Java Magazine - November/December 2011

tify which parts of your project best suit a dynamic layer or domain-specific layer approach. Table 2 highlights some tasks that might be suitable for each layer.

There is a wide range of natural use cases for alternative languages. However, identifying a task that could be accomplished with an alternative language is just the beginning. You now need to evaluate whether using an alternative language is appropriate. Here are some useful criteria that we take into account when considering technology stacks:

■ ■ Is the project area low risk?

■ ■ How easily does the language interoperate with Java?

■ ■ What tooling and testing support is available for the language?

■ ■ How easy is it to compile, test, build, and deploy software in this language?

■ ■ How difficult is the learning curve?

■ ■ How easy or difficult is it to hire developers with experience in this language?

Let’s dive into each of these areas so you get an idea of the sorts of questions you need to be asking yourself.

coverage and a shortage of developers who fully understand it.

However, there is more to a system than just its core processing. For example, this is a situation where better tests would clearly help. Scala has a great testing framework called Scala Test. This enables developers to produce JUnit-like tests for Java code but without a lot of the boilerplate that JUnit seems to generate. So, once they are over the initial learning curve, developers can be much more productive at improving the test coverage. Scala Test also provides a great way to gradually introduce concepts such as Behavior-Driven Development to the codebase. These concepts can really help when the time comes to refactor or replace parts of the core—regardless of whether the new processing engine ends up being written in Java or Scala.

Or, suppose that the operations users would like to have a Web console built so they can administer some of the noncritical, static data behind the payment-processing system. The developers already know Struts and JavaServer Faces, but they don’t feel any enthusiasm for either technology. This is another low-risk area to try out a new language and technology stack. One obvious choice would be Grails. Developer buzz, backed up by some studies (including one by Matt Raible), is that Grails is the best available Web framework for productivity.

By focusing on a limited pilot in a
low-risk area, the manager always has
the option of terminating the project
and porting to a different delivery tech-
nology without too much disruption, if
it turns out that the attempted technol-
ogy stack was not a good fit for the team
or system.

environment. This can help reduce risk and alleviate any worries they might have about the new solution.

Note: DSLs are typically built using a dynamic (or, in some cases, stable) layer language, so many of them run on the JVM via the languages they were built in.

Some languages interoperate with Java more easily than others. We’ve found that most popular JVM alternatives have good interoperability with Java. Run a few experiments first to really make sure you understand how the integration can work for you.

Take Groovy, for example. You can simply import Java packages directly into its code using the familiar import statement. You can build a quick Website using the Groovy-based Grails framework and yet still reference your Java model objects. Conversely, it’s very easy for Java to call Groovy code in a variety of ways and to receive familiar Java objects. One example use case could be calling out to Groovy from Java to process some JSON and having a Java object be returned.

Does It Interoperate with Java?

You don’t want to lose the value of all that great Java code you’ve already written. This is one of the main reasons organizations are hesitant to introduce a new programming language into their technology stack. However, with alternative languages that run on the JVM, you can turn this concern on its head—so it becomes about maximizing the existing value in your codebase, not about throwing away working code.

Alternative languages on the JVM are able to cleanly interoperate with Java and can, of course, be deployed in a pre-existing environment. This is especially important when discussing this step with the production management folks. By using a non-Java JVM language as part of your system, you’ll be able to make use of their expertise in supporting the existing

JAVA IN ACTION ABOUT US

Is the Project Area Low Risk? Let’s say you have a core, payment-processing rules engine that handles more than 1 million transactions a day. It is a stable piece of Java software that has been around for more than seven years, but there are not many tests for it and there are plenty of dark corners in the code. The core of this engine is clearly a high-risk area for a new language, especially because it is running successfully and there is a lack of test