Imagine that your current workplace is a Java shop. There is a lot of built-up k
ID: 639595 • Letter: I
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?
Explanation / Answer
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: