Francis Shanahan has an interesting take on J2EE, Groovy, and Grails:

Let’s say you want to put up a simple Hello World website that saves some information to a database. In ASP.NET that’ll take you about 5 minutes if you’re slow. You won’t get much for your 5 minute investment but you can iterate on the implementation and ultimately “evolve” it to production quality code. You never need to leave the IDE and there’s practically no configuration.

In Java, you’d better start out on the right foot. J2EE is abismal so you’ll need to choose a presentation framework, the most popular arguably being Struts. You might need a middle-tier framework, why not choose Spring. Next you’ll need a data access layer, like JDO, iBATIS or Hibernate . Of course all these frameworks are terrific, “light-weight” and incredibly generic. What does that mean to you??? You’ll have to configure them for about a week.

It’s because of this that the java community has woken up in favour of things like Ruby. But Ruby on it’s own was pretty useless until 37Signals created Rails (you guessed it, a framework for Ruby). Such a struggle to actually get something done. But it doesn’t stop there. Someone said “hey, why do I have to learn a new language?” I’d like a language that looks like java but without all the overhead. So they made “Groovy”. And that of course needed a framework, which is how you arrive at “Groovy on Grails”. It get’s worse, Groovy doesn’t use servlets, it uses groovelets. grooBarf.

Now each to his own but it seems to me that J2EE has arrived at a rather embarrassing conclusion that it’s basically unusable as an agile development platform. Maybe I’m wrong but when your platform is so convoluted that you need to actually look elsewhere to get stuff done, perhaps it’s time to rethink.

– Francis Shanahan

Comments on the original post:

Max : It’s not cheap either.

Max : Java abstracts the platform, but so many folks have made their own implementations that it’s gotten to the point where you have to specialise in an vendor or a framework. So you lose your portability, both of skills and code.

Beano : It gets better/worse - ever heard of JRuby???

Jordan : It’s such a crazy misconception that you can’t do rapid prototyping in J2EE. If you’re starting point is equivalent to .NET Visual Studio, so a decent IDE (Eclipse) with App Server plug-ins (like Tomcat) and a database (maybe mySQL) than you could pop something out in five minutes. 1) Create a JSP page and use the java standard tag libraries (JSTL) SQL tags to do it. 2) Run… You don’t need to assemble all these crazy frameworks to do the simple stuff.

Tags: Grails

Andrew Binstock writes the “Integration Watch” column for SD Times and is a senior contributing editor at InfoWorld where he reviews middleware and enterprise software development tools. For the past 16 years, he has also been a judge for the Jolt awards. He wrote the following blog entry on Groovy’s traction after JavaOne 2007.

Java developers suddenly have a wealth of choices when it comes to dynamic languages that run on the JVM. There’s JavaFX, which Sun announced at JavaOne this year, and JRuby, which Sun expects to complete sometime this year, and then, of course, there’s my favorite: Groovy. Groovy makes writing Java programs far easier. It essentially takes Java and removes the syntactical cruft, leaving a neat language that makes you terrifically productive.

Because Groovy took a long time getting out of the gate, it’s taken some licks in the press. However, it’s clear that Java developers are catching on to its benefits. The JavaOne bookstore published its daily top-10 sales during the show. The picture on this post, shows the Day 2 list with two Groovy titles in the top 10 (at places 5 and 8). Overall, the Groovy bible, Groovy in Action, came in at number 5 for the show. Interest is definitely growing.

If you haven’t tried Groovy yourself, it’s definitely worth a look. Here are a couple of good overviews:

• The Groovy Getting Started Guide
• Andrew Glover’s Overview and Tutorial on DeveloperWorks

Dierk König followed up that:

Groovy in Action was #2 bestseller through day 3 of JavaOne and would have finished even better that #5 overall if it wouldn’t have been sold out by Thursday noon

Tags: Groovy

Groovy core developer Jeremy Rayner rounded up bloggers’ reactions to Groovy, after JavaOne 2007:

