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
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
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
EXAMPLE PROBLEM DOMAINS