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?
Introducing a new JVM programming language into an established enterprise environment
java;development process;language choice
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 laboriousStatic typing can be inflexible and lead to long refactoring timesDeployment is a heavyweight processJava's syntax is not a natural fit for producing DSLsAt 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-specificBuild / Continuous Integration / Continuous DeploymentDev-opsEnterprise Integration Pattern ModellingBusiness Rules modellingDynamicRapid Web developmentPrototypingInteractive administrative/user consolesScriptingTest Driven Development / Behaviour Driven DevelopmentStableConcurrent codeApplication containersCore business functionalityStart 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.