Summary
Groovy project manager Guillaume Laforge discusses the history of Groovy, it's relationship to Java, where Groovy fits into Java development,how Groovy compares to Ruby, how Groovy enables domain-specific languages, and what future Groovy development will focus on.
Bio
As the official Groovy Project Manager, Guillaume Laforge spends his spare time bringing a versatile and agile environment to the masses and initiated a year ago the seed of Grails, the Groovy & Spring web framework. Guillaume is also a software architect and Open Source consultant, working for OCTO Technology, a French consultancy focusing on architecture of software and information systems
This is Floyd Marinescu at QCon with Guillaume Laforge. Guillaume , could you tell us a little bit about yourself?
My name is Guillaume Laforge, I am the Groovy project manager and I am also the spec lead of JSR 241, which is the JSR standardizing the Groovy programming language, and in my professional life I am a software architect at OCTO Technology, which is a French based consulting company focusing on software architecture, Agile methodologies and that's why I was happy to go to the QCon conference organized by InfoQ.
Guillaume , you saved Groovy.
Yes, a few years ago it was stagnant, it wasn't really moving anymore and we needed to do something about it and as the former project manager went on working on some other projects, I took back the lead and tried to attract new developers and put some new energy inside the project and its community. I think it worked quite well because there's a lot of things happening around Groovy and Grails, this past month and past year and you can expect a lot more in the following month and year.
Why is Groovy important to Java? Why did you invest so much of your time to make this project work?
Initially when I came to Groovy, it was around 2 months old or something like that, I was working on an application where users could customize some widgets in their user interfaces, and initially you could only create those widgets in Java, and you could not create them live, you had to redeploy your application and so on, it was really boring and I thought "well, if we had scripting support in Java for doing such a thing that would be great". And Groovy was there and I looked at it and thought: "Oh that looks interesting, I could integrate that in my Java applications". And I could externalize business logic, widgets or some configuration we find, fed in with XML, I can use some programmatic constraints to configure my application or to go even further, if you are externalizing your business logic you could go as far as creating your domain specific language with Groovy because of its malleable syntax, and its dynamic features.
Where do you see are the best places to use Groovy in a Java project?
There's an example that comes to mind, there's a big insurance company in the US, Fortune 500 company, was working on a very big insurance application for dealing with the risks associated with health policies and so on, and they have got around 45,000 lines of Groovy code to represent all the business logic, all the rules defining how things work and how to compute the risk associated with a certain product or policy. And they managed to involve the business specialists of the company into writing themselves those rules. It makes quite a lot of sense to be able to separate this business logic from the core Java group's code making the application, and to be able to work together, make people work together, developers as well as business specialists. That's pretty interesting and a very good use case for where you could integrate Groovy in Java. I think we are going to see more and more cases like that, where you can leverage scripting language or dynamic language in your Java application.
What are some other good uses of Groovy in Java?
You can use Groovy in various areas, for instance if you are just doing some scripting tasks like you would do in any scripting languages on your Linux system. It's interesting because you can also use Groovy like that kind of language, but leveraging all the Java libraries you already have, so if you've got some special business Java library written and you want to reuse it to parse some files or things that came from older systems, you can do that. And you can use Groovy even for prototyping some small applications as well.
The main three use cases are scripting tasks, integrating Groovy in your Java application for externalizing things like I explained earlier, and writing full blown applications. I have another example that comes to mind: the French Ministry of Justice used Groovy while building their application, they had a UML model of their application - so there were judges, and courts and various domain objects, designed in a UML - they extracted an XMI model in an XML format and they managed, through the use of Groovy templates and some Groovy glue, they managed to create all the artifacts of their application like the JSP views or the flow of the application, where from this page go to this page, and from this thread's action you are going to see the outcome to this view. The final application didn't have any single line of Groovy code in it, but they used Groovy as a tool to enable them to write faster their application.
Where do you see Groovy adoption being in the Java community right now?
The adoption is quite good because we have got interesting business use cases of Groovy usage. We've got more, especially when we released 1.0, we had like twice as much user subscribing to our mailing list, and more and more downloads and more and more people coming asking questions. And you see that there are new users because their questions are more like "How do I do this and that?" It's interesting to see that since we released the final version of 1.0 we are quite successful. And if you are watching the blogosphere, you'll see every day many articles on Groovy and Grails, it's a bit crazy and it's taking shape quite nicely. And even on polls, there are polls, "which scripting language you prefer?" and Groovy is usually ranked first. It's a pleasure for me to see that success coming.
Why is the Java community discovering scripting now?
It's funny because scripting languages have been there for such a long time and the fact is that those languages were usually languages on their own, they weren't really integrated with Java. Now there's a big difference because there are many languages that are available on the JVM, so you can mix and match different languages together, separate things and have more expressive ways to define rules. While it is interesting to see that, the success of Ruby and Ruby on Rails also played an important role in this. I don't know exactly why, but I think all these things come into play having scripting languages for the JVM and lot of noise and buzz around Ruby and all the famous languages like that.
Speaking of Ruby, it seems like Java developers have a choice between two popular platforms now when they are trying to do scripting. How would one choose between Groovy and JRuby for doing scripting in Java?
I've got a rule for them on that. If you are a Java shop it makes sense to use Groovy because it's a Java-like syntax and it integrates seamlessly with the Java platform and all its libraries. It's the same object-oriented models, the same libraries, the same regular expressions. If you were to choose JRuby so that you can stay on the JVM, you'd probably choose JRuby if you are already a Ruby shop. For instance if you have people with skills in Ruby they should probably just go with JRuby. But if they want a tighter integration with Java on the JVM they should probably go with Groovy because it's the very same object model, there's no impedance mismatch between two different languages and two different paradigms. So that's my rule: if you know Ruby, use JRuby, if you prefer something more Java-like, use Groovy.
Do you see Groovy making DSL programming more popular in Java?
Yes, I think so. Because of all its dynamic features it's so easy to do things like you can write "3.euros" or "48.dollars" or things like "3.days.ago". You can have some very expressive means of expressing things. You can really create your own mini-languages, modeling your domain of expertise, the business concept and so on. You can create your own control structures, you've got "IF", "FOR", "WHILE" loops and so on, but if you really want to have your own control structure you can do so, it's very flexible. I think those who are embedding Ruby for the business rules in the application usually tend to go that way, to try to have a simpler language which models their domain of expertise and it is easier to work with and both the business guys and the developers share this common metaphor for textual representation of their business. It's rather interesting to see how dynamic languages are able to define such specific languages for their model and their domain.
What is it with dynamic languages, that makes them suited for DSLs versus something in Java?
Java is a statically type language, and you always need a compiler - in Groovy there's also a compiler - but it's done, everything is hard-wired by the compiler when you compile Java code. So you can't really easily intercept method calls, property access or overwrite things like operators or things like that. It's a lot less flexible, and even if you are writing some fluent interfaces which make Java code more readable, you will always have boilerplate technical code which gets in the way of readability and you usually can't have business guys behind you, over your shoulder: "Hey, this rule is not the way it should be in the model" whereas dynamic languages, on the other hand, let you catch methods, you can do method interception, you can add new methods to existing JDK classes or to numbers, like the example I mentioned earlier where you say "3.dollars", you've got an amount of money in a certain currency. You can't do that in Java -- ints are just primitive types, you can't play with them or create useful things with them. So in the end you can have, through meta-programming facilities in dynamic languages that you can't have in Java, you can really create a language on its own with new constraints and the limit is your imagination in fact, because it's that powerful and Java won't let you do that kind of things.
What are the most important issues facing the Groovy community today?
I think the biggest issue at the moment which can slow adoption is regarding tooling support and especially IDE support, because when you are a Java developer you are so used to hit ctrl-space and that's code completion, I don't have to look for the Javadoc or the documentation of my APIs. One of the important aspects that we are going to work on in 2007 is tooling support, and we have got a pretty big team of guys working on the Eclipse plugin and within the following weeks or months you should to be able to have code completion in the Eclipse plugin so it is going to be much easier to write Groovy code in Eclipse.
And I have also been contacted by the JetBrains guys, because they want to add Groovy support in the IntelliJ IDE. As you know they are quite good at making awesome support for languages like JavaScript or Ruby, and I am sure they can do pretty amazing things for Groovy like code completion of course, but even refactoring. So you will have very good support in your IDE, you can mix and match Java and Groovy and have refactoring work, because they have to work. It's really something we have to focus on during this year, and it's taking shape quite nicely and before the end of the year we should have some good tooling support. That's really the main aspect that we need to work on.
What are your two favourite computer books?
Probably one of my favorites is the "Pragmatic Programmer" book -- that's really one of the great books I have really enjoyed reading. In fact there are two other books I have in mind, I would say "Groovy in action", of course I am one of the co-authors so I am a bit biased. It's a really good book. If you look for reference documentation on Groovy, if you really want to know all the inner workings of the language and its libraries and meet our programming facilities, it's definitely a very good book. And if I had to pick a third one, it would be "The Definitive Guide to Grails", written by Graeme Rocher and speaking about the Grails web-framework.
No comments
Reply