Discussions

News: Groovy 1.0 has been released

  1. Groovy 1.0 has been released (45 messages)

    Groovy 1.0 has been released. From Groovy's home page, Groovy is a dynamic language for the JVM that integrates seamlessly with the Java platform. It offers a Java-like syntax, with language features inspired by Smalltalk, Python or Ruby, and lets your reuse all your Java libraries, and it's the language used in the Grails web application framework. Groovy's an interesting language. In some ways, it greatly simplifies operations compared to Java, making them far less wordy, but in the process gains some of perl's weaknesses - namely, chaotic syntax for the uninitiated.

    Threaded Messages (45)

  2. Why did it take forever for Groovy to go from concept to a release? I can't remember exactly when the word "Groovy" was coined, but it seems earlier than 2003 or something. Is it going to be part of Mustang? Will Sun ship both java and groovy compilers as part of the JDK7?
  3. Uhm, no. Most bloggers who posted about groovy being released are either developers or ex-developers of it, interestingly enough. Few users really care, I suspect. Groovy has gone from being an interesting and potentially exciting project, to a 'good lord, how complicated can this possibly be?' kind of project, with a handful of people knowing to REALLY use it, and rest left flailing about with docs to try and decipher its perplexing behaviour. I can't imagine anyone would be stupid enough to think that including it in ANY JDK is anything but cruel and unusual.
  4. ???[ Go to top ]

    I suspect you haven't used Groovy in a while. I am not a developer but I am a user and Groovy's documentation and implementation have come a long way. They've worked very hard to make Groovy a top notch product. I found Groovy to be quite natural and actually refreshing coming from "why does this have to be so hard" Java. Once you learn the conventions and get used to working with a dynamic language it is great.
  5. Re: Groovy 1.0 has been released[ Go to top ]

    Uhm, no.

    Most bloggers who posted about groovy being released are either developers or ex-developers of it, interestingly enough. Few users really care, I suspect.
    Don't suspect - research. There is much more interest in Groovy (and particularly Grails) than you apparently realise. Sure, it is nothing like Rails, but certainly not 'few users'.
    Groovy has gone from being an interesting and potentially exciting project, to a 'good lord, how complicated can this possibly be?' kind of project, with a handful of people knowing to REALLY use it, and rest left flailing about with docs to try and decipher its perplexing behaviour.
    Oh come on. There is quite a bit of fiddly stuff in Groovy, but you can use it with what is basically Java 1.4 syntax. How is that supposed to require deciphering or be perplexing? I can be used pretty much like BeanShell - would you say people flail about using that?
    I can't imagine anyone would be stupid enough to think that including it in ANY JDK is anything but cruel and unusual.
    I am THAT stupid! I freely admit it. I think having a dynamic version of Java bundled in a JDK (providing decent debugging was there as well) is a great idea.
  6. Re: Groovy 1.0 has been released[ Go to top ]

    I was looking at the sample chapters for the book. Looks like I have another book on my list. Merry belated Christmas to me. :)
  7. Bile not...[ Go to top ]

    I'm always astounded that people bash groovy this way. What right do you have to expect anything from them. They told you it was under development and suddenly you and everybody else telling them what they have now isn't ready? What exactly makes you think that groovy owes you anything? What do you care how "complicated" the project is? You aren't on the team, but you are bashing them for things that only matter to those on the team. If you were expecting it to be 1.0 level before it was, then the problem was your expectations. If you have specific language complaints that are present in 1.0, then feel free to discuss them, but on the other hand if you had anything this specific you would have already aired it. Instead all you have is vague spew about how a pre-release language was "complicated". Yeah, no kidding. Maybe you'd be happier with perl6 and parrot?!?!?!
  8. Re: Bile not...[ Go to top ]

    Zing!
  9. Re: Groovy 1.0 has been released[ Go to top ]

    I've been using groovy for a while and it seems to be a pretty good language. I have implemented some scripts using COM integration, AntBuilder and SwingBuilder and these are definitely among the features I like the most. It is really amazing how fast you can create UI prototypes using SwingBuilder. The only issue I had was about compatibility, since there was some syntax changes along the way. BTW, congratulations to the development team and thank you for providing us with such a good piece of software.
  10. Goovy in the bundle.[ Go to top ]

    I wouldn't mind a decent scripting language bundled in be it Groovy or some other JVM-compatible language. It is so hard to get some technologies inside conservative corporations unless they are forced to take it with another upgrade they want. For example, the only reason we got Java 1.5 was because they wanted to switch to JBoss/Linux. The only "approved" scripting language is perl 5. Yuck. The only reason we have Spring is because someone sold them on it as a transaction manager. I was bitten by the early hype of Groovy - was expecting it a bit sooner like many others and then dropped it from my interest list for the last year or so. Congrats on getting the 1.0 out though, I'll probably check it out soon.
  11. 3.5 years isn't quite "forever"[ Go to top ]

    Languages take quite a long time. Ruby took 10 years before it was discovered by bloggers. JRuby was started before Groovy and is still not at 1.0. Groovy (unlike Jython and JRuby) involved developing the language as well as the implementation. I think programming languages are, in one respect, like sausages - if you want to enjoy the end product don't look too closely at the way they are made:) Groovy has been in production use in at least one large US corporation for over 12 months and there are two books available this month. The hype at the beginning was quite damaging to the project - I think we were rather conservative in declaring the 1.0 release because we didn't want to repeat the original nonsense.
  12. Re: Groovy 1.0 has been released[ Go to top ]

    Is it going to be part of Mustang? Will Sun ship both java and groovy compilers as part of the JDK7?
    It won't be: JDK7 will have some new bytecode instructions that are desireable for dynamic "scripting" languages to exectue more quickly. I suspect that JDK8 will be the target release for this and the beanshell JSR. I think you will start to see useful stuff surrounding groovy over the next year. The language has a lot of potential, and I think it represents a superior solution to ruby in a number of areas because of it's ability to seamlessly interoperate with java. Especially in the enterprise arena where so much functionality exists in java now that can be leveraged.
  13. Please, not in the JDK[ Go to top ]

    I wish people would stop asking for more stuff in the JDK! The JDK is intended to run java byte code and that's it. Period. If you do not agree, please look at the JAXB versioning debacle. By including it in the JDK, JAXB is suddenly no longer a viable solution; you never know what version you are running as the developer rarely gets to decide which JDK to run. Another example: I was involved in a project where we could not switch to Java 1.4 because of large changes in the JDBC interfaces. Bummer. So please don't kill Groovy by putting it in the JDK.
  14. Re: Please, not in the JDK[ Go to top ]

    I wish people would stop asking for more stuff in the JDK! The JDK is intended to run java byte code and that's it. Period.
    That is surely the JVM, not the JDK.
    If you do not agree, please look at the JAXB versioning debacle. By including it in the JDK, JAXB is suddenly no longer a viable solution; you never know what version you are running as the developer rarely gets to decide which JDK to run.
    Firsly, many additions to later JDKs are back-ported to earlier versions. Secondly, just because an implementation of an API is present in a JDK or JRE, this does not prevent you from using alternative implementations of that API.
    Another example: I was involved in a project where we could not switch to Java 1.4 because of large changes in the JDBC interfaces. Bummer.
    Changes in the JDBC interfaces which were not backwardly compatible? Really?
  15. Re: Please, not in the JDK[ Go to top ]

    The JDK is intended to run java byte code and that's it. Period.

    That is surely the JVM, not the JDK.
    Well, how do you get the JVM? By downloading the JDK. Right? The point is that there will be environments in which you can not just assume that putting a jar on your classpath will do the expected thing.
    Firsly, many additions to later JDKs are back-ported to earlier versions. Secondly, just because an implementation of an API is present in a JDK or JRE, this does not prevent you from using alternative implementations of that API.
    1) is a solution to a problem you do not have when you just let people put stuff on the classpath themselves so this is a non-argument. 2) I agree, but it does make it quite a but harder. For each potential target JVM you have to include installation instructions with your product.
    Another example: I was involved in a project where we could not switch to Java 1.4 because of large changes in the JDBC interfaces. Bummer.
    Changes in the JDBC interfaces which were not backwardly compatible? Really?
    We admittedly did a weird thing: we implemented the Connection interface ourselves. In JDBC version 4 that interface showed an incredible growth in size. So even though JDBC4 was backward compatible, we could not use the newer JVM (without major refactoring) because JDBC was now tied to it.
  16. Re: Please, not in the JDK[ Go to top ]

    Well, how do you get the JVM? By downloading the JDK. Right? The point is that there will be environments in which you can not just assume that putting a jar on your classpath will do the expected thing.
    That is the case whether things are bundled with the JRE or not.
    2) I agree, but it does make it quite a but harder. For each potential target JVM you have to include installation instructions with your product.
    You can't have it both ways - complain about things bundled with the JRE, then complain about what you have to do if they aren't.
    We admittedly did a weird thing: we implemented the Connection interface ourselves. In JDBC version 4 that interface showed an incredible growth in size. So even though JDBC4 was backward compatible, we could not use the newer JVM (without major refactoring) because JDBC was now tied to it.
    So don't implement JDBC version 4 - there is no requirement to implement all those features, and JDBC is not tied to that version - it surely only increases what you are able to implement, not what you have to. Unless you mean you actually wrote your own version of 'java.sql.Connection'. Which is really not advisable.... and would cause all sorts of problems.
  17. Re: Please, not in the JDK[ Go to top ]

    The point is that there will be environments in which you can not just assume that putting a jar on your classpath will do the expected thing.
    That is the case whether things are bundled with the JRE or not.
    I am not sure what kind of JVMs you use, but when I put a regular jar on the classpath this just works 99.9% of the time and on any JVM.
    2) I agree, but it does make it quite a but harder. For each potential target JVM you have to include installation instructions with your product.
    You can't have it both ways - complain about things bundled with the JRE, then complain about what you have to do if they aren't.
    Huh? I am complaining about what you have to do when a (potentially) wrong version of a jar is (potentially) already bundled. Too many variables here.
    Unless you mean you actually wrote your own version of 'java.sql.Connection'. Which is really not advisable.... and would cause all sorts of problems.
    Unfortunately, that is exactly what we did. I am not proud of it, but it did prove my point :(
  18. Re: Please, not in the JDK[ Go to top ]

    2) I agree, but it does make it quite a but harder. For each potential target JVM you have to include installation instructions with your product.
    You can't have it both ways - complain about things bundled with the JRE, then complain about what you have to do if they aren't.

    Huh? I am complaining about what you have to do when a (potentially) wrong version of a jar is (potentially) already bundled. Too many variables here.
    You were complaining about the version of something that is bundled with the JDK. And also about what you would have to do if things weren't bundled (including installation instructions).
    Unless you mean you actually wrote your own version of 'java.sql.Connection'. Which is really not advisable.... and would cause all sorts of problems.

    Unfortunately, that is exactly what we did. I am not proud of it, but it did prove my point :(
    Sorry if this sounds harsh, but I don't think it does. I think it shows what happens when you don't follow the guidelines of how to write portable Java code. Replacing java.* packages yourself is way up there in the 'what not to do' list.
  19. Re: Please, not in the JDK[ Go to top ]

    Ahh, more and more misunderstandings. Please read carefully.
    You were complaining about the version of something that is bundled with the JDK.
    Correct.
    And also about what you would have to do if things weren't bundled (including installation instructions).
    Not correct. See my previous post(s).
    Replacing java.* packages yourself is way up there in the 'what not to do' list.
    Of course I did not replace the java.sql.Connection interface, I only implemented one. I read your text "wrote your own version of.." as "wrote your own implementation of...".
  20. Re: Please, not in the JDK[ Go to top ]

    Ahh, more and more misunderstandings. Please read carefully.
    I'll do my best.
    Replacing java.* packages yourself is way up there in the 'what not to do' list.
    Of course I did not replace the java.sql.Connection interface, I only implemented one. I read your text "wrote your own version of.." as "wrote your own implementation of...".
    There seems to me to be two alternatives here: 1. You replaced java.sql.Connection. 2. You implemented java.sql.Connection. (1) Would cause all kinds of problems. Apparently you have not done that. (2) Should not, as you don't have to implement all the features of, say, JDBC 4.0. All you have to do is implement a version then indicate that version in the metadata. So, I am confused about how things could go bad switching to a version of Java with allowed JDBC 4.0, as many, many people are still implementing and running pre 4.0 versions of JDBC on those platforms.
  21. Re: Please, not in the JDK[ Go to top ]

    Unfortunately, that is exactly what we did. I am not proud of it, but it did prove my point :(
    LOL. We've all got code skeletons in our closet.
  22. Re: Please, not in the JDK[ Go to top ]

    The JVM represents the majority of java's contributions to moving programming forward: JIT optimizations that can beat statically compiled code Hardware abstraction and true run-anywhere (for server code at least) Garbage collection Large standardized library What does any of that have to do with the Java language? Java is showing its age, while the JVM is still one of the most powerful technologies in modern programming? dotNET's only advantage over the JRE/JVM is its language flexibility. I seriously doubt the bytecode features added to the JVM to support language independence will hamstring its performance. Meanwhile, we get scripting capabilities, type-loose programming languages to go with Java's strict typing, and perhaps enable even better languages such as a smalltalk derivative. Your comment smacks of a close-minded single-language developer...
  23. Groovy fits perfectly the JVM, it is built from the ground to tightly integrate with the Java environment, while JRuby is still in its infancy on respect of performances and JVM integration. As others scripting languages its success will depend more on available tools and good IDEs integration, as one can be more productive with plain Java thanks to Eclipse or Netbeans ease of development, code completion and refactoring. If those IDEs will provide good language support, scripting languages like Groovy, JRuby or Jython will gain popularity at the enterprise level also. Maybe the fact that Groovy is newer and doesn't need to deal with much legacy code as Python and Ruby could represent an advantage in the long run, but it is necessary to add some mass to the users community.
  24. Why not BeanShell?[ Go to top ]

    Would Java itself not be a scripting language? Why Groovy, jRuby, or others? It is nice to use single language in a project, isn't it?
  25. Because Groovy is a dynamic language[ Go to top ]

    Bean Shell is a perfectly adequate scripting language. However it is, like Java, a static language. Groovy, Jython and JRuby are dynamic languages. In Groovy we can and do dynamically add properties and methods to classes. This allows us to do so much more that glue bits of Java together. One of the strengths of Groovy and the other dynamic languages is the ability to extend them to build Domain Specific Languages to make certain common tasks easy to perform - go to the Groovy site and look at how we have great ways of producing and consuming XML (GPath and Builders).
  26. In Groovy we can and do dynamically add properties and methods to classes.
    That's not really exclusive to dynamic languages. Boo is a type-inferred, statically typed language that allows you to declare a variable as dynamic. http://boo.codehaus.org/Part+18+-+Duck+typing
    This allows us to do so much more that glue bits of Java together. One of the strengths of Groovy and the other dynamic languages is the ability to extend them to build Domain Specific Languages to make certain common tasks easy to perform
    Building DSLs has nothing to do with if a language is dynamically or statically typed. Boo has macros. http://boo.codehaus.org/Part+17+-+Macros I'm not dogging on Groovy, and congratulations to the Groovy team, but I'm just wondering what the real advantages of dynamic typing is, because I just don't see it. I wish Boo was available for the JVM.
  27. It's not just about dynamic typing, but it's also about the fact method dispatch, property access, etc, are done at runtime. That's the real dynamic aspect of dynamic languages and why they are called that way. You can have dynamic/runtime addition of methods or properties or change the behavior of your classes because those things are done at runtime and not at compile-time. It's not related to non-static typing -- since Groovy also supports static typing anyway.
  28. It's not just about dynamic typing, but it's also about the fact method dispatch, property access, etc, are done at runtime. That's the real dynamic aspect of dynamic languages and why they are called that way. You can have dynamic/runtime addition of methods or properties or change the behavior of your classes because those things are done at runtime and not at compile-time. It's not related to non-static typing -- since Groovy also supports static typing anyway.
    Question - If I write a Groovy class and specify static type information, and then write some other Groovy code that uses the class and has statically type variables, will the generated bytecode be comparable to the bytecode generated from similar code written in Java? Meaning will it recognize the fact that it doesn't need to use dynamic method invocation because virtual method invocation will work, and generate appropriately optmized bytecode? How about compile-time checks. So I have a statically typed method receiving a statically typed variable of an incorrect type as a parameter - will it catch it? If Groovy will do all the optimizations and checks when information is available, while freeing the coder to write much looser dynamic code when he chooses, it seems like Groovy could be the best of both worlds between static and dynamic languages.
  29. If you statically type fields, return values or parameters then the bytecode generated will be identical to Java. So Groovy objects can be used from Java with no magic. Also Groovy objects can implement Java interfaces. Basically from the Java viewpoint all Groovy classes are Java classes. Untyped data just appears as things of type Object. Groovy always does dynamic dispatch even if the method or field is statically typed. We need to do this because Groovy is a Dynamic language not just a Dynamically typed language. So we can modify the behaviour of a class at run time and so the compiler can never be sure what the target of a call is. However, because you can subclass Groovy classes with Java classes it is possible to produce an object which has some methods which do dynamic dispatch and some methods which do static dispatch. So some methods are very flexible and some run at full Java speed and do all the Java compile time checks.
  30. Some Groovy questions[ Go to top ]

    If you statically type fields, return values or parameters then the bytecode generated will be identical to Java. So Groovy objects can be used from Java with no magic. Also Groovy objects can implement Java interfaces. Basically from the Java viewpoint all Groovy classes are Java classes. Untyped data just appears as things of type Object.

    Groovy always does dynamic dispatch even if the method or field is statically typed. We need to do this because Groovy is a Dynamic language not just a Dynamically typed language. So we can modify the behaviour of a class at run time and so the compiler can never be sure what the target of a call is.

    However, because you can subclass Groovy classes with Java classes it is possible to produce an object which has some methods which do dynamic dispatch and some methods which do static dispatch. So some methods are very flexible and some run at full Java speed and do all the Java compile time checks.
    Man, didn't know that Groovy could be statically typed. This is why I always I never bother to look at scripting languages as dynamic typing makes it real hard to do refactoring and maintenance sucks. Beyond DSL, I can now see why Gavin wanted Groovy to be the main scripting engine for Seam.... BTW, did anybody ever think about stripping down Groovy so that we just have Dynamic Java? Having written an AOP framework, I had to jump through hoops and always ran into brick walls when trying to implement AOP features. Does Groovy support JDK5 annotations? Would be interesting if we could get a groovy class that was deployable by EJB3 and JPA containers. Bill
  31. Re: Some Groovy questions[ Go to top ]

    We haven't really considered Dynamic Java. Groovy is very nearly a proper subset of Java. We have changed the semantics of == because everything in Groovy is a an object (e.g. 1.toString() works) and the Java semantics of == are not useful when everything's an object. We don't have the standard Java for loop - we just haven't got round to implementing it. We don't allow stand alone blocks - problems with confusion with closures. New Groovy programmers coming from Java start of writing almost pure Java until they pick up on the extra features - closures are the things which change people's lives. We have some annotation support - we recognise the notation and add information to the class file - I'm not quite up to speed with the details - pop into the mailing list and ask you will get a definitive answer there.
  32. Re: Some Groovy questions[ Go to top ]

    New Groovy programmers coming from Java start of writing almost pure Java until they pick up on the extra features - closures are the things which change people's lives.
    This is why I think Groovy will be a major success; because it can be adopted gradually - there is no big leap to new syntax and new libraries as with JRuby. There is still a bit of work to be done, such as support for Java 5 features, and to provide debugging and IDE support (NetBeans, please!), but I think Groovy has a good future as an increasing number of developers realise the full power and flexibility of the language. Guillaume deserves a lot of praise for the effort and energy that he has put into the Groovy project, as do the rest of those involved.
  33. Re: Some Groovy questions[ Go to top ]

    I was interested into Groovy a year ago, then I lost interest, but now 1.0 is out I will look again into it. From what I have seen the language has become excellent although somewhat feature laden, partially caused due to the syntax migration path embedded into the language. But I must say it is a serious contender for becoming the scripting language of choice on the JVM. All it needs is annotation support then most people probably are happy with it. It could become the language of choice for bean definitions and orm mapping class definitions in the long run due to its clean and excellent property handling (no more setters and getters unless needed)
  34. Re: Some Groovy questions[ Go to top ]

    Groovy 1.0 supports annotations but does not support RetentionPolicy.RUNTIME. This means that tools can read the annotation data from the class file but you can't introspect the Class instance and get annotation data at run time.
  35. Re: Some Groovy questions[ Go to top ]

    BTW, did anybody ever think about stripping down Groovy so that we just have Dynamic Java? Having written an AOP framework, I had to jump through hoops and always ran into brick walls when trying to implement AOP features.
    Personally, I'd really like to see Groovy become more of a superset of Java. I think there's to large of a push to keep on extending Java (the language) and eventually, even if the new Java is a great language, too many of the things that have made Java successful will be lost. Instead, keep on pushing the JVM forward, and let a new language that at the bytecode and standard library level has little to no impedance mismatch with Java embrace all the new language features.
  36. Re: Some Groovy questions[ Go to top ]

    BTW, did anybody ever think about stripping down Groovy so that we just have Dynamic Java? Having written an AOP framework, I had to jump through hoops and always ran into brick walls when trying to implement AOP features.


    Personally, I'd really like to see Groovy become more of a superset of Java. I think there's to large of a push to keep on extending Java (the language) and eventually, even if the new Java is a great language, too many of the things that have made Java successful will be lost.

    Instead, keep on pushing the JVM forward, and let a new language that at the bytecode and standard library level has little to no impedance mismatch with Java embrace all the new language features.
    +1
  37. Re: Some Groovy questions[ Go to top ]

    BTW, did anybody ever think about stripping down Groovy so that we just have Dynamic Java? Having written an AOP framework, I had to jump through hoops and always ran into brick walls when trying to implement AOP features.


    Personally, I'd really like to see Groovy become more of a superset of Java. I think there's to large of a push to keep on extending Java (the language) and eventually, even if the new Java is a great language, too many of the things that have made Java successful will be lost.

    Instead, keep on pushing the JVM forward, and let a new language that at the bytecode and standard library level has little to no impedance mismatch with Java embrace all the new language features.
    +2
  38. Re: Some Groovy questions[ Go to top ]

    Does Groovy support JDK5 annotations? Would be interesting if we could get a groovy class that was deployable by EJB3 and JPA containers.

    Bill
    Not yet, and that's one thing I'm looking forward to. The last time I looked at the RoadMap it was some time post 1.0, but it was there. The idea of writing some objects like JPA persisted objects and even web actions complete with annotations in Groovy is very appealing. But right now you can't.... -Tim Fennell Stripes: Because web development should just be easier.
  39. Re: Why not BeanShell?[ Go to top ]

    Would Java itself not be a scripting language? Why Groovy, jRuby, or others? It is nice to use single language in a project, isn't it?
    You could make that argument and probably very well in most cases. There are many situations where a looser scripting language can be handy: Prototypes, business rule code, unit tests and tests in general, mark-up, config in some cases, regular expression code, and cases where you want to dynamically swap out business logic. If you are good at Java, I'm guessing you could be come more than proficient in Groovy in less than a day so the overhead of learning something new is pretty low. While I could make lemonade out of lemons if a scripting language was bundled into the JDK (see earlier post), in reality I think it is a bad idea to keep doubling its size with every release instead of promoting plug-in libraries.
  40. What happened to JSR-241?[ Go to top ]

    JSR-241 on Groovy was started in early 2004, but there is nothing on the JSR page to indicate progress. Can someone from the project comment on this?
  41. Re: What happened to JSR-241?[ Go to top ]

    JSR-241 on Groovy was started in early 2004, but there is nothing on the JSR page to indicate progress. Can someone from the project comment on this?
    A few months ago, I've been nominated Spec Lead of the JSR when James Strachan left the project. So far, as we are more programmatic language agilists than theoretical language implementors, we focused on delivering a language that Java developers can use instead of writing a pure specification first. As you probably know, a JSR is composed of three key elements: a specification (GLS: Groovy Language Spec), a Reference Implementation (RI), and a Test Compatibility Kit (TCK). Now that the Reference Implementation is out (Groovy 1.0), we have to fork and expand the test cases we use to test our RI to make them the official Test Compatibility Kit. Along the way, we are going to take our language spec outline and fill in the gaps. We also already publish online the diagrams of the Groovy grammar -- not up-to-date yet.
  42. Now that the Reference Implementation is out (Groovy 1.0), we have to fork and expand the test cases we use to test our RI to make them the official Test Compatibility Kit.

    Along the way, we are going to take our language spec outline and fill in the gaps. We also already publish online the diagrams of the Groovy grammar -- not up-to-date yet.
    In this case you can't call Groovy 1.0 "final release"! Let's remember two MyFaces announcements:
    April 9, 2005 - MyFaces 1.0.9 has been released
    MyFaces 1.0.9 (final) is now available here.
    and
    April 16, 2005 - MyFaces 1.0.9(m9) has been released
    MyFaces 1.0.9(m9) is now available. The (m9) stands for milestone 9. The license agreement covering JSF and all other JCP based specifications require that we use this terminology and avoid the word "final." Once MyFaces passes the TCK we will be able to refer to our releases as final. This is one of the reasons why we initially pulled the release announcement from the website a few days ago. But the release is official now and is available through your nearest Apache mirror. Enjoy!
    So, you have to make clear decision is Groovy 1.0 related to JSR-241 or not. Nebojsa
  43. So, you have to make clear decision is Groovy 1.0 related to JSR-241 or not.
    I think you are confusing an implementation of a standard with the standard itself. Like PL/1, C, C#, JavaScript and BeanShell Groovy is being standardised after the first production release of its implementation. The JSR process provides us with a mechanism for producing a high quality standard which must be approved by thier parties and provides the possibility of more than one implementation. The 1.0 release means that we think that the language spec is stable and code base is production ready.
  44. So, you have to make clear decision is Groovy 1.0 related to JSR-241 or not.


    I think you are confusing an implementation of a standard with the standard itself.

    Like PL/1, C, C#, JavaScript and BeanShell Groovy is being standardised after the first production release of its implementation.
    The JSR process provides us with a mechanism for producing a high quality standard which must be approved by thier parties and provides the possibility of more than one implementation.

    The 1.0 release means that we think that the language spec is stable and code base is production ready.
    You are trying to say that Groovy 1.0 is JSR reference implementation and Groovy 1.0 is final release, but Groovy 1.0 is not final reference implementation. This is source of confusion. BTW, K&R C is not an implementation of ANSI C. What I am worried about is that Groovy team doesn't consider language specification important enough. Nebojsa
  45. I've played around with Groovy a bit and would be very excited about using it to further simplify my work. However lack of runtime annotation support means that it doesn't work with any of my annotation based frameworks. Hibernate Validator, Seam, EJB 3, JPA. Sure, if I tried I could probably get some of these frameworks to work with Groovy using their XML configuration mechanisms, but annotations are what we're using and I'm not looking to make more work for myself. Another barrier to adoption is the current level of tooling support. At last check there was an Eclipse plugin that offered some syntax highlighting, but no code completion at all, even for standard classes, let alone the groovy add-on methods. With these improvements I can see Groovy getting a lot more eyes. Oh, and if you have time, please add support for Java's for loops. I can't believe that something that appears to be such a great extension to Java doesn't allow for(int i=0;check;i++) syntax. Closers you have, cut and paste code migration you don't?
  46. Though we've had already a start at annotation support, we don't fully support them at the moment, as John Wilson said earlier. But the infrastructure is there for fully supporting them, including, of course, runtime retention policy. Full Annotation support is on our agenda and should be implemented pretty soon in priority. It's one of the most requested feature. As to the Eclipse plugin, it has improved a lot lately with even a start at basic code completion for typed variables, and the structure is there to also add the GDK methods as well. Tool support is a very important aspect of our work in 2007!