I'd add my vote for using Groovy's shell (groovysh) for Java REPL. The shortcuts and conveniences the Groovy lang provides make it perfect for this kind of application.
Groovy's original purpose, as frequently stated by its creator James Strachan, was exactly this kind of application. There's been a lot of other things going on with Groovy since then which anyone considering using it would have to evaluate. Although other JVM scripting languages existed at the time of its birth in 2003, e.g. Jython since 1997 and Beanshell since 1999, Groovy brought more to the JVM than Beanshell had and did it using Java's syntax style, unlike Jython. Groovy's also used a lot in scripts for manipulating and testing JVM classes. And it's this use of Groovy that made it a good match for Gradle, i.e. short 50-liners defining builds.
Groovy's been extended to other use cases since then. Graeme Rocher had a meta-object protocol added to Groovy so he could bundle it as the scripting language of Grails (used just like Ruby is in Rails). The backers of Grails have an overbearing attitude towards Groovy, as they do all the software Grails bundles. They muscled in on the consulting market for Spring until they got bought out by SpringSource in 2008. Grails 3, released earlier this year, bundled Gradle for the first time, and the Grails backers will no doubt use that as justification to attack Gradleware's placing in the market for Gradle consulting, and so ultimately wrest control of Groovy via its primary applications from its neutral home at the Apache incubator.
Groovy was also extended in version 2 by a static type-checking and compilation facility, which was duplicated from an addon created by Alex Tkachman. Making no headway into the overcrowded market for statically-typed JVM languages, last year the Groovy backers then repurposed that static-typing facility to make Groovy target the Android platform. This year, Groovy's sole full-time developer supporting it all was retrenched when the Groovy/Grails group moved from VMware/Pivotal to OCI Consulting.
I'm picking Groovy will remain popular on the JVM for scripting and REPL work, including Gradle build scripts, for quite a while. It will never be used much for statically typed work on the JVM or Android, and eventually its use for scripting a web framework will slowly decline as Grails follows Rails into eventual obscurity perhaps 5 years down the line. Groovy will continue to suffer from leadership difficulties, perhaps with the Grails group taking control of Gradle via a sustained attacked on their consulting business, and through this eventually taking over the Groovy code base at, or from, the Apache incubator. I wouldn't want to pick the time frame for all this, though!
And I actually think you belittle Alex with your focus on Groovy++. Alex best work on Groovy was the introduction of callsite caching. That was his best and biggest work. In terms of features of the language there are surely numerous other things. But they are sources of trouble. And that is because he did never finalize his work. Instead he always wanted to have new things and added half-done code to Groovy. That goes for the stub based compilation, for mixins, for many of his internal changes. I could make a really long list. Most of these things have been a huge step forward and a huge source of trouble.