What java probably needed from the start was something like groovy
Jython (then called JPython) came along fairly early, in 1997 and feature complete but never took off for testing or gluing Java code. Jacl, a Java version of Tcl, also came around 1997 but virtually no one used it. Beanshell was built before Groovy, removing static typing but keeping the rest of Java's syntax. Groovy duplicated Beanshell's use case but brought closures and terse collections syntax, but didn't get any significant users until the Grails project spent a year (2006) retrofitting it with a meta-object protocol so it could be used with Grails. A second growth spurt happened in 2009 when Groovy added a DSL syntax to its already klunky grammar so Gradle could use it. Though you could argue Groovy's use in Gradle builds isn't very significant because the build files are typically 20 to 50 lines long, using the DSL syntax only and not making any use of the actual Groovy language features. And Gradle may not use Groovy as a build language for much longer. Calling Groovy an "overhead in the IDE-to-Gradle communication", the recent Gradle 2.0 roadmap [1] says:
"Android Studio demonstrates the enormous potential of a deep integration between the IDE and Gradle. At the moment, the price we pay for this is often mediocre responsiveness: every time the IDE makes a query of Gradle, the configuration phase is run before an answer can be given. The folks at Google are implementing some smart workarounds for this. But what is ultimately needed is a fundamental solution within Gradle that eliminates the overhead in the IDE-to-Gradle communication."
I should perhaps have been a little more clear: I didn't mean to imply there were no scripting languages for java, just that they weren't first-class citizens of the platform (Beanshell being an exception -- but perhaps it too suffered from being a bit heavy?).
It's interesting that Gradle seem to be moving away from Groovy -- especially considering the section on configuration: It appear they're moving towards a functional-flavoured architecture -- and at the same time further specializing Gradle -- so that it'll (probably) be a better build tool -- but also quite useless for other tasks/customization. Or rather; it would appear the project will not be much of a driver in improving Groovy for projects that need some form of dynamic configuration etc.
On the other hand Gradle will (presumably) serve as nice architectural model to follow for other projects (move towards a functional style, rather than programming dependencies in a procedural manner with a hacked up xml dialect).
Perhaps one of the core issues have been projects mixing complex configuration requirements (eg: routing for tomcat) with simple requirements (eg: username/password etc -- stuff that works well in a ini-like format). I suppose that if you've determined you need complex/powerful configuration, you'd be hard-pressed to include a second form of configuration in your project. After all simple xml files are almost as readable and easy to work with as ini-files... And yet, for a lot of projects, it's ended up being a bit of a mess.
Comments
Jython (then called JPython) came along fairly early, in 1997 and feature complete but never took off for testing or gluing Java code. Jacl, a Java version of Tcl, also came around 1997 but virtually no one used it. Beanshell was built before Groovy, removing static typing but keeping the rest of Java's syntax. Groovy duplicated Beanshell's use case but brought closures and terse collections syntax, but didn't get any significant users until the Grails project spent a year (2006) retrofitting it with a meta-object protocol so it could be used with Grails. A second growth spurt happened in 2009 when Groovy added a DSL syntax to its already klunky grammar so Gradle could use it. Though you could argue Groovy's use in Gradle builds isn't very significant because the build files are typically 20 to 50 lines long, using the DSL syntax only and not making any use of the actual Groovy language features. And Gradle may not use Groovy as a build language for much longer. Calling Groovy an "overhead in the IDE-to-Gradle communication", the recent Gradle 2.0 roadmap [1] says:
"Android Studio demonstrates the enormous potential of a deep integration between the IDE and Gradle. At the moment, the price we pay for this is often mediocre responsiveness: every time the IDE makes a query of Gradle, the configuration phase is run before an answer can be given. The folks at Google are implementing some smart workarounds for this. But what is ultimately needed is a fundamental solution within Gradle that eliminates the overhead in the IDE-to-Gradle communication."
[1] http://forums.gradle.org/gradle/topics/revolutionary_new_gra...
I should perhaps have been a little more clear: I didn't mean to imply there were no scripting languages for java, just that they weren't first-class citizens of the platform (Beanshell being an exception -- but perhaps it too suffered from being a bit heavy?).
It's interesting that Gradle seem to be moving away from Groovy -- especially considering the section on configuration: It appear they're moving towards a functional-flavoured architecture -- and at the same time further specializing Gradle -- so that it'll (probably) be a better build tool -- but also quite useless for other tasks/customization. Or rather; it would appear the project will not be much of a driver in improving Groovy for projects that need some form of dynamic configuration etc.
On the other hand Gradle will (presumably) serve as nice architectural model to follow for other projects (move towards a functional style, rather than programming dependencies in a procedural manner with a hacked up xml dialect).
Perhaps one of the core issues have been projects mixing complex configuration requirements (eg: routing for tomcat) with simple requirements (eg: username/password etc -- stuff that works well in a ini-like format). I suppose that if you've determined you need complex/powerful configuration, you'd be hard-pressed to include a second form of configuration in your project. After all simple xml files are almost as readable and easy to work with as ini-files... And yet, for a lot of projects, it's ended up being a bit of a mess.