Slashdot Mirror
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."
java can only succeed if the runtime is part of consumer OSs? right now, I think it is not... . probably got this one wrong, dunno...
I hope I didn't brain my damage.
You mean like Parrot?
-- Argel
this isn't nearly as revolutionary as the article spins it as. .Net will continue to gain ground solely because of microsoft's promotional dollars, regardless of its merits as a language.
Repeal the DMCA!
Having a glue language to tie together Java objects is definitely cool, as is having the scripting language compile down to bytecode for easy deployment.
.Net because its set of tools has grown a little, but Groovy itself seems to be more a threat to Perl and Python and other scripting languages rather than anything Microsoft is doing (except for WSH, but is anyone really using that?) Having a scripting language that can reach directly into Java bytecode without having to invoke a separate VM is a great improvement over the current methods of running external Java programs.
I guess in some obscene way, one could infer that Java is somehow a threat to
Frankly, to me, it doesn't matter which 'platform' succeeds. Both frameworks exist on many platforms, so whichever wins, we all benefit.
I have been pwned because my
It sounds to me like anywhere you think you want this, you would be better off with actual Python.
As a hardcore Ruby lover, I've been unhappy that I can't use Ruby with the vast libraries available for Perl and other established libraries.
But this groovy thing looks like a really nice smalltalk-esque language that hooks right into Java, enough to satisfy both sides of my brain.
This is cool and I can benefit from this *right now* in my work. Forget Parrot or Perl 666 (heh).
How come I never heard of this? And why doesn't jpackage have it?
...and a rejuvenation of the Java platform.
I think people who make statements like this aren't really aware of how widespread the usage of Java is in enterprise and multi-tiered systems.
Java is not just applets.
It's simple: I demand prosecution for torture.
Hopefully the name will get changed prior to getting this into the JSE platform. Does it bother anyone else to imagine having to talk about something called Groovy in a professional environment? The Groovy site is chock full of cuteness about making this or that more or less "groovy". I don't mind it personally but it's not helpful when you expect non-technical types to have faith in stuff.
Anyhow, the JSE platform could use an implicit scripting language. I can see the technical merit in this. A Groovy based shell (with exceptions, an abstract file system, all the JDBC goodness integrated, etc.) that works right everywhere would be a nice bit of progress.
Maw! Fire up the karma burner!
which outputs 1 2 3 and 4 on a line. the cool thing about this style of coding is it makes it's very easy to extend functionality like this to hashes such as:
notice how that code was able to do that much, without having to use "special" syntax like perl and php (foreach blocks, etc).
i definitely will have to give this language a shot.
- tristan
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
> What platforms is Java NOT ported to?
Atari 800. It's very frustrating.
Groovy seems to offer nothing that you don't already get in Python, and Python has implementations available based on C (C Python), Java/JVM (Jython), and C#/CLR (IronPython).
The only thing Groovy does offer is that it is Java/JVM-specific at this point--there are no implementations based on anything other than the Java/JVM runtime. That may be a good thing for Sun--tying people even more to Sun's platform--but it sure isn't good for anybody else.
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 ?
It was just a joke. :)
//, the Atari 800 had no expansion slots, and the memory was only expandable to 48K (though it used VERY easy to use cartridges to expand memory), despite using a chip that could (in theory) address 256K.
//e), but I'm thinking of getting one just to play around with. There are connectors now to hook up your Atari 800 to your PC to store software, etc. on the PC, while still being able to use them on the Atari 800, plus access other hardware on the PC. New OS boot cartridges allow the 800 to start up in 2 seconds. Wish I could do THAT with my Win2k box!
I've become rather fascinated of late with the Atari 800, and with what "could have been," had it been upgraded properly.
The Atari 800 was the brainchild of Jay Miner (who later created the Amiga), and you can see the Atari 800 really _was_ the precursor to the Amiga, with its use of coprocessors for video, sound, & memory management, in addition to the CPU. The only thing that hobbled the Atari 800 was its expandability, or, lack thereof. Unlike the Apple
Later Atari 800 machines (XL & above) wound up being expandable to more than 48K, but the way the machine was designed, software that took advantage of memory over 48K wouldn't work on the original 800s, thus, few software makers took advantage of that ability, understandably wanting to sell products usable on as many machines as they could. Thus, despite several generations of barely-different upgrades to the Atari 800, the line died.
Too bad. It used a much faster version of the CPU than the Apple or Commodore machines of the day (1.89mHz vs 1 or 1 for the Apple ][ & C64), as well as speeding up everything else by using coprocessors. Had the expandability been better, things may have turned out much different.
It's also interesting to see people making new software & hardware (!) for the Atari 800 line even today. Bizarre, but amusing. I never had an Atari 800 when I was a kid (I had an Apple