Groovy language submitted as JSR 241

Home

News: Groovy language submitted as JSR 241

  1. Groovy language submitted as JSR 241 (54 messages)

    Groovy, the scripting language, has submitted itself as a JSR under the JCP 2.6 process. This would mean that the JCP will be used to standardize the language via a specification and TCK. There is already support from Apache, BEA and ThoughtWorks along with Richard Monson-Haefel and more.
    James Strachan and Richard Monson-Haefel are co-spec leads.

    Excerpt from JSR
    Currently the Java community does not have a standard JCP-sanctioned agile programming language for writing scripts and applications that interoperate with the entire J2SE platform.
    Groovy makes writing scripts and applications for the Java Virtual Machine fast and easy. Groovy includes language features found in Python, Ruby, and Smalltalk, but uses syntax natural to developers that use the Java programming language. Because Groovy is based on J2SE, applications written in Groovy can use the full complement of J2SE APIs, and work seamlessly with other packages and applications written in the Java programming language.
    Groovy is a complement of the Java programming language, not a replacement of it. Where the Java programming language is exacting, Groovy is expedient. Where the Java programming language is extensive, Groovy is convenient. Using Groovy, developers can take advantage of rapid application development features like those in Python and Ruby for quick application prototyping and development of scripts for the Java Virtual Machine. In addition, Groovy is useful as a shell-level scripting language that can execute other Groovy scripts as well as native operating-system scripts.
    Groovy is a very "learnable" programming language that makes adoption of the Java platform by developers go more quickly and smoothly. Groovy incorporates syntax similar to the Java programming language. That developers can use familiar Java-like syntax in Groovy source code makes learning of Groovy easier, and facilitates transition from either language to the other. Groovy can be a low-threshold language for developers new to the Java platform as well as a productivity-enhancing tool for experienced Java developers.
    Groovy JSR Info

    View the JCP proposal JSR 241: The Groovy Programming Language

    Read James Strachan's announcement that a Groovy JSR (241) has been submitted!

    Read Richard Monseon-Haefel's thoughts on "Why Groovy?" in JSR-241: Groovy – A New Standard Programming Language for the Java Platform

    Read Carlos Villela's thoughts in Gah-roo-vee!

    Threaded Messages (54)

  2. Groovy language submitted as JSR 241[ Go to top ]

    My main question is how this will affect development of the language.

    Groovy is still a very new language and I feel needs to time to settle down and to become formalized as it's own nature becomes clearer. This process I'm not convinced is over; language features being squeezed into Beta 4 suggest this also.

    If the JSR does not become a straight-jacket for this out-of-the-box (as in thinking out-of-the-box) language then fantastic. I too would love to see it formalized but not contstrained. I've waited many years to see minor changes to the Java language - which can be appreciated within Java's constraints. If this happens to Groovy then we lose in my mind the first decent new langauge for the JVM (jython is very good but is a 'translation' not an orginal).

    Respect to the guys behind Groovy it has the makings of a serious programming language. It would be nice to see it tackle high level issues like a clean persistence and remoting mechanism in the same way it has attacked the language features.

    Interesting to see James's demarcation of the language:

    >> Groovy is a complement of the Java programming language, not a replacement of it. Where the Java programming language is exacting, Groovy is expedient. Where the Java programming language is extensive, Groovy is convenient. Using Groovy, developers can take advantage of rapid application development...

    A rather intelligent colleague of mine who shall remain anonymous said that he felt Java's weakness was that it covers all cases but rarely makes life easier in the mundane/common case.

    An example is if you may have a method which will allow you to print the time in any locale, to any output stream yet doesn't give you a simple printDate() method for the most common and repetitive case of printing to System.out in the current locale (example for illustration only).

    I like Java very much but it causes severe RSI, so Groovy is a welcome addition it makes life easier for the 10% of the APIs/language we use 90% of the time.
  3. Groovy language submitted as JSR 241[ Go to top ]

    I suppose going into JSR can only be a good thing but I'm not sure it will make a huge difference from being on SF.

    As a language, it's great, I've used it for some ANT scripting and looked at using it for defining simple rules. At the end of the day you don't really want to expose business people to Java syntax and it's difficult to make GUIs flexible enough. Even if you do they're a real pain to version control and manage with releases. I shall follow this closely, nice one James!

    -John-
  4. Groovy language submitted as JSR 241[ Go to top ]

    I don't see Groovy in wide spread use anywhere yet, outside a few individuals talking about it on their weblogs.

    Wouldn't it make more sense to see if the language takes on first before attempting to standardize it (after which any mistakes in the language will become very difficult to fix).
  5. Don't add a new "beautifull jsr"...Think to make a better java...don't make java a fat boy...Really we need a new script language?...Really we new a basic-java! Stop nerd-ing Java!!! Where's the clean model? Where the logic? Going speed...Why? Where? If You want a super-simple-visual environment then Microsoft is the winner!!! Java is more than this...I don't want be a market's slave! REVOLUTION...I want opensource...but i hate CAOS_MIXING_OPENSOURCE!!!
  6. Correction To Thread Summary[ Go to top ]

    Don't add a new "beautifull jsr"...Think to make a better java...don't make java a fat boy...Really we need a new script language?...Really we new a basic-java! Stop nerd-ing Java!!! Where's the clean model? Where the logic? Going speed...Why? Where? If You want a super-simple-visual environment then Microsoft is the winner!!! Java is more than this...I don't want be a market's slave! REVOLUTION...I want opensource...but i hate CAOS_MIXING_OPENSOURCE!!!
    Off Topic Reply:

    I was not referring to being a market slave. I was referring government intervention. They are forcing reduction of wages through tax subsidies, unnatural exchange rates, and other things. I wish only to be a market slave, but like socialism it can never exist in reality. It all comes down to what you are willing to fight for. Revolution is the key to any freedom. Whether it’s a market revolution started by making Groovy do something that others are unable to that overrides government intervention, or marching on D.C. to get our civil rights back.
  7. Doubts on the JSR[ Go to top ]

    I have a few doubts on this JSR being accepted by Sun, which I detailed in my weblog.

    I hope I'm wrong.

    --
    Cedric
  8. Doubts on the JSR[ Go to top ]

    I don't want politics problems in this discussion...Java need a clean life...I don't hate Groovy...It's a good work but Java's growing fast...It's not a good think...more and more JSR...We are free! If i don't wan't to use Groovy, I can...But the GOOD of OpenSource is becaming the BAD! Attention! The problem is the CAOS...more and more things become CAOS!...
    Sorry if i've hurted someone...but i'm very scared!...
  9. Degradation of thread[ Go to top ]

    But the GOOD of OpenSource is becaming the BAD! Attention! The problem is the CAOS...more and more things become CAOS!...Sorry if i've hurted someone...but i'm very scared!...
    Please refrain from degrading this thread. If you have something substantial about Groovy or Jython, to contribute please do, else stop posting useless views.
  10. Do we need it...[ Go to top ]

    IMO, added another language to the stack never made things easier. I am still horrified if I think of people defining IDLs before generating stubs that then would be implemented. I see programmers in projects struggling to use JavaScript, Java and PL/SQL at the same time, doing neither very good. I'd rather have one good language and go an extra mile exploiting it as much as possible then throwing in another languages.
  11. Do we need it...[ Go to top ]

    IMO, added another language to the stack never made things easier.

    Pedantic mode but it isn't on the stack, it's parallel to java.

    Assembler was hard to work with so people developed macro assemblers.
    They were hard to work with so we had C/PASCAL etc. They were okay but didn't scale to very large projects so well. So we moved to C++/ADA et al which added higher level features. The projects keep getting bigger so we've all moved to Java. But the amount of java required in a J2EE project can be vast and has lots of redundant code so we've moved to looking at AspectJ etc. So is there really any harm at soliving problems through a language as long as it is the -_right_ language?

    As gradually we work at higher and higher levels we're always going to need higher level languages.

    I agree that proliferation of languages can cause confusion but I have yet to see (Java included) a magic bullet langauge that does all. But hey this is a very old debate isn't it.
  12. Do we need it...[ Go to top ]

    I agree that proliferation of languages can cause confusion but I have yet to see (Java included) a magic bullet langauge that does all. But hey this is a very old debate isn't it.
    Absolutely. I have nothing against moving up the stack further. But I think this is not what people do with something líke Groovy. It's more like "adding another language" to your toolbox kind of thing. For the individual, this is nice (I try to at least grasp fundamentals of new and old languages time and again, hey someday I even be able to put aside enough time to learn lisp properly) - for a project is has "disaster" and "unmaintainable" written all over it.
  13. Do we need it...[ Go to top ]

    - for a project is has "disaster" and "unmaintainable" written all over it.

    Yeah, that's a difficult one isn't it!

    Maybe less so for unit tests, but that's a matter of opinion also isn't it?

    I feel though that Groovy at least has a chance of being there in the long run but I agree that large J2EE projects aren't usually good adoption grounds for new technbologies but as other folk have said let's see.

    And it does make for a nice little gizmo in the toolkit in the meantime doesn't it :-)

    Regards
    Neil
  14. Language Proliferation and $[ Go to top ]

    Here is the order of my language learning in order:

    Basic
    Turbo Pascal
    C & ASM
    C++
    Java
    PHP
    TCL
    Perl
    Python
    JPython
    C# VB.NET

    I exclude VB before .NET, VBA, JavaScript, ActionScript, and others that I really do not count as real programming languages (no real thread support or very specialized).

    I also exclude XSL, XML, HTML, and other languages that are MLs or other data formatter.

    The only language I really know well is Java even though I could pass a general test for all of the languages listed above except for Turbo Pascal maybe.

    Here are my points and questions:

    I love programming, scripting, and ML languages, but will Groovy or language X make me $?

    I want to make good money being a software engineer. How can language X do that for me?

    I have written over a million lines of code in my life, but how can I make money from Groovy that Java, C/C++ and others are unable to?

    Somewhat Off Topic Portion:

    I would be happy to learn Groovy or other language for a decent paying engineering job in the US. Do I need to move to India? What can I do? Other than becoming a plumber, an off shoring manager, or other do nothing laborer (a worker that does not automate nor create anything somewhat new or different).
  15. I love programming, scripting, and ML languages, but will Groovy or language X make me $?

    I want to make good money being a software engineer. How can language X do that for me?

    I have written over a million lines of code in my life, but how can I make money from Groovy that Java, C/C++ and others are unable to?
    If you want to make money using a language like Groovy, in my experience, chances are much better of finding a sponsor if the language is standardized. Say, as a JSR.

    My experience with Ruby is that scripting languages roughly double my productivity relative to Java (<== WARNING: Not based on real data, just gut feeling). By being more productive, you can probably make more money, if capitalism still works.

    Just my 2 cents.
  16. Language Proliferation and $[ Go to top ]

    You would only make money out of Groovy if Groovy surpassed Java. Otherwise in my business (J2EE in corporates) certainly it means nothing on your CV.

    Now that said, there are many times when working on Java applications you need a scripting language an example is if you are writing an XML based swing interface and need to add event triggers in the XML. Or if you need to conveniently and easily reconfigure application logic without a full redeployment. Or if you need a templating system. Or .... and so on.

    The question about improved productivity has to be balanced out with a strong typing fail fast mentality that is _essential_ on large J2EE projects (XP withstanding). When I'm a much more exprienced Groovy user I'll comment on that one. IMHO we need more strongly typed but less verbose (ie higher level)languages.
  17. <blockquoteIf you want to make money using a language like Groovy, in my experience, chances are much better of finding a sponsor if the language is standardized. Say, as a JSR.My experience with Ruby is that scripting languages roughly double my productivity relative to Java (<== WARNING: Not based on real data, just gut feeling). By being more productive, you can probably make more money, if capitalism still works.Just my 2 cents.I think that is a great answer.

    I think Groovy is very groovy along with J/Python, TCL, Perl, and all the others scripting languages. I also do not see the problem with the JSR submission. Further, I think that other scripting languages should do the same.

    Off Topic - Not To Be Taken Seriously By Republicans Or Democrats:

    Although, I do not think becoming more productive will make me a whole bunch of money in the US?

    I suggest that American software workers use a secret language that only they can use so their work cannot be shipped to countries with false exchange rates.

    Pulling six figures as an experienced programmer should be common place without starting my own business. Just consider the money we make for others. It is a shame that plumbers make 40K while programmers make a similar amount in the US. While programmers living in India make around 12K per year while a plumber makes about 5K. If you adjust for cost of living (~7X) the 12K is like 80K and 5K is like 35K.

    I personally decided to start my own business instead of moving to a third world country. Now that things are picking up I can continue working for myself or work for someone else, but nothing can give back the hard work I put in for no pay over the last two years. Both the Democrats and Republicans should be hanged for tyranny against hard working Americans (This excludes special subsidized workers like government employees (100% subsidized), bee farmers (75% subsidized), GM employees (15% subsidized (grants and bailout), and others even in the tech industry like Intel and Motorola (~10% (research money, regulation, and tax subsidies))).
  18. Do we need it...[ Go to top ]

    ...struggling to use JavaScript, Java and PL/SQL at the same time, doing neither very good...
    and English as well, apparently.
  19. Documentation?[ Go to top ]

    I'd really like to get to grips with Groovy but I am held back by the lack of available documentation. Hopefully the JCP will rectify this situation. Without it, it all seems a bit pointless.

    Regards
    Kit
  20. One source of Groovy documentation[ Go to top ]

    I wrote an article on Groovy that I think provides a decent introduction. You can find it at http://www.ociweb.com/jnb/jnbFeb2004.html.
  21. Wow...a scripting language that can "submit itself as a JSR" sounds like a mighty powerful language, and a bit scary I might add. I have used quite a few scripting languages that weren't very good, and I certainly hope they don't become self-aware and submit themselves for review and approval ! ;-)
  22. How does Groovy relate to JSR 223? Or does it? And if it does, why do we need this JSR?

    I found something:

    "We have considered JSR 223, and believe that while 223 is in the same problem domain, scripting, the scope and purpose is completely different than this JSR."

    , but I do not understand why the scope and purpose is completely different. Why is Groovy so different than any other scripting language? I don't know. Adding all that syntactic sugar from ruby, php, python etc., Groovy seems like just another scriting language (even if it remotely looks like Java), nothing more.

    I think that Groovy grew from frustration. Some people tried to use Java in wrong places and then they wanted easier Java. I don't know why there was a need for yet another scripting language, while there are already other mature alternatives. PHP is over 10 years old, so is Python. Groovy has a lot to catch.

    PHP seems to rule web-scripting world. Python is great allaround scripting language. XSLT is good for transformations. Where does Groovy shine over the other scripting languages? Don't say Java bindings, because that's exactly what JSR223 is all about.
  23. Just to let you know my slides (40+) from last weeks Java User Group (JUG) Austria talk titled "Groooooovy Babe: Jazzing Up Plain Old Java - Scripting Power for Java - Do More With Less (Lines of Code)" are online in an all-in-one-HTML-page version.

    The topics covered include:

    * Why Groovy? One Language Can't Do It All
    * Groovy Panorama - Servus Groovy
    * The Heroes Behind Groovy
    * Groovy Goodies Missing in Java
    * Embedding Groovy, Compiling Groovy
    * Alternative Scripting Languages for Java
    * Groovy and Ruby Books and Links
  24. Thanks, Gerald !
  25. replace jsp[ Go to top ]

    I think groovy would make jsp less attractive.
    One of the issues with generating html in java
    is java's horrible string handling. With groovy's embeddable
    strings it is much easier to generate html
    directly.
  26. Groovy don't TCL me much..[ Go to top ]

    Embeddable strings were the only elegant example I could find in the Groovy docs.. Perl, TCL, and Python are far better.. Groovy is too much like Java in the examples I read.. It is kind of an ugly and prhobitive scripting language.. clumsy and generally ineffective.. I doubt it will catch on at all.. I'd rather see TCL adapted and improved for Java... a new TCL/Tk for Swing and Eclipse would be nice... just my opinion..
  27. Hats off to see Groovy making its way into the JCP. I believe the JCP, despite its reputation for not being "fast enough", has done an excellent job of maturing the Java platform at a safe clip. Certainly there is room for a JCP-endorsed "scripting language" for Java, (too bad the name "JavaScript" is ccupied). I'm confident the JCP will do a good job of evaluating Groovy, and through its study of the language, help Groovy grow regardless of whether it is voted to continue in the process.

    WARNING, SLIGHTLY OFF TOPIC CONCERN FOLLOWS ...

    I'm more concerned at the moment with a missing submission to the JCP. Where is the "aspect oriented extensions to Java" submission? Certainly we are blessed with some excellent AOP tools for Java (AspectJ, AspectWerkz for example.) I'd like to see the JCP working on adding AOP to the Java platform as an extremely high priority.

    Why? AOP would provide for a cleaner modularization of Java's many evolving parts. We're seeing a lot of JCP specs moving forward, but what about concerns that crosscut these object models? Over time, the lack of language/platform features to address the clean seperation of these crosscutting concerns in the Java platform are making for the platform far more bloated and complex than it should be. Instrumentation and proxies are just an implementation detail, there is a more fundamental paradigm shift in AOP. Once you look at an AOP implementation of a J2EE server, like JBOSS, I think the benefits are clear. It's hard to not think "what if the J2EE spec had started its life on an AOP-based Java"? I think the result would have been simpler to understand and use.

    So, as much as I like seeing Groovy enter the JCP, it disappoints me that a more sorely needed area (AOP) hasn't left the starting gate towards standardization.

    Best wishes,
    Ben
  28. Hats off to see Groovy making its way into the JCP. I believe the JCP, despite its reputation for not being "fast enough", has done an excellent job of maturing the Java platform at a safe clip. Certainly there is room for a JCP-endorsed "scripting language" for Java, (too bad the name "JavaScript" is ccupied). I'm confident the JCP will do a good job of evaluating Groovy, and through its study of the language, help Groovy grow regardless of whether it is voted to continue in the process.
    Agreed
    WARNING, SLIGHTLY OFF TOPIC CONCERN FOLLOWS ...I'm more concerned at the moment with a missing submission to the JCP. Where is the "aspect oriented extensions to Java" submission? Certainly we are blessed with some excellent AOP tools for Java (AspectJ, AspectWerkz for example.) I'd like to see the JCP working on adding AOP to the Java platform as an extremely high priority.Why? AOP would provide for a cleaner modularization of Java's many evolving parts. We're seeing a lot of JCP specs moving forward, but what about concerns that crosscut these object models? Over time, the lack of language/platform features to address the clean seperation of these crosscutting concerns in the Java platform are making for the platform far more bloated and complex than it should be. Instrumentation and proxies are just an implementation detail, there is a more fundamental paradigm shift in AOP. Once you look at an AOP implementation of a J2EE server, like JBOSS, I think the benefits are clear. It's hard to not think "what if the J2EE spec had started its life on an AOP-based Java"? I think the result would have been simpler to understand and use.So, as much as I like seeing Groovy enter the JCP, it disappoints me that a more sorely needed area (AOP) hasn't left the starting gate towards standardization. Best wishes,Ben
    I agree that some kind of AOP JSR should be started soon; particulary to standardise how to write aspects. How things fit together & weave whether compile time / run time / proxy / bytecode modification / derived classes and so on is implementation detail and I'm not sure it must be standardized.

    However this would be a mutually exclusive JSR. You could equally well apply AOP to Java code as Groovy code as its all the same bytecode.

    James
    Core Developers Network
  29. I agree that some kind of AOP JSR should be started soon; particulary to standardise how to write aspects. How things fit together & weave whether compile time / run time / proxy / bytecode modification / derived classes and so on is implementation detail and I'm not sure it must be standardized.However this would be a mutually exclusive JSR. You could equally well apply AOP to Java code as Groovy code as its all the same bytecode.James Core Developers Network
    Personally I'm not sure that's feasible at this time. AOP is still a novel approach and I think it needs some more time in the field before it can be standardized. The problem with starting a standard right now is that we don't really know the best way to do AOP yet. You can do it through language extensions (Aspect/J), attributes and bytecode magic (latest AspectWerkz version), or interceptors (JBoss, Dynaop, Nanning). All of these approaches has their pros and cons and I'm not sure anyone hits the 80/20 sweetspot.
  30. Personally I'm not sure that's feasible at this time. AOP is still a novel approach and I think it needs some more time in the field before it can be standardized. The problem with starting a standard right now is that we don't really know the best way to do AOP yet. You can do it through language extensions (Aspect/J), attributes and bytecode magic (latest AspectWerkz version), or interceptors (JBoss, Dynaop, Nanning). All of these approaches has their pros and cons and I'm not sure anyone hits the 80/20 sweetspot.
    Wouldn't there be the possibility of multiple JSRs on this, similar to JSR 223 (scripting language interoperability for J2EE), and JSR 241 (a specific scripting language: Groovy.) ?

    Isn't there some way to partition this process so we can incrementally move towards a standardized AOP mechanism for Java? I'll be pondering this, because there has to be some way to move forward without waiting to see which specific AOP mechanism hits the sweet spot for a complete implementation.

    Best wishes,
    Ben
  31. Why?[ Go to top ]

    I thought the JCP was an org to achieve "standardisation", not one that granted blessings. What is the need for standardisation in the case of a scripting language?

    This is an example of JSR bloat. Absolutely needless. I hope Onno and the JCP team are reading this. Please raise the bar and keep it there.
  32. Why?[ Go to top ]

    What is the need for standardisation in the case of a scripting language?This is an example of JSR bloat. Absolutely needless. I hope Onno and the JCP team are reading this. Please raise the bar and keep it there.
    It appears that JSR 223 is already addressing the need of interoperability with Java and scripting languages (without mandating any specific scripting language). I also find it hard to see a need to go beyond this. Groovy should participate in JSR 223 and then make their language implementation compliant to that specification. There's no sense standardizing a specific scripting language through JCP.
  33. Why?[ Go to top ]

    What is the need for standardisation in the case of a scripting language?This is an example of JSR bloat. Absolutely needless. I hope Onno and the JCP team are reading this. Please raise the bar and keep it there.
    It appears that JSR 223 is already addressing the need of interoperability with Java and scripting languages (without mandating any specific scripting language). I also find it hard to see a need to go beyond this. Groovy should participate in JSR 223 and then make their language implementation compliant to that specification.
    I'm on the JSR 223 EG as well as JSR 241 so Groovy will completely implement the JSR 223 (which is a standard API to plugin scripting languages like PHP and JavaScript to the J2EE web container).
    There's no sense standardizing a specific scripting language through JCP.
    I don't follow your logic. Individuals & companies are embedding Groovy into their applications as a scripting engine and would like to see the language specification standardised through the JCP process so that they have a solid foundation on which to work - plus provide valueable input into the language specification process. You're more than welcome to join and help if you're interested. Otherwise don't have to use Groovy if you don't want to :)

    James
    Core Developers Network
  34. Why?[ Go to top ]

    There's no sense standardizing a specific scripting
    >> language through JCP
    >
    > I'm on the JSR 223 EG as well as JSR 241 so Groovy
    > will completely implement the JSR 223

    So, do we need JSR 242, 243... to completely implement JSR 223 for PHP, Python, Perl... ?

    > Individuals & companies are embedding Groovy into
    > their applications as a scripting engine and would
    > like to see the language specification standardised
    > through the JCP process

    Inviduals & companies embedding PHP, Python, Perl etc. into their applications do not care whether or not these languages are standardised through the JCP process (and of course they aren't). Neither should they care whether Groovy is standardised through JCP or not. I think that for Groovy there should be a GCP process, and I thought that JCP was created to improve Java, and not for introducing another language. I was wrong.

    I think that JSR 241 will somehow **** up JSR 223 by making Groovy the dominant embedded scripting language for Java.
  35. Why?[ Go to top ]

    There's no sense standardizing a specific scripting language through JCP<br>
    I'm on the JSR 223 EG as well as JSR 241 so Groovy will completely implement the JSR 223S
    So, do we need JSR 242, 243... to completely implement JSR 223 for PHP, Python, Perl... ?
    No. JSR 223 specifies an API which the scripting engines implement. JSR
    223 has no direct dependency on any other implementaiton.
    Individuals &amp; companies are embedding
    Groovy into> their applications as a scripting engine and would>
    like to see the language specification standardised through the JCP
    process
    Inviduals &amp; companies embedding PHP, Python, Perl etc. into their
    applications do not care whether or not these languages are
    standardised through the JCP process (and of course they aren't).
    They are already standardised - though via different standards bodies
    outside of the Java platform (since they are not Java). e.g. Python
    uses the PDP.
    Neither should they care whether Groovy is standardised through JCP or not.
    Of course not - since they won't be using Groovy, they'll be using PHP, Python or Perl.
    I think that for Groovy there should be a GCP process, and
    I thought that JCP was created to improve Java, and not for introducing
    another language
    I don't see why we can't use the JCP process - since its a speficiation for the Java community. JCP = Java Community Process.

    Admittedly not *all* of the community will want to use it. Some might
    like to use PHP, Python, JavaScript etc. A JSR doesn't mean that you
    *must* use it if you don't want to :)
    I think that JSR 241 will somehow **** up JSR 223 by making Groovy the dominant embedded scripting language for Java.
    Huh? JSR 223 specifies an interface that any language can implement.
    Its not gonna be possible to mess up JSR 223 for non-Groovy
    implementations.

    James
    Core Developers Network
  36. Why not?[ Go to top ]

    James,

    Thanks for your comments. While I do not agree everything you said, I got your point, and so no further questions.
  37. Why?[ Go to top ]

    would like to see the language specification standardised through the JCP process
    Where is the language specification you are currently planning to standardize? I am getting the feeling you are trying to run before you learned to walk. Maybe the specification is out there, I admit I haven't looked very hard.
  38. Why?[ Go to top ]

    I'm not entirely convinced about the need or helpfulness of the JCP in this instance and whether this is appropriate timeing, but I have to agree with James on his point about creating a JCR.

    He is making the effort to go to the appropriate standards body to standardize a language variant (somewhat like going to ANSI to standardize C++).

    The question comes down to who writes better langauges: individuals, communities or committees :-)
  39. JCP?[ Go to top ]

    I wonder if submiting it as a JSR is a good idea?

    JCP is slow. It's not transparent either. And they follow "release late, release never" apparently :-) I'd rather see a vibrant community around Groovy. Take the recently added template stuff for example. It was started by Cedric and was quickly added to Groovy core in a matter of days and the whole world had a chance to discuss it. Now imagine the same thing happening in a JCP expert group. My bet is six month at least :-) And after six month I bet we all would be surprised by the spec because we had different expectations and something totally different appeared! The quality of the expert group matters of course, but whoever is on the group it's still less than the quality of a big vibrant/diverse community.

    Ara.
  40. JCP?[ Go to top ]

    I wonder if submiting it as a JSR is a good idea?JCP is slow. It's not transparent either. And they follow "release late, release never" apparently :-) I'd rather see a vibrant community around Groovy. Take the recently added template stuff for example. It was started by Cedric and was quickly added to Groovy core in a matter of days and the whole world had a chance to discuss it. Now imagine the same thing happening in a JCP expert group. My bet is six month at least :-) And after six month I bet we all would be surprised by the spec because we had different expectations and something totally different appeared! The quality of the expert group matters of course, but whoever is on the group it's still less than the quality of a big vibrant/diverse community.Ara.
    Completely valid concerns Ara.

    The aim of the JSR is to use the JCP process to define a water tight language specification we can all use then companies can rely on it to embed groovy into their applications. The idea is for the JSR to define the language specification and for the Groovy open source project (GOSP) to be the reference implementation and TCK.

    What this means for the GOSP is we have a standards based process through which to define the language specification - which should hopefully allow us to provide a versioned, more stable language on which we can all build.

    So the open source project can remain vibrant and agile despite having a more stable language definition. i.e. the language specification might not change dramatically overnight, but the libraries & tools & extra modules can. (e.g. like the template engine).


    We hope to run the JSR in a very open fashion - using public mail lists for all discussion and allowing anyone to participate as well as all contributions to the JSR / GOSP being open sourced using a liberal BSD/ASF style licence. In addition we hope to run both the JSR and GOSP in an agile way - releasing often and performing incremental releases.

    I'm hoping this JSR could show how open and agile the JCP process can be.

    James
    Core Developers Network
  41. JCP?[ Go to top ]

    Ok relief :-) So only the language is JCP-ed and the libraries are GOSP-ed. Good strategy. Yes, I agree that the language should be kept stable and monitored.

    Let's see if you guys can handle the jsr in a transparent fashion. But generally the argument remains valid for all jsrs. All JSRs, so far, has been far from transparent. I hope the JCP guys finally find a formulla to make it more open. You know I really want to see the community more involved in the process. If something's broken in the frameworks then the community should be able to fix it itself. Take Swing for example. We all know it has lots of bugs and shortcommings and we want it fixed indeed because we sell stuff developed based on it. Currently there's no way we can easily and effectively fix something if it's broken. I don't really care whether Java is open sourced as Eric Raymond and others advocate. I don't care if it's included in GPL distros of Linux. I develope commercial software and I want to be able to fix the foundation of my software if it's broken.

    Ara.
  42. JCP?[ Go to top ]

    [... snip ...] I don't really care whether Java is open sourced as Eric Raymond and others advocate. I don't care if it's included in GPL distros of Linux. I develope commercial software and I want to be able to fix the foundation of my software if it's broken.Ara.
    Yes, agreed. This is the sweetspot for open source. For example, appservers are really painful to deploy your software in. When an open-source appserver like JBoss falls over you go in, read the code (although miserable it might be) and fix the problem. When something like WebSphere falls over all you can do is raise your hands to the sky and pray that they got their support services sorted. (And in the case of IBM... that's a big NO.)

    Luckily nowadays you get the source code for the Java standard libraries so you don't have to solely rely on what some poor technical writer chose to put into the documentation. The sorry state of the code in some parts of the JDK is quite worrying though.
  43. JCP?[ Go to top ]

    Ok relief :-) So only the language is JCP-ed and the libraries are GOSP-ed. Good strategy. Yes, I agree that the language should be kept stable and monitored.Let's see if you guys can handle the jsr in a transparent fashion. But generally the argument remains valid for all jsrs. All JSRs, so far, has been far from transparent. I hope the JCP guys finally find a formulla to make it more open. You know I really want to see the community more involved in the process. If something's broken in the frameworks then the community should be able to fix it itself.
    Totally agreed. The new JCP 2.6 process helps alot. Then the Expert Group can help further by having an OSS based policy for submissions, releasing the RI & TCK often via a liberal OSS licence and using open public mail lists for all communication so that folks outside of the EG can communicate with those inside it.

    Hopefully more JSRs can move to JCP 2.6 and become more open and agile.

    James
    Core Developers Network
  44. JCP?[ Go to top ]

    Ok relief :-) So only the language is JCP-ed and the libraries are GOSP-ed. Good strategy. Yes, I agree that the language should be kept stable and monitored.Let's see if you guys can handle the jsr in a transparent fashion. But generally the argument remains valid for all jsrs. All JSRs, so far, has been far from transparent. I hope the JCP guys finally find a formulla to make it more open. .
    Did you follow the the JSR 166 process? I was anything but non transparent, and looks like that is going to be the model for all future JSRs.

    Cheers
  45. Excerpt from http://viva.sourceforge.net/talk/jug-mar-2004/slides.html#groovy-4

    "Jython is a 100 % Java version of the Python scripting language that allows you to compile Python scripts to Java byte code that runs on any Java Virtual Machine. Jython offers seamless and smoth Java integration: from Python you can access all Java libraries, you can build applets or Java beans, you can derive from Java classes in Python and vice versa".

    IMO, that's enough.I'm a happy developer because I use Java, Python and Jython.

    And it's ill will to say Groovy is actually more learnable that Jython.
    A java programmer may effectively use Python and Jython after a couple of hours.
    I'm wrong ?

    I think Groovy is here - and perhaps will be largely used - because Java community is not open-minded enough to accept something not laid by her.

    M.M
  46. Excerpt from http://viva.sourceforge.net/talk/jug-mar-2004/slides.html#groovy-4"Jython is a 100 % Java version of the Python scripting language that allows you to compile Python scripts to Java byte code that runs on any Java Virtual Machine. Jython offers seamless and smoth Java integration: from Python you can access all Java libraries, you can build applets or Java beans, you can derive from Java classes in Python and vice versa".IMO, that's enough.I'm a happy developer because I use Java, Python and Jython.And it's ill will to say Groovy is actually more learnable that Jython.A java programmer may effectively use Python and Jython after a couple of hours.I'm wrong ?I think Groovy is here - and perhaps will be largely used - because Java community is not open-minded enough to accept something not laid by her.M.M
    Why do we get so 'religous' about these things, it's just another tool in the toolbox, isn't it?

    Btw, as someone who has used Jython and Python, have you seen it's language features? It is defintely a step forward.

    One of the things I find interesting when reading these message boards, blogs etc. is that we often get two schools of thought. One feels that progress should be from A->B in a straight line and one feels that progress evolves naturally. The people who believe in the first tend to regard diversity as wastage on the direct path of progress and the latter feel it is a neccesary part of evolution (as we see in the animal world).

    Its this same division that divides Microsoft Vs Java, Closed Vs Open Source, it's just the Ying and Yang of our industry (fades into the sunset) .....
  47. Excerpt from http://viva.sourceforge.net/talk/jug-mar-2004/slides.html#groovy-4"Jython is a 100 % Java version of the Python scripting language that allows you to compile Python scripts to Java byte code that runs on any Java Virtual Machine. Jython offers seamless and smoth Java integration: from Python you can access all Java libraries, you can build applets or Java beans, you can derive from Java classes in Python and vice versa".IMO, that's enough.I'm a happy developer because I use Java, Python and Jython.And it's ill will to say Groovy is actually more learnable that Jython.A java programmer may effectively use Python and Jython after a couple of hours.I'm wrong ?I think Groovy is here - and perhaps will be largely used - because Java community is not open-minded enough to accept something not laid by her.M.M
    Why do we get so 'religous' about these things, it's just another tool in the toolbox, isn't it?Btw, as someone who has used Jython and Python, have you seen it's language features? It is defintely a step forward.One of the things I find interesting when reading these message boards, blogs etc. is that we often get two schools of thought. One feels that progress should be from A->B in a straight line and one feels that progress evolves naturally. The people who believe in the first tend to regard diversity as wastage on the direct path of progress and the latter feel it is a neccesary part of evolution (as we see in the animal world).Its this same division that divides Microsoft Vs Java, Closed Vs Open Source, it's just the Ying and Yang of our industry (fades into the sunset) .....
    Absolutely Agreed!

    If someone wants to use PHP, Python, JavaScript or Ruby inside the Java platform then go right ahead and use the Java port. Noone's stopping you - use whatever tool you prefer.

    http://groovy.codehaus.org/faq.html#why-groovy

    The Java platform should be about choice and using the best tool for the job. Use whatever you want!

    James
    Core Developers Network
  48. Thanks for the replies.

    I know I can choose ;-), i'm just trying to understand if it's really interesting for the Java community to introduce and use Groovy as THE scripting language for Java. The discussion about the sens of a Groovy JSR is relevant.

    Be pragmatic : give me a Groovy snippet, I can't write with Jython with the same simplicity or the same powerful or which is really easier for a Java programmer.

    I know Jython is not perfect, I think It could have a better integration with Java (J2SE and J2EE). But why don't we help Jython to be improved ? can we imagine a Jython JSR (or at least asking Jython authors about that) ?

    M.M.
    Neil, believe me : I'm not "so religious" and I don't adhere to any "school of thought".
  49. Java integration[ Go to top ]

    I know Jython is not perfect, I think It could have a better integration with Java (J2SE and J2EE).
    I've taken only a brief look at both Jython and Groovy, so feel free to educate me, I've probably got some things completely wrong.

    I can pass stuff from/to Java to/from Groovy using Binding. Which is excellent: as an application developer, I can control which parts of my application I expose to Groovy scripts. I found no similar functionality in Jython, but then again - I didn't spend much time looking, and the documentation wasn't as good as Groovy's.

    Anyway, this kind of functionality is exactly the case in which a scripting language comes in handy: writing business logic/rules in a scripting language without exposing (and thus risking) too much of the application.
  50. Java integration[ Go to top ]

    I can pass stuff from/to Java to/from Groovy using Binding. Which is excellent: as an application developer, I can control which parts of my application I expose to Groovy scripts. I found no similar functionality in Jython.
    Here is Jython version of Groovy Binding snippet (http://groovy.codehaus.org/embedding.html) :

    ---
    import org.python.util.PythonInterpreter;
    import org.python.core.*;

    public class JythonBinding {
      public static void main(String []args) throws PyException {
         PythonInterpreter interp = new PythonInterpreter();
         interp.set("foo", new PyInteger(42));
         interp.exec("print 'Hello World!'; x = 123; foo * 10");
         if (((PyInteger)interp.get("x")).getValue()!=123) System.out.println("oops !!");
    }
    ---

    Embedding Jython : http://www.jython.org/docs/embedding.html.
    Anyway, this kind of functionality is exactly the case in which a scripting language comes in handy: writing business logic/rules in a scripting language without exposing (and thus risking) too much of the application.
    Python execution mode defines 2 namespaces (a local and a global) and when you execute a script or evaluate a Python expression, you can set the 2 namespaces (dictionnaries) and expose what you want. (http://www.python.org/doc/2.2/ref/execframes.html)
  51. Absolutely Agreed!If someone wants to use PHP, Python, JavaScript or Ruby inside the Java platform then go right ahead and use the Java port. Noone's stopping you - use whatever tool you prefer.http://groovy.codehaus.org/faq.html#why-groovyThe Java platform should be about choice and using the best tool for the job. Use whatever you want!James Core Developers Network
    So what is the status of Jelly? Where would you use Jelly instead of Groovy? Is Jelly dead?

    My issue with this JCP is that there are other more established and mature competitors in this space, and, I'm sorry, I always thought Jelly was a silly idea, and now you've dropped it for a new shiny toy. Tell me why I should think this won't be abandoned too?
  52. Why?[ Go to top ]

    Like several other responders, I'm not sure why we need this.

    I'm not against standardizing a scripting language, but surely it's better to standardize something that's well known and proven, rather than an unknown half-formed language. There seem to be lots of candidates out there. One that's heavily used in the Java community, and hasn't been mentioned in these discussions, is Ant. I know it's currently seen as a build language, but it's very powerful and easily extended to just about anything.

    One thing I dislike about Groovy is its syntax -- similar to Java but annoyingly different. Keeping the distinctions clear is going to be a pain. I know you can make the same argument about Java and C++, and that's exactly my point. Having made the switch, I now program very comfortably in Java, but when I have to switch between the two I spend too much time thinking about syntax issues.
  53. Why?[ Go to top ]

    Tony, what particularly didn't you like about the syntax?
    If it is the same as java then it won't be
    any different :-) It seems inline with other
    scripting languages and some it would be nice
    in java.
  54. Why?[ Go to top ]

    The problem is that it's similar, but not the same as Java. There seem to be subtle, and not so subtle, differences -- string handling, for example. Personally, I find it annoying to have to think about such things. When one is familiar with a language, it becomes second nature and you can spend your time thinking about the problem you are trying to solve, not how to code the correct syntax.

    I find Java very natural and elegant in that respect. C++ was also good in the early days, before the language lawyers got to it!

    Maybe others have different experiences -- I can only speak for myself.
  55. Groovy vs. BeanShell[ Go to top ]

    I use in my applications BeanShell. Is Groovy better ? Is there some comparison sheet ?