InfoQ

News

Groovy as a business user language?

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

Community
Architecture,
Java
Topics
Scripting,
Dynamic Languages,
Business
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.

7 comments

Reply

Interesting... by Kit Davies Posted Aug 1, 2007 4:42 AM
Re: Interesting... by Tom Nichols Posted Aug 1, 2007 9:05 AM
Interesting... by flameme yamam Posted Jun 6, 2008 5:29 AM
Why not JavaScript? by Thamaraiselvan Poomalai Posted Aug 1, 2007 10:49 PM
Re: Why not JavaScript? by Vadim Voituk Posted Aug 2, 2007 2:09 AM
Re: Why not JavaScript? by Stefan Tilkov Posted Aug 2, 2007 2:13 PM
Re: Why not JavaScript? by Vadim Voituk Posted Aug 10, 2007 8:39 AM
  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.

  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.

  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?

  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.

  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?

  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.

  7. Back to top

    Interesting...

    Jun 6, 2008 5:29 AM by flameme yamam

Exclusive Content

Rob Windsor on WCF with REST, JSON and RSS

WCF is not just for SOAP based services and can be used with popular protocols like RSS, REST and JSON. Join Rob Windsor as he introduces WCF 3.5 and its new native support for non-SOAP services.

Christophe Coenraets Discusses Flex 3, AIR, and BlazeDS

Christophe Coenraets discusses Flex 3, Flex Builder, AIR, BlazeDS, Adobe and open source, integrating Flex with existing applications, and integrating RIAs with search engines and browsers.

Debunking Common Refactoring Misconceptions

Danijel Arsenovski attempts to dispel some of the myths around refactoring and how it applies to .NET developers.

REST Eye for the SOA Guy

In this presentation, recorded at QCon San Francisco, CORBA guru Steve Vinoski explains REST from the view of someone who comes to SOA from a traditional, RPC-oriented background.

Choose Feature Teams over Component Teams for Agility

Feature teams are key to scaling agility for large teams. In an excerpt from "Scaling Lean and Agile Development," Larman & Vodde show how feature teams resolve traditional problems & raise new issues

Billy Newport explains Virtualization

Billy Newport talks about virtualization, eXtreme Transaction Processing (XTP) and WebSphere Virtual Enterprise. He discusses hardware, hypervisor, JVM, application and data virtualization.

Virtualization and Security

While virtualization provides many benefits, security can not be a forgotten concept in its application.

Introduction to Agile for Traditional Project Managers

This session is specifically aimed at traditionally trained project managers who are new to Agile, and who would like to be able to relate the PMI's best practices to their Agile equivalents.