Jshell: The Java Shell (REPL)
openjdk.java.net
openjdk.java.net
Meant, as the name implies, for Groovy, but since Java is a subset of Groovy, works fine for any Java code, too.
It's great for quickly trying out an API or library. Also makes it easy to just drop a bunch of jar files onto the classpath.
Java is not a subset of Groovy. Some syntax valid in both will behave differently in each, e.g. default visibility, and how == behaves.
My experience of using it is that tells me that without a undefined type keyword it becomes very boring to use. Each time you have to define a variable you have to write all type info:
Map<String,String> foo = new HashMap<>();
var foo = new HashMap<String,String>();
Not quite var, and it would require the interpreter to do a little bit more work when invoking methods to avoid the necessary downcasting.
Map<String, String> foo = new HashMap<>();
Last time I checked it, in 2010, it didn't had any commits.
However, there is a community fork "beanshell2"[1], which was created exactly because the original was left to rot. It looks like the most recent change to beanshell2 was February 2014, so it may be going the same direction.
[1]: https://github.com/pejobo/beanshell2 (formerly https://code.google.com/p/beanshell2/
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.
Drop by, check it out & please stop the Snarky "Should have had it 10 yrs ago" comments.
It's probably better to categorize things based on (pick one of) semantic, runtime (JVM vs Beam vs blablabla), productivity, correctness, readability etc.
> Do your coworkers never have to go in and maintain your code? What about after you leave?
I wrote an extension to our core app that is needed by 2 customers. Someone might need to touch it again one day, but it's more likely that a new spec will demand new engineering for a new solution in the future, at which point the most favorable technology will be used. That goes for me or the next person.
> Do you not have to pull request the code before it's merged in?
No. I'm a full-time employee and a core committer. We already have extensions in Java, Groovy, (very limited, nearly dead experiment) Jython, and now Clojure. Technically my extension is Java and it is a thin wrapper to a Clojure library.
> At the end of the day it IS just a jar, but that ignores all the non-runtime aspects of coding.
They are de minimis in this case. It survived review with nominal eyebrows raised. It's a Java shop but they're familiar with the family of other JVM languages.
HTH.
I will never relocate just to change programming language.
My question is, what took so long? What prevented it?
Reinventing the wheel is so human...
And to think that when I advocated for writing business logic in a scripted language in 2003 everyone was looking at me like I was crazy (well italy is always quite behind last trends, so while in the states they were starting with scripting languages we were still writing ejb with xml - and we still do in many places)