It looks like Groovy managed to enthuse some people about Groovy and we even made it to the best seller list (#5)

Jeremy sent special thanks to Guillaume Laforge, Dierk König, Rod Cope, Vladimir Vivien Graeme Rocher and anyone else who talked about Groovy at JavaOne, either on stage, or in the corridors.

Tags: Jeremy Rayner

Groovy developer Jeremy Rayner’s 6-minute elevator pitch for the Groovy language. Recorded at Google offices in London on 24 May 2007, as part of the Open Source Code Jam 3. Presented and Edited by Jeremy Rayner.

Tags: Jeremy Rayner, Video

From the Groovy Mailing List:

Hi all,

the compiler is now able to support most of the generics declaration
features. It is now possible to use generics in methods, fields and
class definitions using wildcards, lower and upper bounds. The
implementation might have several bugs, I tried to find them, but of
course I can’t foresee all cases.

Things that are currently missing:
* covariant return types (might come soon)
* compile time checks for correct usage of the number of parameters
(might not yet be implemented as it requires java5 features)

have fun

bye blackdrag

–
Jochen “blackdrag” Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

Generics support in will be useful in Grails, according to Graeme Rocher:

>
> will Grails now make use of it? List<Books> looks useful to Grails.

Yeh definitely for those who want to use EJB3 style mappings instead
of GORM style mappings

Cheers
Graeme

Tags: Graeme Rocher, Jochen Theodorou

We just rolled out an update to our public site, with some key improvements:

• Better code index We added over 20,000 new projects, including many that are archive-only (no code available in a public SCM) from repositories such as SourceForge.net and Tigris. We now have over 2 billion lines of code in our index.
• New languages We now support Erlang and Groovy. I’m guessing Yonatan and Al, among others, will be very excited about this. I know, we’re still missing ABAP, Forth, SCL, LabVIEW, etc, etc. Good God there are a lot of programming languages out there!
• Revised Eclipse IDE plug-in The Eclipse plug-in is now at version 1.0.5.2, and recently passed the Ready for Rational gauntlet. You can download the latest version here. This link is still to the beta program page, but we’re transitioning to general availability.
• Open API A big part of this release was cleaning up the RESTful API to our services, in preparation for public availability. If you’re interested, send email to support@krugle.com and request to be added to the documentation seed list.
• Lots of cleanup For example, our code query parser is smarter about quoted terms. You can click on language graphs in a project page (like KDE). And many more fixes and features requested by our users - so keeping clicking that feedback link…it really works!
• Top Projects As always, we continue to expand our list of top projects.

While the size of the index isn’t so important (see my early blog post on 1,563,644,824 reasons why size doesn’t matter), the fact that it’s grown by over 35% in the past 6 weeks is an important data point. We’re finding that the long tail of public code is longer and fatter than we thought. The rate at which we find new repositories and projects, as well as the rate at which new projects get added to existing repositories, isn’t slowing down. And as more companies decide to open up their source code, I expect to see an accelleration in the growth of public code.

Notice that I’m using the term “public code” instead of “open source software”. Another trend (for a future blog) is that we’re seeing an increasing amount of code released under what I call “look but don’t touch” licenses. Or maybe a better term would be “antique store” licenses, as in “you use it, you pay for it”. More on that later.

Getting back to the recent update to Krugle, I’m excited about opening up our API. You’ve been able to send in search requests and project links (via URLs) for quite a while - see this blog post by Chris Burmester from last October. What we’re doing now is providing public access to the back end APIs that actually power the Krugle web site and our Eclipse IDE plug-in. Using this API, you’ll have access to the same code, tech pages, and project data that you see on the public web site and via the Eclipse IDE plug-in.

So send us email if you’d like to get added to the documentation seed list (once again, that’s support@krugle.com), and include a short description of how you’re thinking of using the API.

Thanks,

– Ken, Krugle Blog

Tags: Groovy

Warner Onstine described his recipe for writing Domain Specific Languages (DSLs) in Groovy.

The original post is here.

This post highlights the comments on that post:

Comments

1. Graeme Rocher about 18 hours later:

   nteresting, though I find that in the beginning it seems like a good idea to extend BuilderSupport, but later you realise it is too limiting and overriding invokeMethod is far more flexible as far as the syntax options you have available to you

   It of course depends on the DSL you are writing

   Cheers Graeme

2. Warner Onstine 1 day later:

   This comment came from Guillaume Laforge (Groovy lead) on the Groovy users list:

   This is a nice wrap-up of the steps to follow. The thing I feel is missing a little is the “invention” of the DSL in itself with the end-user. I think we have to stress that part more. You have to know what’s possible to do with Groovy in terms of DSL, you have to speak at length with your users, and incrementally design on paper (or on screen) what the DSL will look like. I think this step should be emphasized a bit more in the approach.

3. Warner Onstine 1 day later:

   Guillaume, I definitely agree. I wanted to come up with some basics, but the user-level involvement definitely has to be there. It’s hidden right now in the Prototype phase I talk about, but should be more fully discussed in a future post. I have several posts in my head right now so I’ll jot this down as one to write up

Leave a response on the original post

Tags: Graeme Rocher, Guillaume Laforge

Tags: Dierk König, Graeme Rocher, Grails, Guillaume Laforge, Jeremy Rayner

I never intended to do a long-ish explanation of my position on the whole Groovy/Grails vs Ruby/Rails thing, but Migs’ and Graeme’s comments on my previous post prompted me to respond. I originally intended to answer them in another comment after Graeme’s, but my comment turned out longer, so I’m putting it up as a separate post instead.

Before going further, I have to warn everyone — I have ZERO tolerance for flames. Long convoluted debates to get to some technical ‘truth’ (or any other kind of ‘truth’ for that matter) are nothing but mental and intellectual masturbation, period. Consider yourselves warned.

Now then…

Actually, having a scripting language that compiles to bytecode from its inception has been something on my wishlist for the longest time, ever since I first fell in love with Python many years ago. If I recall correctly, for instance, Jython’s development lagged somewhat behind mainstream Python, and more so Java. Much as I loved Python (and Java), I couldn’t bring myself to bother with Jython.

Now, here comes Ruby. I’m sure its a great language; I ran through a tutorial article in a magazine and it seemed as simple as Python to learn, maybe even simpler. But, it was designed from the get-go to be interpreted, and when I started hearing about JRuby, I figured this would be the same story as with Python — development would always lag somewhat behind mainstream Ruby and/or Java; whether or not anybody admits it, Ruby will always be a second-class citizen on the Java platform.

I haven’t tried Groovy yet, but I find the idea of a [scripting language that is a] first-class Java platform citizen very appealing. Nobody doesn’t really claim that Ruby or Rails had no influence on the initial inspiration for Groovy and Grails, and I have no problem with that. Progress based on or inspired by something that came before, is not unheard of, even in the world of scientific research; in fact its only natural, I think, “standing on the shoulders of giants” and all that, as Einstein said.

As of now, I have no real scientific reason to judge which is ‘better’ or not, and I’m not inclined to do any exhaustive benchmarks on either side. There are other people on both sides of the fence who would only be too happy to do that, and probably do a much better job of it than I ever could. With no ‘real’ technological benchmark to base my judgement on, I’m left with only what ‘appeals’ to my own personal geek sensibilities.

I’m still, therefore, going to give Groovy/Grails a whirl one of these days. And when I say that, I mean just that — I’m not saying everybody else should be getting into Groovy/Grails too. I’m only saying I’m going to give Groovy/Grails a try. It’s not a moral statement of right or wrong, and its not a judgement of what’s better or not. It’s only a statement about what I’m going to do. Let everybody else go into benchmarks and long arguments on mailing lists if they want.

– Joel at ThoughtForge

Tags: Groovy

When I started to play with Grails, I was impressed with the design of it. However, as soon as I got into actually developing a Grails application of my own, I have found myself spending (read: wasting) a lot of time on issues, not documented, that only a newbie like me would do, but that ate a lot of my time. So, to save you from the same (and your time from wasting), here’s a list of “gotchas” I ran into:

The list:

• Use size instead of length.
• Use right type parent reference when defining one-to-many relationship
• Unit testing
  • Don’t call dynamic methods from controller or unit test
  • Hidden validation error messages
  • Hidden unit test error log
    

Details:

• Domain property constraints: do not use length, but size. If you use length, you won’t be warned at all, but it won’t work either. And a book (and a very good one!) by Graeme, the “The Definitive Guide to GRAILS”, still uses the “length” in all examples. So, stay warned.

• When defining a one-to-many relationship, in the child object you have to define a declare it by static belongsTo = Parent, but also you need to define a property that references the parent. Now, this property, has to be of the Parent type. As obvious, as it seems to be, I have spent another couple hours to figure out, why the dynamic views were not reflecting one side of the relationship. Again, there is no warning. It’s up to you, so stay alert.

• Unit testing
  • First, if you try to call dynamic methods (in controller you have: def scaffold = Book), from your unit tests, you’ll get an ugly message, that doesn’t help you understand what’s the problem. The thing is, you need to switch to static scaffolding in order to be able to call controller methods from unit tests.
  • If you have a def book = new Book(title:’Ala ma Kota’).save() and the constraints are violated by it, you’ll get a null returned from save() as a result. But how to find what is the problem with new Book()? Well, it’s a secret. Use book.errors.allErrors to get the list of errors and println on them. And by the way, they will not show up in the unit test stdout. See next bullet for this.
  • Unit tests send errors to a file well hidden in <app_base>/target folder.

– Stan Berka on Grails.org

Tags: Grails