Introducing a new JVM programming language into an established enterprise environment

Question

Imagine that your current workplace is a Java shop. There is a lot of built-up knowledge about the Java language and there is a comprehensive build and deployment process in place to handle everything in a smooth and Agile manner.

One day, a project comes along that just screams out to be written in, say, Ruby. Only the senior developers have any clue about Ruby but there's a general notion that since JRuby exists for the JVM then existing infrastructure could continue to be used and supported. Also, JRuby could show the way to a better way of implementing the current applications with less code so this could represent an ongoing migration.

Remember that JRuby is just an example, it could equally be Clojure or Groovy or whatever else runs on the JVM.

The question is how would you go about introducing this kind of change - if at all?

Answer 1

Disclaimer: I'm biased as I'm writing a book on Polyglot programming on the JVM (Shameless Plug!! - The Well-Grounded Java Developer) :)

Firstly, you should only introduce the change where it is truly warranted!

A good place to start is to consider Ola Bini's programming language pyramid. Ola talks about about stable, dynamic and domain specific languages.

Java is a stable language (statically typed & managed) and for various reasons (I can go into these later if people are interested) is not an ideal choice for dynamic layer projects (e.g. Rapid Web Development) or domain specific layer projects (e.g. modelling the Enterprise Integration Pattern domain). If you have a project that fits into one of those layers then that can be a good place to start.

You can also consider introducing a new language at the stable layer to replace Java if there is a fundamental feature that the alternative language offers. For example, Scala simply handles concurrency in a safer and more natural way than Java does.

As requested, some more on this. WRT Java:

• Recompilation is laborious
• Static typing can be inflexible and lead to long refactoring times
• Deployment is a heavyweight process
• Java's syntax is not a natural fit for producing DSLs

At this point, you may be asking yourself: “What type of programming challenges fit inside these layers? Which language(s) should I choose?”, remember there is no silver bullet, but I do have some criteria that you could consider when evaluating your choices.

Domain-specific

• Build / Continuous Integration / Continuous Deployment
• Dev-ops
• Enterprise Integration Pattern Modelling
• Business Rules modelling

Dynamic

• Rapid Web development
• Prototyping
• Interactive administrative/user consoles
• Scripting
• Test Driven Development / Behaviour Driven Development

Stable

• Concurrent code
• Application containers
• Core business functionality

Start with a small low risk module (remember, these JVM languages often interact with existing Java code beautifully) or project. Make it clear that this will be a throw away prototype.

Make sure that you've investigated the programming lifecycle and tooling aspects for that language. You will want to make sure you can TDD, run build tools and Continuous Integration, have powerful IDE support and all of those other factors. For some languages you'll just have to accept that certain tooling isn't there, or is very basic. The strength of the developer and the tooling support can outweigh the strength of a language.

Make sure there is a vibrant community that can help your team when they get stuck. Local user groups are even better for this.

Make sure the developers get the initial language training, especially if the language is not an OO style language (moving to Clojure is non-trivial).

That's about it I think. I've personally successfully used Groovy, Scala and Clojure in my development alongside Java for tasks such as XML processing, building quick web sites and doing some data crunching.

Answer 2

I'd like to add some thoughts about the topic raised with the the "if at all" remark. Indeed, why should one introduce additional languages to the team? True, if you are just looking at any single project the new language might stick out as the ideal tool for the task. But if you are going to have many projects, you might end up with quite a few additional languages over time. I don't know about your maintenance cycles and project numbers, but chances are the team will have to provide quite a lot of expertise in more languages than before.

From a business point of view, adding languages means adding complexity and knowledge requirements to the team. This extends periods of vocational adjustments, makes holiday-grounded (or permanent) replacements of specialists in your team harder and requires additional training for team members, meaning slow-downs in the short term.

In my eyes, a strategy to make the introduction welcomed should adress such issues apart from purely functional aspects, too. Is the expected gain worth the extra trouble and the disadvantages like the ones I mentioned above? If this can be proved, acceptance rates might be much higher. Pointing out those nice investments in the qualification of team members might help, too.

Answer 3

I'd say, start around the edges. Show off the language in some non-production code like build scripts, maven plugins, report running, etc. Once they see the utility and simplicity, they may be more inclined to allow into small-scale project and so on.