Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Java Programming IT Technology

Groovy JSR: A New Era for Java? 100

Posted by timothy from the coffee's-always-been-there dept.
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."
This discussion has been archived. No new comments can be posted.

Groovy JSR: A New Era for Java? More

Groovy JSR: A New Era for Java?

Comments Filter:
  • 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...

  • Imagine.... (Score:5, Informative)

    by argel ( 83930 ) <`moc.nsm' `ta' `legra'> on Tuesday March 16, 2004 @07:25PM (#8584319) Homepage
    Imagine a common platform of standardised languages talking to each other ...

    You mean like Parrot?

  • bah (Score:2, Interesting)

    by Tuxinatorium ( 463682 )
    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.

    • Re:bah (Score:4, Informative)

      by jone1941 ( 516270 ) <jone1941@g[ ]l.com ['mai' in gap]> on Tuesday March 16, 2004 @10:43PM (#8585718)
      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.
    • .Net will continue to gain ground solely because of microsoft's promotional dollars, regardless of its merits as a language.

      C# and the CLR will gain ground because they really do have considerable more technical merit than Java. They will also gain ground because there is a complete open source implementation available (there aren't for Java). .NET is a set of Microsoft-proprietary APIs. It will gain ground because Java doesn't address the needs of Windows programmers as well. Windows programmers aren
  • 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.

    I guess in some obscene way, one could infer that Java is somehow a threat to .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.

    Frankly, to me, it doesn't matter which 'platform' succeeds. Both frameworks exist on many platforms, so whichever wins, we all benefit.

  • Let Me Get This Straight (Score:5, Insightful)

    by Markus Registrada ( 642224 ) on Tuesday March 16, 2004 @07:35PM (#8584389)
    This is like Python, except it's less portable (because JVMs are less widely ported than Python), and has a bigger memory footprint (because it uses JVM garbage collection instead of Python reference-counting), and it uses libraries with different actual semantics and different bugs on different platforms (because they're the Java libraries).

    It sounds to me like anywhere you think you want this, you would be better off with actual Python.

    • Re:Let Me Get This Straight (Score:5, Interesting)

      by Anonymous Coward on Tuesday March 16, 2004 @07:40PM (#8584424)

      This is like Python,

      Except it's actually elegant, based on Smalltalk, not whatever the heck Python is inspired by.

      And Python reference counting stinks, I just spent weeks debugging a C extension that keeps killing a Python-based server.

      I use Python, but I sure don't think there's anything "great" about it, at least not enough to explain why it seems *every* language discussion includes somebody who thinks Python is god's gift to computer science.

      Python came along at a time when people where starting to use Perl for bigger projects and realizing that Perl is really BAD for big projects. Momentum took over from there.

      • Except [Groovy] actually elegant, based on Smalltalk, not whatever the heck Python is inspired by.

        I don't see anything "elegant" about yet another scripting language built on top of a runtime designed for a simple statically typed language (Java).

        And Python reference counting stinks,

        True. It also makes the C-Python interpreter slower than a garbage collected version. It is somewhat disconcerting that this misfeature of C-Python still exists after so many years. In fact, the C-Python implementation

        • Re:Let Me Get This Straight (Score:4, Interesting)

          by angel'o'sphere ( 80593 ) <angelo.schneider ... e ['oom' in gap]> on Wednesday March 17, 2004 @02:07PM (#8590787) Journal
          But it works well enough, and it sure is a lot more practical than running a JVM just to execute Groovy.

          I like to point out that running Groovy in a JVM means: you want to script java code.

          I also do not really see the difference between running a PVM or a JVM (python virtual machine versus java virtual machine).

          But: I know that Java Byte Code is Hot Spot compiled to machine code. A groovy script running in a JVM scripting Java classes or classes of other languages (like SmallTalk or Lisp or Prolog or Eiffel or Ada or: Python) is java byte code, isnt it? So it is compiled to machine code during runtime.

          Goovy is an excellent language. And in case it gains momentum like one has written here, there is no doubt that people will port it to Parrot and the Python VM just like Python is ported to the JVM.

          angel'o'sphere
          • I also do not really see the difference between running a PVM or a JVM (python virtual machine versus java virtual machine).

            Well, unlike Sun's Java runtime (which is the only one that counts), the Python runtime is open source. Furthermore, the Python runtime takes a fraction of the amount of memory of the Java runtime.

            Goovy is an excellent language. And in case it gains momentum like one has written here, there is no doubt that people will port it to Parrot and the Python VM just like Python is ported
            • Why dont you keep your discussion straight?

              First you doubt groovy is worth it and you argue Python is better somehow.

              Now you start arguing with open source ... where is the relation?

              Finally you try to distract the reader even further by saying this: The Python port to the JVM was a fluke--it only works so well because someone really smart spent a lot of time on making it happen.

              First I like to point out: there have been two Python ports to the JVM which got merged later to the Jython we have in our day
              • Well, my main point answering in the first line to one of your posts was: you simply seem not to have looked at "Groovy the Language" at all.

                Sure, I have. It's just another run-of-the-mill scripting language. The only significant distinction is that, so far, it seems particularly tied to the JVM.

                Second I like to point out: Writing a Python compiler for the JVM is as trivial as writing a Python compiler to the PVM. Funny is: You start in a pure Python environment and use the Python compiler which is wr
                • Could not resist:

                  The biggest difference is the license and the patents (the PVM is free and open, the JVM isn't)
                  I did not ask about THOSE differents. Besides the fact that it is from a lawers point of view simply wrong. The JVM specification is "open". Everybody is free to wrie a JVM which is free software. I guess the "free software community" did not found it worth while to do so. Or how do you explain that there are about 20 open/free JVM implementations and none of them is "finished" while there a
          • Goovy is an excellent language. And in case it gains momentum like one has written here, there is no doubt that people will port it to Parrot and the Python VM just like Python is ported to the JVM.

            It is the stated goal of Groovy to be a dynamic and scripting language for Java (see here [codehaus.org]). That is, its design is driven by the needs of Java developers and adapted closely to the Java environment.

            Maybe it will be ported to other platforms, but Groovy will then be as foreign on those other platforms as somet

    • Re:Let Me Get This Straight (Score:5, Insightful)

      by malachid69 ( 306291 ) on Tuesday March 16, 2004 @07:43PM (#8584448) Homepage
      it's less portable (because JVMs are less widely ported than Python)

      What platforms is Java NOT ported to?

      I know it is available for Windows, Linux, FreeBSD, AIX, HP-UX, Solaris, AS/400, Handhelds (Palm, Handspring, SaveJe, etc), and direct hardware (PTCU and TINI)... What's missing?

    • Re:Let Me Get This Straight (Score:5, Informative)

      by FFFish ( 7567 ) on Tuesday March 16, 2004 @07:49PM (#8584490) Homepage
      It's even less like Python, because Python has a port named Jython which... you guessed it! provides Python scripting within Java.

    • Re:Let Me Get This Straight (Score:5, Insightful)

      by Pengo ( 28814 ) on Tuesday March 16, 2004 @07:50PM (#8584493) Journal
      "It sounds to me like anywhere you think you want this, you would be better off with actual Python."

      Unless you want access to any of the miriad of Java libraries that are available, such as JDBC drivers, XML parsers, SOAP tools and 3rd party components you may want to use unless you prefer to use something like Jython.

      I have to work with other bits of code and systems all the time, and thats the main headache with using Python that I run into.

      Python might be king of quick hacks, but for a large-scale project where bits of scripting code might be appropriate, this sounds like an excelent option where you would NOT be better off with python.

      • Re:Let Me Get This Straight (Score:4, Informative)

        by Jerf ( 17166 ) on Tuesday March 16, 2004 @10:35PM (#8585637) Journal
        such as JDBC drivers, XML parsers, SOAP tools and 3rd party components

        Semi-check [python.org], built-in [python.org], check [interview-machine.com], and check [vex.net] (including a lot of real winners, particularly including multiple [wxpython.org] cross-platform [daa.com.au] GUIs [riverbankcomputing.co.uk]).

        (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 [jython.org], though I know it's been mentioned elsewhere.)
      • Unless you want access to any of the miriad of Java libraries that are available,

        No, I don't.

        Python might be king of quick hacks, but for a large-scale project where bits of scripting code might be appropriate, this sounds like an excelent option where you would NOT be better off with python.

        There are plenty of scripting languages for that. Jython and JavaScript have both C and JVM-based implementations. Beanshell is small and integrates particularly well with Java. I really don't see why we need G
    • and has a bigger memory footprint (because it uses JVM garbage collection instead of Python reference-counting),

      Java does have a bigger footprint than Python, but that is unrelated to whether it uses garbage collection or reference counting. IMO, Python is a nicer language than Java, but the use of reference counting in Python actually makes it both slower and more bloated than a garbage collected implementation of Python would be.
    • I was under the impression that python had an optional garbage collector [python.org], enabled by default.
      Also, I'm not sure what do you mean by bigger footprint when you refer to a language. GC interpreters/VMs may have a bigger footprint, but at the same time the footprint of the running software is smaller than reference counting because of the lack of reference counters.

  • *blink* hey this is COOL (Score:5, Interesting)

    by Anonymous Coward on Tuesday March 16, 2004 @07:36PM (#8584398)
    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 [jpackage.org] have it?
    • Are you aware of Jython (Jython.org) that implements Python in Java, so that you get most (if not all) of the extensive Python standard library in the JVM. Jython is exactly equivalent to Groovy (you can inherit Jython from Java and vice-versa) but is based on a more well-known language...
      • Are you aware of Jython (Jython.org) that implements Python in Java, so that you get most (if not all) of the extensive Python standard library in the JVM. Jython is exactly equivalent to Groovy (you can inherit Jython from Java and vice-versa) but is based on a more well-known language...

        I've been a Python programmer as long as I've been a Java programmer (since 1996), so I've followed Jython with great interest. The problem with Jython is that it's implementation is ssssllllooooooooowww. As in 2-3 ma

  • Ok, we got that out of the way.

    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 wri
    • Yes, I am still illterate.

      And I don't really hate Scripting languages. Some of my best friends code in Perl.

      I guess with Groovy we can also use the time honored

      Javaish? Funny, doesn't look like Javaish.

    • Re:Warning, Obligatory Jython reference ahead (Score:5, Informative)

      by cxvx ( 525894 ) on Tuesday March 16, 2004 @08:00PM (#8584579) Homepage
      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:

      Actually, as of JDK 1.5, System.getenv() [sun.com] is undeprecated (is that even a word? :). I'm sure that was a first in the java libraries though :)

    • 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.

      That's not as far of as you think:
      You can create servlets using Groovy [codehaus.org].

    • LOL,
      probably you should read a bit more about how to use the CLASSPATH.

      a) Bash exercise
      CLASSPATH=Blah:blue:Blink

      b) simle Java start
      java -Dcustom.config.dir=/home/adam/blah com.younglogic.app.Executable

      Note: as the CLASSPATH is set, tehre is no need to use -classpath

      As you dont like -D (I agree here) why dont you put the infoirmatin you pass here into a properties file and use Object.getResource("file.props"); to load it?

      c) complex Java sample:
      java -Dcustom.config.dir=/home/adam/blah -classpath=some/mor
      • There were two threads to my Rant, one about scripting languages in general and one about having to Script in Bash to get a Java executable.

        I know about the $CLASSPATH thing, just like to make it explicit.

        I find whene ever I start scripting, the scope of the application increases and I wish I were using a language that was good for large projects. Some people are comfortable using Perl in the Large, but I am not. Maybe I was just warped too early. Blame my CS instructors. I always do.

        I've done the pr

  • rejuvenation? (Score:5, Insightful)

    by sfjoe ( 470510 ) on Tuesday March 16, 2004 @07:51PM (#8584500)
    ...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.

    • yah, but it's so corporate, bleh.

      it's about time cool programmers stepped up on the java scene.
    • 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.

      LOL rejuvenate != repair

      Rejuvenation: To restore to youthful vigor or appearance; make young again.

      Java is 9 years old, getting to be a senior citizen in the world of programming languages. Do you think it's possible to be a successful 60-year old person and still enjoy being restored to youth? Of course, they are not incompatible concepts.

      Not everyone around he

  • JCP naming thunk? (Score:4, Insightful)

    by Tailhook ( 98486 ) on Tuesday March 16, 2004 @07:54PM (#8584531)
    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.

  • Blocks! (Score:3, Interesting)

    by OmniVector ( 569062 ) <se e m y h o mepage> on Tuesday March 16, 2004 @07:59PM (#8584574) Homepage
    When i saw how Groovy does blocks, i immediately thought of Ruby [ruby-lang.org]. basically you have a block of code like this:

    array = [ 1, 2, 3, 4 ]
    array.each do |i|
    puts i
    end


    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:

    hash = { 1 => "one", 2 => "two", 3 => "three" }
    hash.each_pair do |key,value|
    puts "#{key} = #{value}"
    end


    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.

    • Re:Blocks! (Score:1, Insightful)

      by Anonymous Coward
      The cool thing about blocks, that hardly anybody seems to mention, is that you can factor out "transactional" code. For instance, code like this:

      t = open_thing()
      try:
      frob(t)
      fozzle(t)
      glorp(t)
      finally:
      close_thing(t)

      In ruby you can factor out the try/finally and just do:

      with_thing { |t|
      frozzle(t)... etc
      }

      and you don't have to clutter the code with the same construct, over and over. This is why ruby is so popular with the XP crowd, you can factor out common stuff into ONE PLACE which you can't d

      • Re:Blocks! (Score:3, Informative)

        by battjt ( 9342 )
        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

    • Re:Blocks! (Score:4, Insightful)

      by Unordained ( 262962 ) <unordained_slashdotNOSPAM@csmaster.org> on Tuesday March 16, 2004 @09:57PM (#8585411)
      would you mind explaining in what way

      hash.each_pair do |key,value|

      is not "special" syntax, but

      foreach ($array_name as $key_name => $value_name)

      is?
      • because in with blocks, it's standard. perl requires a special syntax structure (foreach) just to do hashes. JUST for hashes. whereas ruby's is standard, and can be used for much more than arrays, and hashes. it's also used for threads, such as this:

        thread = Thread.new do
        executeThreadCodeHere
        end

        the code in that block makes a new thread. the do ... end code is a "block" (think of it as a dynamically created function) that's passed as a parameter to the thread constructor. that's not special syntax,

        • [RELATED:]
          python lambda-functions (nameless functions, passed as callbacks) ... or function objects / callbacks in C++/C ...

          it's the equivalent, then, of using STL algorithms like ...

          vector bob;

          for_each(bob.begin(), bob.end(), mem_fun(&T::do_stuff));

          ... the difference being that C++ doesn't particularly allow for unnamed functions / classes, as would be necessary to do this.

          [NIT-PICK:]
          i would say that calling it a "block" is confusing, as that term is already used to refer to things in {} in most l

          • [NitPick]

            I think the term block referring to [:args| statements] predates, or at least is contemporary with, the introduction of { } to describe blocks.

            In a way, you can see {..} as a handicapped version of [..], in that they are not first class and do not take arguments. To think: C was *that* close to having a proper lambda construct.
        • perl requires a special syntax structure (foreach) just to do hashes

          foreach in perl deals with arrays not hashes. To deal with a hash you get the list of keys from the hash as an array and iterate through them. You can deal with arrays using a for loop if you want to, but foreach just reduces the amount of code you have to write.

      • Re:Blocks! (Score:3, Informative)

        by tunah ( 530328 )
        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.
    • Wowzers. Reinventing APL are we ;)

  • Scripting with .NET (Score:4, Informative)

    by Chester K ( 145560 ) on Tuesday March 16, 2004 @08:01PM (#8584592) Homepage
    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.

    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 .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.

    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?

    • Re:Scripting with .NET (Score:5, Informative)

      by iebgener ( 592564 ) on Tuesday March 16, 2004 @08:32PM (#8584828)
      In Java, you can't unload code/type from the classpath (core classes you had when you started java) but if the class comes from a different classloader (created at runtime), you can do pretty much what you want... if you own the classloader...

      The only limitation is that the class must not be on the classpath (for security reason). This is also how you can have the same class but with different version on the same VM.

      See : http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ ClassLoader.html
    • No. In Java, a Class is subject to garbage collection exactly like every other object (well, conceptually at least). When there are no more references to it, away it goes. Since a ClassLoader holds a reference to all of the Classes it loaded, and vice versa, Classes cannot be considered garbage unless their ClassLoader is also garbage.

      To be able to garbage collect Classes, you have to load them using a new ClassLoader, and then be damned sure that all references to the classes and the ClassLoader are de
    • This isn't entirely true, if I'm understanding you correctly. It's really a matter of design.

      If you're running a MUD, let's say written in .NET, and want to add scripting on top of it, you wouldn't use ActiveScripting to do this (what I'm assuming you're doing).

      Instead you would more then likely have those scripts compiled and objects "loaded" on the fly using ICodeCompiler using the GenerateInMemory property set to true. You can then recompile this on the fly at any point.

      Your problem lies in script B
      • Instead you would more then likely have those scripts compiled and objects "loaded" on the fly using ICodeCompiler using the GenerateInMemory property set to true. You can then recompile this on the fly at any point.

        That's the approach I was planning on using, however that just creates a more-or-less standard assembly in memory. There's no way to unload the assembly. Recompiling doesn't unload the old assembly, just returns you a reference to the new assembly via the CompiledAssembly property. The example
    • You should probably check out the new DynamicMethod class: it allows creating methods at runtime that are not bound to a dynamic assembly and whose code can be garbage collected once it's no longer in use.
      Mono implements it already.
      • You should probably check out the new DynamicMethod class: it allows creating methods at runtime that are not bound to a dynamic assembly and whose code can be garbage collected once it's no longer in use.
        Mono implements it already.

        Awesome. That's exactly what I need; and Mono implementing it is even better since that's my development platform.

  • what's the point? (Score:3, Insightful)

    by hak1du ( 761835 ) on Tuesday March 16, 2004 @11:51PM (#8586096) Journal
    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.
    • Oh, thats a silly post, I really hat seeing it moddd up :-/ Sorry hak1du, no offense.

      Groovy seems to offer nothing that you don't already get in Python

      If like extend that just a little bit then I come to this: every language seems to offer nothing more than any other language allready has.

      Ooops. And now? Am I wrong? All programming languages can be used to do more or less everything else.

      However there are two things which make a HUGHE difference:

      a) programming pradigm
      its a difference wether you code

  • Great but why a JSR (Score:4, Informative)

    by Laz10 ( 708792 ) on Wednesday March 17, 2004 @06:44AM (#8587491)
    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 ?
    • This is a good point. I'm happy to see something getting JSR status however. If it becomes a standard, perhaps more work will be done to add the language as a possible JSP scriplet alternative and what's more the compiler may be made more efficient than Jython's (which I haven't had the opportunity to try yet, but I hear that there exist some limitations on the code to be compiled... is this true?).

      Wouldn't it be nice to have a community supported alternative to Java? Or even a language integrated tightly

  • 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
    • 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)?
      • 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 real
  • "this looms as a big threat to .Net and a rejuvenation of the Java platform"

    except that .NET already has like a bizillion languages under it that can "talk" together.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close