In Java 8, Oracle introduced the new Nashorn engine and is encouraging the use of jjs. It’s a RPEL (read print evaluate loop) for JavaScript. Since JavaScript can call Java, this allows experimenting with Java APIs like you do in other languages like Python and Ruby. I actively disliked it and even wrote a blog post about what turned me off. Java 9 introduced JShell for this same purpose except it works with Java rather than a level of indirection through JavaScript.

In this blog post, I repeat the same experiment with JShell (using the Java 9 early access download) to see if it is any better. Again I used the exercises from Cay Horstmann’s book, Java SE 8 for the Really Impatient so it would be an equivalent experiment.

Exercise 1 – Play … to experiment with an API you want to explore; did you find it easier than writing test programs in Java?

With Nashorn/jjs in Java 8, I had three issues. Let’s see how jjs compares:

Having solved these three issues, the question is a better one. If I’m on a UNIX system or don’t have my IDE open, JShell would definitely be faster. If I already have the IDE open, I have a “PlayTest” program with a main method already available to me so it is a tie. But that’s just my workflow. JShell looks good.

Note: I learned on Twitter that:

wickund: @jeanneboyarsky jjs in JDK9 uses the same API as jshell (JDK9), so there is code completion and up arrow.

Which means my issues with Nashorn are gone in Java 9. Thanks Jim Laskey

Exercise 2 – Using …. the stream library iteratively work out a solution to the problem to print a filtered list of unique long words in sorted order and see how it compares to your usual workflow.

Here was my workflow with JShell:

1. Create the test file in a text editor (vi)
2. Run ./jshell
3. Create a path object
   

   Attempt #	Code	Error	Comments
   1	jshell> Path paths = Path.get(“path/words.txt”)		Success! This package is included in the list of known ones so I didn’t even have to look anything up.

4. Read the file
   

   Attempt #	Code	Error	Comments
   1	jshell> List<String> list = Files.readAllLines(path)		Success

5. Filter the long words
   Worked.

   Attempt #	Code	Error	Comments
   1	jshell> list.stream().grep({ l -> l.length() > 12})	cannot find symbol	This is completely wrong. Aside from the stream() call, it is using Groovy syntax. (I code Groovy at a command line so my fingers started there. I did the same thing when I was doing this with Nashorn)
   2	jshell> list.stream().filter( l -> l.length() > 12)		Success

6. Add sorting and uniqueness
   

   Attempt #	Code	Error	Comments
   1	jshell> list.stream().filter(l -> l.length() > 12).sorted().forEach(System.out::println)		Sorting worked
   2	jshell> list.stream().filter(l -> l.length() > 12).sorted().distinct().forEach(System.out::println)		Uniqueness filter worked

 My thoughts

This was 6 attempts/iterations using JShell.  This is compared to 17 in Nashorn! JShell is clearly a superior tool for prototyping Java. Part of this is because they implement common RPEL features. And part is because they don’t try to shoehorn a rhinoceros into being a Java RPEL. Seriously, many of the problems with Nashorn came from mixing Java and JavaScript while trying to prototype Java.