Groovy and its bugs

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Groovy and its bugs

hans_d
Administrator
Using Groovy for real projects means one is still an early adopter.  
The installbase is growing immensely but the usage of Groovy for  
larger projects is right now still rather small. The likelihood to  
run into severe bugs is high. If people decide which language to  
choose this is definitely a very important issue. Therefore I think  
it is crucial how the Groovy team reacts to critical bugs. For me it  
is perfectly OK to be in the role of an early adopter. I have spend a  
significant amount of my time for bug evaluation and reporting in the  
last couple of months, even if the bugs I have discovered were not  
relevant for my project. That has been my way to contribute to the  
health of Groovy. But early adopters need the trust that if they hit  
upon a critical bug, the Groovy team will make dealing with such bugs  
the HIGHEST priority. This is my understanding  
of best practices. I definitely are going to handle it that way for  
Gradle.  Others of my favorite projects behave exactly this way.  
Immediately dealing with critical bugs means not necessary fixing  
them. It means first of all evaluating them and then either discuss  
whether they are really critical and whether there are workarounds.  
But of course if possible fixing them. Some bugs involve deeper  
changes which can't be done immediately but then this should be  
communicated soon.

I have reported a critical bug 10 days ago. If someone uses  
metaprogramming for Scripts, Closures don't work properly within  
them. For a language where a major use case are DSL's this is VERY  
critical in my opinion. Jim had a look at it and said he made my  
attached test case work for him, but unfortunately I can't reproduce  
it. The bug is still not assigned. For my release this is a complete  
blocker. I'm pretty frustrated. Of course I could start to fix it  
myself. Considering the steep learning curve of Groovys  
metaprogramming implementation this looks not very efficient.

- Hans



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Groovy and its bugs

hans_d
Administrator
Uups, that was the wrong list :)

- Hans

On Mar 8, 2008, at 8:52 AM, Hans Dockter wrote:

Using Groovy for real projects means one is still an early adopter. The installbase is growing immensely but the usage of Groovy for larger projects is right now still rather small. The likelihood to run into severe bugs is high. If people decide which language to choose this is definitely a very important issue. Therefore I think it is crucial how the Groovy team reacts to critical bugs. For me it is perfectly OK to be in the role of an early adopter. I have spend a significant amount of my time for bug evaluation and reporting in the last couple of months, even if the bugs I have discovered were not relevant for my project. That has been my way to contribute to the health of Groovy. But early adopters need the trust that if they hit upon a critical bug, the Groovy team will make dealing with such bugs the HIGHEST priority. This is my understanding of best practices. I definitely are going to handle it that way for Gradle.  Others of my favorite projects behave exactly this way. Immediately dealing with critical bugs means not necessary fixing them. It means first of all evaluating them and then either discuss whether they are really critical and whether there are workarounds. But of course if possible fixing them. Some bugs involve deeper changes which can't be done immediately but then this should be communicated soon.


I have reported a critical bug 10 days ago. If someone uses metaprogramming for Scripts, Closures don't work properly within them. For a language where a major use case are DSL's this is VERY critical in my opinion. Jim had a look at it and said he made my attached test case work for him, but unfortunately I can't reproduce it. The bug is still not assigned. For my release this is a complete blocker. I'm pretty frustrated. Of course I could start to fix it myself. Considering the steep learning curve of Groovys metaprogramming implementation this looks not very efficient.


- Hans