Integrating Groovy We build too many walls and not enough bridges. —Isaac Newton 360 Getting ready to integrate 361 One of the biggest advantages of Groovy (even one of the reasons for its inception) is the fact it integrates natively with Java because both languages run on the same platform. It is important to understand what makes Groovy such an attractive option when you need to embed a scripting language in your application. First of all, from a corporate perspective, it makes sense to build on the same platform that most of your projects are already running on. This protects the investment in skills, experience, and technology, mitigating risk and thus costs. Where Java isn’t a perfect fit as a language, Groovy’s expressiveness, brevity, and power features may be more appropriate. Conversely, when Groovy falls short because of the inevitable trade-off between agility and speed, performance- critical code can be replaced with raw Java. These balancing decisions can be made early or late with few repercussions due to the close links between the two languages. Groovy provides you with a transparent integration mechanism that permits a one-to-one mix-and-match of Java and Groovy classes. This is not always the case with other scripting solutions, some of which just provide wrap- pers or proxies that break the object hierarchy contract. This chapter will show you how to integrate Groovy with Java in various ways. First we’ll examine three facilities provided by Groovy: GroovyShell, Groovy- ScriptEngine, and GroovyClassLoader. We will then consider the scripting sup- port provided by the Spring framework and Java 6, code-named Mustang. You will see that by integrating Groovy and Java, you can leverage the vast libraries of available Java classes and also enjoy the benefits of the extremely agile dynamic capabilities Groovy provides. All this can be done with seamless integra- tion of the two languages. 11.1 Getting ready to integrate The interplay between Groovy and Java means that it is easy to make them coop- erate in various ways. The most obvious way is to make Groovy code call into Java code, either using one of the command-line tools to load and run Groovy scripts directly, or using groovyc to compile Groovy into normal Java class files. This assumes that all the code is known before the application needs to be compiled. It doesn’t allow for any just-in-time provision of code, whether that’s through users entering expressions as they might into a graphing calculator or developers pro- viding replacement scripts for just the bits of code that require frequent changes within a live system. As an idea of how widely used this kind of facility can be, consider Visual Basic (VB). We’re not in the business of judging its pros and cons, but it would be hard to 362 CHAPTER 11 Integrating Groovy deny that VB is popular and has been for a long time. Although many developers write whole applications in VB from scratch, far more use the capability of various products to embed pieces of VB code in order to customize behavior in ways the original developers may never have even considered. Now consider allowing that kind of flexibility in your application. Instead of hearing people talking about writing VB in Microsoft Office, imagine those same people talking about writing Groovy in your application. Imagine them using your product in ways you never contemplated—making it more and more valu- able for them. Before seeing how this can be done, we should step back and think about why we would need to integrate Groovy in a Java application, the situations in which it’s useful to do so, and the dependencies we need to set up before we get started. 11.1.1 Integrating appropriately No-one can tell you what your application needs are or what is going to be suit- able for your particular situation. You must look carefully at your requirements and consider whether you will benefit from integrating Groovy at all. We can’t make that decision for you—but we hope we can give a few ideas to guide you. First, it’s worth explicitly acknowledging that not all applications benefit from integrating a scripting language such as Groovy. We can go as far as saying that most don’t need that. If you’re writing an e-Commerce web site, a multimedia player, or an FTP client, chances are that you won’t need a scripting language. But now, suppose you were building an advanced word processor, a spreadsheet appli- cation, or a complex risk-calculation module for an even more complicated bank software suite that had to evolve quickly to follow the rapid changes of the market, legislation, or new business rules. These applications might need an extension point where end users can customize them to suit their needs. Figure 11.1 shows one example of where you could integrate Groovy. Figure 11.1 One example of an integration solution. Groovy code is entered by the user in the user interface layer and then executed in the business layer. Getting ready to integrate 363 For instance, the banking application might require the definition of business rules in a script that could be defined at runtime without requiring a new and tedious development/test/qualification phase, reducing the time to market and increasing the responsiveness to changes in financial practices. Another example could be an office suite of applications offering a macro system to create reusable functions that could be invoked with a keystroke. It becomes obvious that a dichot- omy of the software world differentiates monolithic applications, which don’t need to evolve over time and have a fixed functional scope, from more fluid applications whose logic can be extended or modified during their lifespan to accommodate context changes. Before considering using Groovy in your application, you need to analyze whether you need to customize it, and see whether you want to customize, extend, or amend the logic, and not just simple parameters. If parameterization will ful- fill your needs, you may be better off with classic configuration mechanisms such as an administration web interface through a set of web services; or, for more advanced monitoring and action management, you may also consider exposing JMX1 MBeans. Sometimes, even if the logic has to change, if the choice is between a small and well-defined set of business rules that are known to begin with, you can also embed all those rules within the application and decide through param- eterization which one is to be used. Once you have examined your needs and come to the conclusion that a scripting environment is what your application requires, this chapter should provide you with all the information you need to make your application extendable at runtime with logic written in Groovy.2 In the following sections, you’ll learn how to use the GroovyShell class to eval- uate simple expressions and scripts, as well as the GroovyClassLoader for further loading of Groovy classes. In addition to the techniques provided by Groovy for integrating your scripts in Java, you’ll discover alternatives for leveraging the Spring framework and the scripting API within the upcoming Java 6 release. 11.1.2 Setting up dependencies In order to use Groovy within your project, you will need to set it up to use the Groovy libraries. This section covers the dependencies required for Groovy inte- gration. The fact that it’s so short should be a source of comfort—there’s little 1 Find more information at http://java.sun.com/products/JavaManagement/. 2 Of course, we don’t wish to discourage you from reading the chapter even if you don’t have any inte- gration needs right now. Gaining knowledge is a worthy pursuit in and of itself. 364 CHAPTER 11 Integrating Groovy work to do to get up and running. However, problems can sometimes crop up during integration that you wouldn’t see if you were using Groovy by itself. We will discuss these potential issues and how to resolve them. The Groovy distribution comes with a directory containing all the core librar- ies that form the Groovy runtime. The minimum for embedding Groovy consists of the three jar files listed in table 11.1. Table 11.1 The minimal jar files required for integrating Groovy File Purpose groovy-1.0.jar Groovy core library antlr-2.7.5.jar Grammar parser and generator asm-2.2.jar Bytecode toolkit used to generate classes But these three dependencies may sometimes conflict with the other libraries your project uses. In particular, if you are using Hibernate and/or Spring, which both use ASM for generating proxies, you will not be able to use Groovy unless the version of Hibernate or Spring you are using requires the same version of ASM. However, there is a solution to this problem. The Groovy distribution also comes with a specific Groovy jar file that embeds the dependencies in their own pack- ages. This library is often called the embeddable jar file, because you can embed it beside any other library without any conflict. You will find this jar file in the direc- tory named embeddable of your Groovy installation: groovy-all-1.0.jar. Remember that if your project depends on ASM or Antlr, you can use this “magic” jar file to solve your versioning issues between Groovy and your other dependencies. Also, keep in mind that your project will have to run under a JRE 1.4 or above, which is a requirement for Groovy.