JEP 222

Among the few truly new features recently confirmed for Java 9 (alongside Project Jigsaw’s modularity) is a Java Shell that introduces the first REPL function to Java. Java Executive Committee member Werner Keil explains how Java’s new REPL got started and what it’s good for.

As proposed in OpenJDK JEP 222, the JShell offers a REPL (Read-Eval-Print Loop) to evaluate declarations, statements and expressions of the Java language, together with an API allowing other applications to leverage its functionality. The idea is not exactly new. BeanShell has existed for over 15 years now, nearly as long as Java itself, not to mention many scripting languages on Scala and Groovy also featuring similar shells already.

BeanShell (just like Groovy, too by the way) made an attempt of standardisation by the Java Community Process in JSR 274 – a JSR that did not produce any notable output, in spite of the fact that (or perhaps because?) two major companies, Sun and Google, had joined the expert group. Under the JCP.next initiative this JSR was declared “Dormant”.

An eyebrow-raising approach

Adding a new Java feature like this via JEP, rather than waking up the “Dormant” JSR (which anyone could, including Oracle who now owns former EG member Sun), raised some eyebrows among JCP EC members. One concern was that after the JCP had just merged its ME and SE/EE parts into a single body, developing more and more platform features not as JSRs but JEPs under the OpenJDK would create another rift between ME/SE (JDK) and EE where most remaining JSRs then resided.

Device I/O, derived from an Oracle proprietary predecessor under Java ME, was already developed as an OpenJDK project. Without a JEP, it seems Oracle at least can also ratify such projects without prior proposal. The farce around JSR 310, which neither produced an actual Spec document mandatory to pretty much all JSRs, nor (according to Co-Spec Lead Stephen Colebourne) comes with a real API similar to other SE platform JSRs like Collections, was another example of where the JSR should have been withdrawn or declared dormant when the JEP started. It was just meant to rubberstamp some JDK part by the EC, without the actual result of the JSR outside of the OpenJDK.

SEE ALSO: 5 features in Java 9 that WILL change how you develop software (and 2 that won’t)

Every class has some Javadoc, so that doesn’t really count. Given Oracle’s strong involvement we are likely to see more JEPs under the OpenJDK. And having a transparent opensource effort behind these parts of the Java ecosystem is still better than a closed environment, so even if it may disenfranchise and weaken some of the JCP (and EC), it is better than no open development at all.

Potential uses of the JShell

Having such a shell in Java is certainly not a bad idea. Regardless of its development under Java SE, future versions of Java EE may find a standard shell even more appealing than Java SE. The value for Java ME remains to be seen, especially if down-scaling like Device I/O is even possible. But at the very least, IoT devices running Java SE Embedded should clearly benefit.

Windows PowerShell has become a strong preference for system administration or DevOps teams, at least on Windows and .NET. This is used by its Play Framework for administrative tasks, while Groovy is used for similar purposes by the Spring Framework, or under the hood of the JBoss Admin Shell. Meanwhile, WebLogic Scripting Tool (WLST) emerged from Jython, a Python shell on the JVM. Java EE Reference Implementation GlassFish has an admin shell called asadmin. Being able to tap into a unified Java shell in future versions could certainly make life easier for many Java-based projects, as well as products, developers and ops using them.

Other interesting fields of use are domain-specific extensions. Groovy, Scala or other shell-enabled languages (both on the JVM and outside of it) are very popular for business or scientific calculations. Based on early impressions with JShell, messages like assigned to temporary variable $3 of type int can be quite misleading (Figure 1).

In particular the financial domain tends to think of US dollars when they read “$”, so that still has room for improvement. But almost natural language queries such as Google answers questions like “what is 2 plus 2”, or a pretty NoSQL DB of its time like Q&A, offering such features ten years before the Java language even started to have great potential. Instead of simply asking “2+2” questions, users may ask what the temperature in their living room is, when backed by a Smart Home solution. Or using JSRs like 354, the recently finished Money API, questions like “2$ in CHF” or similar would make great sense too. That’s where temporary variables quoting $ amounts would be a bit confusing, but maybe the JDK team behind JShell finds other ways to phrase that.

Another great example of a Java-powered REPL and expression language for scientific and other arithmetic challenges is Frink, named after the weird scientist character in The Simpsons TV series. It answers all sorts of questions, starting from date/time or time zone conversions (which java. time aka JSR 310 could certainly be used for, too) or currency conversions like:

"600 baht -> USD"

Frink provides much more mathematical and physical formulas, including unit conversion. Based on JSR 363, the upcoming Java Units of Measurement standard, this will be possible in a similar way. With Groovy, co-founder Guillaume Laforge has documented a DSL/REPL for Units of Measurements using JSR 275 a while back. Their solution was used in real-life medical research for Malaria treatments. Of course, being written in Java, someone might also simply expose the actual Frink language and system via JShell under Java 9!