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
- Enterprise Integration Pattern Modelling
- Business Rules modelling
- Rapid Web development
- Interactive administrative/user consoles
- 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.