Groovy as a business user language?

Posted by Mark Figley on Jul 31, 2007 04:14 PM

Community

Architecture,

Java

Topics

Dynamic Languages ,

Business ,

Scripting

Tags

Groovy

Lifehacker, a popular personal productivity blog site, recently announced that OpenOffice would be using Groovy for their user facing macro/scripting language, the equivalent of VB/VBA in MS Office:

Free OpenOffice extension Groovy makes it possible to record and run Macros in OpenOffice. Don't confuse Groovy for a cheap Visual Basic knockoff. Groovy has its own syntax similar to bash mixed with Java. If you were sticking to Microsoft Office solely for its macro capabilities, you may be able to break away with Groovy. Unfortunately, Groovy is not nearly as beginner friendly as VB/VBA. However, beginners will have no problem getting started with simple macros. Groovy is a free extension for all platforms with OpenOffice.

For Architects there are a couple of things that are really interesting about this post:

• The source of this post. Lifehacker is a personal productivity news site, not a java developer oriented news site. It’s a geek friendly productivity site to be sure, but the readers of this site are likely to be the power users in the business units of your organization, not just the developers in your IT shop.
• There is no mention of Groovy as a broadly applied, general purpose programming language. No mention of Grails or Groovy’s use in a Java application infrastructure. In fact, after reading the post there is no reason to believe that Groovy is anything more than a scripting language extension created for OpenOffice. By neglecting to introduce Groovy in a broader context the author of the post might just be trying to keep things simple for the reader, but regardless we are seeing Groovy extending its relavence here. To this audience, Groovy is not a dynamic language for Java developers - it is a scripting tool for power users.
  

If nothing else, it is interesting to note that because of the OpenOffice integration Groovy my gain a whole new class of users that understand Groovy from a completely different perspective than your typical Java developer would. But from an Enterprise Architecture perspective, the application platform implications are more significant. For a long time Microsoft has been positioning it’s office suite as a rich client platform upon which power users can develop workgroup support applications that can integrate with backend applications, business services and databases. For Java shops there have always been issues with embracing that strategy because many Java shops aren’t fluent with the Microsoft stack. Now Groovy is giving OpenOffice the ability to compete with Microsoft in this space, and because of Groovy’s native integration with Java, OpenOffice/Groovy may now become even better positioned than MS Office as a rich client stack for Java shops.

1. Back to top

   Interesting...

   Aug 1, 2007 4:42 AM by Kit Davies

   Mmm. Functionally, it sounds great. But I can imagine the memory usage and performance being "less than spectacular", which might just annoy all those influential power business users, undoing all the good work in a stroke unfortunately.

   Reply

2. Back to top

   Re: Interesting...

   Aug 1, 2007 9:05 AM by Tom Nichols

   Not that I have tried this in OpenOffice, but in general... Groovy's performance is more than adequate for scripting applications, and I imagine memory would be a non-issue for anyone with more than 512MB of RAM. I'd be interested to hear first impressions of anyone who's actually tried it.

   Reply

3. Back to top

   Why not JavaScript?

   Aug 1, 2007 10:49 PM by Thamaraiselvan Poomalai

   Why can't we use JavaScript? If we use Rhino based JavaScript engine, we have all power of Java with easy usability of javascript. Any one out there to listen?

   Reply

4. Back to top

   Re: Why not JavaScript?

   Aug 2, 2007 2:09 AM by Vadim Voituk

   JavaScript has no such powerfull language capabilities like Groovy has. Also Groovy uses power of JVM HotSpot throught compilation to bytecode.

   Reply

5. Back to top

   Re: Why not JavaScript?

   Aug 2, 2007 2:13 PM by Stefan Tilkov

   Vadim, could you elaborate? What features are missing?

   Reply

6. Back to top

   Re: Why not JavaScript?

   Aug 10, 2007 8:39 AM by Vadim Voituk

   Groovy`s superiority - the JVM backend (HotSpot compilation and powerfull JDK) + much of language features (OOP, Clousers, native collections support, etc), that makes your code more readable, clear and easy to support.

   Reply

• Older >