Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
can't imagine which 'Java' shop you could be talking about there gary – Gareth Davis May 6 '11 at 13:41
@Jonas Good link - lots to chew over in there. – Gary Rowe May 6 '11 at 13:58
up vote 14 down vote accepted

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.


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


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


  • 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.

share|improve this answer
+1 for a thorough answer - especially "moving to Clojure is non-trivial". I would appreciate some expansion on the dynamic layer/domain specific layer selection criteria. Good luck with the book! – Gary Rowe May 6 '11 at 13:43
@Gary Rowe - I'll expand on the selection criteria a little, check again in 10-15 minutes :) – Martijn Verburg May 6 '11 at 13:48
@Martin Thanks for the extra info, much appreciated. – Gary Rowe May 6 '11 at 14:14
Great answer, Martijn, very detailed and well thought out. Maybe you should write a book on this stuff! ;) – Rein Henrichs May 6 '11 at 16:07
@Rein, well I have to admit that I was able to paraphrase part of chapter 7 which was written to discuss this very question ;) – Martijn Verburg May 6 '11 at 16:13

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.