Your statement is reductive. You can replace xtend by all the new jvm language. In fact these languages haven't proove anything. On the contrary of groovy.
On my own experience I use groovy not only for grails :
- virtually all java classes can be replaced by groovy classes. Groovy is far more concise. eg. I use groovy for spring/backed bean.
All your examples are controlled by the Groovy/Grails business in some way. Groovy bundles both gpars and Swingbuilder in its distro, and Spring is bundled in Grails.
The Not-Invented-Here mentality has always been prevalent in the VMWare-funded "Gr8te" ecosystem. If someone independently builds something using Groovy or Grails, such as Alex Tkachman, Roshan Dawrani, et al building Groovy++, VMWare make excuses to reject it, then build their own version, Groovy 2's static compilation, probably copying plenty of code out of Groovy++ along the way.
This mentality results from VMWare wanting to control as much of Grails's constituent technologies as possible. The reason behind Gradle becoming the build tool for Groovy/Grails, Spring, and Hibernate was for Gradleware to pitch their control of Hibernate's build, knowing they'll be targeted for a buyout by VMWare. Rocher's probably hard-balling the Gradleware execs right now, trying to screw them for as much as possible.
On my own experience I use groovy not only for grails :
- virtually all java classes can be replaced by groovy classes. Groovy is far more concise. eg. I use groovy for spring/backed bean.
- SwingBuilder
- gpars