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?
Ok, we got that out of the way.
.o files, which is cool in its own way, but what I really want is:
S PATH=$CLASSPATH:Blink
S PATH=$CLASSPATH:Blink
I hate scripting languages, except Bash shell.
Why...because when I program I want an object oriented language. Notice the period at the end of that sentance. If I didn't want the Benefits of Java, I would not program in Java.
Yes, I would love it if the Runtime environments for PERL, Python, Java, Ruby, and a slew of other Lagnugaes could be combined so I could have one and only one virtual machine required.
What I really want is to not have to wrap any Java program I write in a Bash script just to get the Damn thing to run. I realize the gcj way is to compile to
Environmental Variables. Java used to have them. But because of the Mac (oS 9 and before, mind younot OSX) it was removed from the language. Instead, we have -D parameters on the command line. Oh Joy. So to run a program with a different config directory than expected I get:
CLASSPATH=Blah
CLASSPATH=$CLASSPATH:Blue
CLAS
java -Dcustom.config.dir=/home/adam/blah -classpath=$CLASSPATH com.younglogic.app.Executable
and then I stick this whole thing into a bashscript. Will Groovy fix this for me? Nope, I'll just end up with
#!/usr/local/bin/groovy
#cus you know they'll want to stick it in local
CLASSPATH=Blah
CLASSPATH=$CLASSPATH:Blue
CLAS
exec com.younglogic.app.Executable
#Or what ever groovy decries is the right way to execute a java executable.
I still won't use it to extend Mozilla, since that will involve spinning up the JVM and Mozilla already has one of those. Maybe be nice for Eclipse plugins, but, wait, now we are back to real programming tasks and those I want to do in Java.
Hey, Maybe we can call groovy from inside JSP, just to get two layers deep in the scripting. I bet that will speed up development.
Pan Pant, Ahh. now I feel better.
Open Source Identity Management: FreeIPA.org
...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
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.
What advantage has this over Jython?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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 ?
There are hundreds of more or less stable languages for the JVM already. .NET doesn't have a tenth of the variation in lanugages despite all the hype about the "common language" runtime. Now, Groovy is a bad idea because multiple languages is a bad idea. You don't want millions of bits and pieces of the code written in different languages, it just becomes totally unmanageable. Groovy to me looks like some persons poor attempt at making himself look cool by submitting it as a JSR, I hope this crap gets voted down, but with utter crap like JSF going through there doesn't seem to be much hope.
"this looms as a big threat to .Net and a rejuvenation of the Java platform"
.NET already has like a bizillion languages under it that can "talk" together.
except that
Sun have a chance !
a Sun Virtual Machine ( SVM ) that has libs for java and can be targeted well by other langs
start with the JVM fix the Java memory model
(JSR 133, which has been active for nearly three years see article on fixing it and links at bottom located at )
let ADA and fortran target it well
(i.e. think about take floating point IEEE754 seriously but get it out there and tune later)
really not that hard look at Programming Languages for the Java Virtual Machine
Start with something you know well and adapt it
if it was refered to the ITU I bet they would love it and make it a standard !
regards
John Jones
given Sun's focus on compatability and focus on well managed development, groovy would be a step away from that goal. I see no real point in making groovy official spec, other than it makes the groovy developers look cool. there are other scripting languages out there for java, so again nothing special. just someone's need for affirmation.
Java has a few zillion too.
there's no place like ~
Not a troll, just want to know what you find crappy about JSF (I'm about a month away from looing into it so I'm trying to gather information)?
"Look Lois, the two symbols of the Republican Party: an elephant, and a fat white guy who is threatened by change."
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
JSF isn't crappy, just widely misunderstood. JSF is a comprehensive framework that allows the development of structured and scalable java GUI applications independent of the implementation of the GUI. For example the JSF reference implementation provides code that allows server-side processing of HTML forms, but the GUI could be just about anything, including Swing, SWT, Flash... The supposed 'crap' is that many developers expected JSF to be a simple and/or visual design tool for web apps, whereas in reality JSF is a standard framework that IDEs are going to be using to build such tools.