Groovy Gains Big Sky Sponsorship and aboutGroovy Portal
"Jochen will be able to focus his efforts exclusively on Groovy development now which will help ensure that Groovy 1.0 is released the end of 2006 and future enhancements in Groovy will be addressed at an accelerated rate", commented Jay Zimmerman, President of Big Sky Technology and creator/director of the No Fluff Just Stuff Java Symposium Series. When asked why Big Sky Technology has stepped up to fund this initiative in the Groovy space, Zimmerman commented: "The NFJS Symposium series has always been a big advocate of the open source community from its inception in 2002. Over the last five years we have seen the pain points in the Java space from our conversations with NFJS attendees which for the most part are corporate developers. With Groovy we have decided to take a more activist role by directly supporting ongoing Groovy development as we see great benefits to the Java development community namely addressing unit testing, streamlining XML usage, better ORM support, and being able to take advantage of Groovy's dynamic language features like closures.
Zimmerman also noted that the NFJS will be offering a full Groovy track at events in 2007.
Also on the Groovy front the portal aboutGroovy.com was announced this month:
aboutGroovy.com -- your source for news about the programming language Groovy. In the days and weeks to come, aboutGroovy.com will bring you the best of news, tutorials, and rich media from across the Internet. Welcome aboard!
So many reasons.....Theodorou was then asked what was on his list to improve in Groovy now that it is his full time focus:
One, Groovy 1.0 will be out 1st week of January and ready for prime time use.
Two, Groovy gets rid of a lot of the verbosity found in straight Java code. Scott Hickey said it best, "Groovy's concise, yet flexible syntax frees developers from normal Java constructs that are required for code compilation but don't necessarily help express what the program is really trying to accomplish. What's more, Groovy's relaxed typing removes perceived code complexity through the reduction of interfaces and super classes, which are required in normal Java applications to support common behavior among distinct concrete types. "
Three, Java developers can become productive in a very short amount of time with Groovy due to the familiar syntax and on a practical level, developers can inject Groovy code into their for applications immediately without having to fight the internal political battle with upper technical management regarding the merits of another language and the accompanying learning curve which goes with it.
Improvement of the documentation - Not all methods are documented and there is a need for writing a document about the internal dos and don'ts, structures and goals, ideas and implementation technics. I started with that a while back ... but it should be more than just a paragraph =).
Make it a real JSR - That means writing a spec and a test test compatibility kit (tck).
Build system - The current build requires maven 1.0.2 (exact version) so we are thinking about migrating to Gant, our upcoming Groovy based build tool.
Performance - 1.0 had many internal changes allowing a better way to improve the performance in following releases. One such improvement is to have new MetaClasses for special types like Maps, Closures, instances of GroovyObject... we will experiment with code generation during runtime here to get performance to the maximum level.
Java5 language support - enums and annotations are high on our list, because more and more tools out there do need them.
Finally, Zimmerman was asked how the AboutGroovy.com portal come into being:
We wanted to see a central place for all Groovy/Grails related content (articles, presentations, interviews, book downloads and Groovy/Grails discussions to occur). In addition, I wanted the portal to be built with Grails to showcase the technology. To accomplish this task, Big Sky Technology partnered with Scott Davis and Davisworld Consulting. Phase 1 is now out and available for use. We have many new features to be added to the site over the next three months, so stay tuned!
After 1.0 is done, please focus on updating the Eclipse plugin. I predict no widespread adoption of Groovy until the IDE support is as good as what we have for Java (where possible). (jroller.com/page/RickHigh?entry=predictions_for...)
See this issue jira.codehaus.org/browse/GROOVY-1422 which still seems to be unresolved.
See what the poster has to to say....
"The lack of code completion in the Groovy source code editor is a huge problem. Not only does it speed up input, but allows one to explore unfamiliar APIs. This last fact alone makes it easier to code in Java, even though the code can never be as terse and and elegant as the equivalent Groovy code. Code completion for Java based libraries alone would be a huge boost in productivity. Completion hints for dynamic Groovy types would be an added bonus."
It seems from the comments that this issue may be fixed, but when I tried it recently... not so much.
Has anyone tried the NetBeans support for Groovy? Is it any good? The Eclipse support is not so great!
This has to be a top priority to support Groovy on the most popular IDE.
ways in the last 9 months. There isn't code completion
for Java classes yet but work is being done there.
There is some basic code completion already there.
Even without that, the plugin is still very usable for
real world project work. My project team has been
using it for about since last May. There is step
debugging available, color syntax highlighting, and
hyperlinks to the Groovy source from the console. It
also supports mixing Grovy and Java source is the same
project (it still requires keeping the build order for
the classes in mind).
The developers on the plugin understand that code
completion and code browsing are the two most
important features for the plugin. They are also the
The code completion in place today will recognize
variables and methods defined in the same groovy
module. In the subversion trunk, there was some recent
work done to add Groovy DGM to the code completion
I have used Eclipse for a large Groovy project and have some experience creating an environment that allows real world work to get
done. Some of it has included using ant from Eclipse
to do things like regression testing and code coverage
I have tried NetBeans (last January - March) and didn't have good luck getting the debugging working with Groovy - although I was able to use JSwat (which is now build using NetBeans) with good success.
RE: Even without that, the plugin is still very usable for real world project work.
This is debateable. Yes some people will use Groovy even without good IDE support. I don't debate this. But, (with all due respect) there are people who like to drink their own yellow snow cone. I was talking about widespread adoption of Groovy not edge cases on the fringes of the bell shaped curve or people using it in production. (BTW I am not accusing you of drinking your own piss yellow snow cone it is just an example of a thing that won't be widespread).
I wrote this post because I am one of those people who are waiting for the Groovy plugin to improve. I'd love to start using Groovy, but not without code completion. ;o)
The code completion I am interested in the most is for Java classes so if I import a Java class.
I can do this.
myobj = new MyClass();
And get code completion where the | is. This is what I am waiting for....
(Okay... And annotations and enums would be nice too, but the biggest hold up for me is code completion.)
When this comes out.... I will start using Groovy.
Thanks to Big Sky!
Congrats to Big Sky and Theodorou !
Now only if we could get some sponsoring for the Eclipse plugin... :-)
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015