Groovy JSR: A New Era for Java?
fastdecade writes "Groovy, the open-source scripting language, has been submitted for a Java Specification Request (JSR). And not without strong support from venerable J2EE practitioner/author, Richard Monson-Haefel, who labels this "the beginning of a new era in the Java platform". Groovy can use Java objects easily and compiles to JVM byte code, but it is nonetheless a scripting language at heart and a great companion for the more heavyweight Java programming language. Most JSRs concern new APIs, and this is the first JSR for an alternative language. Imagine a common platform of standardised languages talking to each other ... this looms as a big threat to .Net and a rejuvenation of the Java platform."
You mean like Parrot?
-- Argel
It's even less like Python, because Python has a port named Jython which... you guessed it! provides Python scripting within Java.
--
Don't like it? Respond with words, not karma.
Actually, as of JDK 1.5, System.getenv() is undeprecated (is that even a word? :). I'm sure that was a first in the java libraries though :)
If only I could come up with a good sig
Of course .NET already has support for JScript and VBScript -- however, the main problem with scripting on .NET is that once you load code into memory, there's no way to unload it without having to destroy the entire AppDomain.
.NET because of the no-unloading-assemblies behavior; but it makes .NET unusuable in the class of applications where you're running lots of different code from different sources; in this case, a MUD where users can script their own objects -- with the ability to arbitrarily rewrite and change their scripts at any time. .NET seems like it has wonderful support for everything else needed (Code Access Security, etc.), but that one single sticking point is a dealbreaker.
This leads to problems where you've got an environment where you'll be running lots of dynamic script code -- your process pretty much leaks memory. The only solution is to run your scripted code off in another AppDomain, but then you've got the considerable overhead of doing cross-AppDomain calls (serialization/deserialization, both ways) and you're restricted to types that can be passed across the AppDomain barrier.
Even then, you've got to be extremely careful because if you pass back a type that was defined in the assembly generated by the script, your primary AppDomain will silently load the assembly itself to deal with the type (and keep it open forever -- the thing we wanted to avoid!).
I understand there are considerable performance gains in
I'm not all that familiar with this aspect of Java -- does Java suffer from the same problem of not being able to unload code/types from memory?
NO CARRIER
Something wrong with this Java?
http://www.apple.com/macosx/features/java/
"Can of worms? The can is open... the worms are everywhere."
such as JDBC drivers, XML parsers, SOAP tools and 3rd party components
Semi-check, built-in, check, and check (including a lot of real winners, particularly including multiple cross-platform GUIs).
(The semi-check is because I'm not 100% certain the python modules match the JDBC completely.)
The only advantage Java offers is when it has an actual library that you can't get in Python (or likely anywhere else); capability for capability the languages and libraries are pretty close to the same. I mean, we have "Web Application Servers" for Python (like Zope), but maybe you absolutely need some Java thing for some other reason. There's no one language that meets all needs. But there's no reason Python can't be used in very large scale projects successfully, as evidenced by the fact that it has been so used.
Personally, I'd much rather use Python for the larger scale projects since for a variety of reasons I think it scales better then Java; Java projects IMHO survive because they get a lot more resources thrown at them, not because the language does very much to hold large projects together. But that's just my opinion.
(Oh, and Jython, though I know it's been mentioned elsewhere.)
Ugh, Interesting? Common moderators .Net IS NOT a language, it is a peice of marketing. You can wax philosophical about C# or the runtime, but don't make sweeping statements that don't mean anyting. Sorry for the rant, but this post just didn't even make sense, let alone say anything remotely interesting.
Fear trumps hope and ignorance trumps both
each_pair is a function call that takes a block (like an inline method). Obviously you need language support for passing blocks to functions, but this is a general purpose feature that is used in many places. In contrast, foreach is a (useful) hack for the specific case of iterating over a collection.
Free Java games for your phone: Tontie, Sokoban
There are many other scripting languages for java than groovy.
Beanshell (Lightweight Java)
http://www.beanshell.org/
JavaScript (Rhino)
http://www.mozilla.org/rhino/
Python (Jython)
http://www.jython.org/
Ryby (JRuby)
http://jruby.sourceforge.net/
has all been available for several years without being made a JSR.
What qualifies groovy to become a JSR instead of them ? Isn't choice good.
IBM has open sourced a framework called BSF
http://jakarta.apache.org/bsf/
that allows for integrating scripting languages into java. I could see why THAT would be promoted to a JSR -- not a specific scripting language.
As the name suggests it looks like groovy is just a couple of guys who have been playing around with tossing "groovy" language features into their homegrown scripting langugage. Cool, interesting but why make it part of the big package ?
We do a similar thing in Java with anonymous classes.
new StopWatch(2000) { public void run() {
frozzle(blah);
}}.start();
where StopWatch is a class that executes the run method for up to 2000 ms. Granted some syntactic sugar would be nice.
I agree with yuour assertion that blocks are extrememly helpful. I was first introduced to them in Smalltalk.
Joe
Joe Batt Solid Design