JShell: Just a Little Disappointing

Java developers have waited a long time for JShell. It’s here now. Is it really what we waited for? Sorry, but some doubts linger on my mind.

First, a confession. Due to whatever reasons I stayed on with Java 8 for an eternity. Recently I was bounced into a new project and landed in Java 12 with a splash. JShell was one of several features I had to get acquainted with.

As you already know, JShell is a read-eval loop tool that makes Java interactive. It’s not the first of its kind. From the Java 5 days I remember Bean shell (bsh) with affection. Groovy tools, groovysh and groovyConsole, have also helped mould my expectations for the first official Java shell.

Some petty details tripped up my first attempts. JShell does not honor the CLASSPATH environment variable, and does not take a -classpath command line argument (it’s named –class-path). In my mind there is a kind of tradition around these things. It makes JShell seem a bit out of touch. EDIT: Additionally, if you use the /env command to define the classpath the spelling is -class-path, no typo here.

A similar nitpicking complaint is that you exit JShell with /exit. There is no /quit command. Command line tools have an unspoken tradition of having both.

The big thing, however, is: strong typing or not? The answer depends on why you use a read-eval tool in the first place. Is it to write polished code? Or is it to check out prototype code? I can only speak for myself, but I use read-eval for quick hacks. For instance, when checking out a new API or a new database I often use real-eval to get something working, like a sketch or a prototype. From the sketch I write real code.

So I prefer less rigid typing. Like Bean shell. Like Groovy shell. In those tools you may introduce new variables without any declaration at all. Its value has a type, of course. It’s only that you don’t have to go through generics paroxysms to declare it.

Unfortunately for me, JShell takes the uncompromising strong typing stand. This is the Java spirit, it’s correct in a mathematical sense. It’s hard to complain about it. However, I prefer having an occasional escape from the “correctness comes before productivity” doctrine. I would have liked JShell being such an escape. After all, javac will uphold the Java language definition.

Did I just hear objections from the rear stands? How can anything go before correctness? True enough. My point is that Java is a lot of boilerplate. We all know that types have to be declared and exceptions caught. In an experimental phase I’d like to leave out the boilerplate. It’s doable.

Given the background of strong typing, it’s a bit surprising that JShell does not require a semicolon to terminate commands. Groovy also does not require semicolons. There is a difference, however. Groovy “knows” when a line requires a continuation. For instance, a line ending with an operator like “+” must be continued. It seems JShell does not accept line breaks at all. One command, one line.

Something that seems like a JShell bug is that an XML file on the class path is not accepted. Having configuration files on the classpath is not uncommon. (EDIT: A previous mention of an exception tracing problem was erroneous.)

Finally, kudos to JShell for the reload command. It saves precious developer hours by reloading classes on the class path.