What are the limits to JShell?

Well, of course, its confined to a bring a normal REPL utility in terms of scoping what an IDE and graphical user interfaces could provide. I would talk of more about its capabilities as compared to single source code programs. The features that keeps it apart still from single source code programs:

• a history with editing
• tab-completion
• automatic addition of needed terminal semicolons and
• configurable predefined imports and definitions

As mentioned in the alternatives to Single-File Source-Code Programs JEP as well:

We could delegate the task of "one-off runs" to the jshell tool. While this may at first seem obvious, this was an explicit non-goal in the design of jshell.

The jshell tool was designed to be an interactive shell, and many design decisions were made in favor of providing a better interactive experience.

Burdening it with the additional constraints of being the batch runner would detract from the interactive experience.

---

!!! Limitations and behavior!!!

On the other hands, few limitations(assumed functionalities) that one would mostly find while performing a hands-on using JShell rather than simply reading the docs would be :

• use of final variables final variables are not functioning well in jshell

• of course Debugging with JShell

• integration of jshell with IDEs Java 11 JShell inside Intellij IDEA

• disabling history Disable JShell history

• redeclared variables should be reset In jshell-11, why does a redeclared reference variable that resets to null still have a type?

• create module using jshell Create Module in JShell in Java 9

• importing private package classes Importing Package-Private Classes to JShell

• scope of objects Access to "parent scope" in JShell

• clear jshell console How to clear Java 9 JShell Console?

!!! Features and more !!!

More details over the links that gives it an upper hand over Single File Source Code Programs :

• why and how Why and how do you use JShell?

• import classpath for a project In JShell, how to import classpath from a Maven project

• run an application via JShell How to run a java application with jshell?

• set custom feedback modes Create custom feedback mode in jshell

• load scripts on startup Different ways to load script on jshell startup

• list active methods List all active methods in jshell

• run a jshell file How to run a JShell File?

• execute javascript with jshell How to execute a java script with jshell?

• how to use method references in jshell Is there a way to use method references for top-level functions in jshell?

Answering the updated question

All problems can be solved with snippets (and with a sufficiently complicated shell script, too). But JShell is best used to debug and learn java - a full-fledged program is much more flexible for all other use-cases.

JShell, .jsh and java MyClass.java

JShell is an interactive shell for trying out java code. Essentially, it is a REPL for Java.

Since JShell is all about you typing in code snippets, which it then evaluates, and it often makes sense to put those snippets in a file instead of writing them several times, JShell supports .jsh scripts, which contain collections of snippets to be interpreted by JShell. In this sense, this is similar to bash accepting .sh files or command.com accepting .bat files -- typing them line by line is equivalent to importing them.

Single-source java-file execution is a very different beast. It is sugar that replaces, from JDK 11 onwards,

java MyClass.java arg1 arg2 arg3

by your local scripting equivalent of writing

TMPDIR=$(mktemp -d)
javac -d $TMPDIR MyClass.java
java -cp $TMPDIR MyClass arg1 arg2 arg3
rm -rf $TMPDIR

This allows single-source files to be quickly executed from the command line with a single command, and without leaving their compiled classes all over the place (no actual temporary directory needs to be created, as java can store those classes in memory). Since they already had 3 other execution modes in java (for classes, jar-files and modules), it is no great stretch to add this as a fourth one.

Since OP wanted a picture:

Java as a scripting language

Now that the distinction is clear (.jsh is for use with JShell, single-source java executables are only for, you guessed it, single-source java executables), what about using Java as a scripting language?

You have always had the option to write a launcher; for example,

 #!/bin/bash
 java -jar MyApp.jar

has worked for ages. It was technically possible to name a class directly, but not too useful, as jar files are far more handy when distributing binaries -- for one thing, they avoid mirroring the package structure as a bunch of folders. Having a launcher script as separate from the actual java code was, however, still somewhat unfriendly: you now need to keep both together, or at least have the launcher be able to locate the actual .jar to launch.

Now, they have also introduced the following shortcut: regardless of file name or extension, you can distribute your java source with a "shebang prefix" as follows:

#!/path/to/java --source 11
<source of MyClass.java>

mark it as executable, and launch it from the command-line just as you can launch any other executable. For example, copy and paste this into a helloworld file (and fix the jdk location before attempting to run it):

#!/opt/jdk-11.0.1/bin/java --source 11 
public class Test {
    public static void main(String ... args) {
        System.out.println("Hello " + (args.length == 0 ? "world!" : args[0]));
    }
}

After marking it as executable, you can launch it directly with

$ ./helloworld
Hello world!

and it even takes its arguments right:

$ ./helloworld Bob!
Hello bob!

For small programs, and provided you do not need to go outside of the JDK to pull in additional libraries, it will now be vastly easier to distribute java code for command-line use.

Java will still not be a "scripting language" (it will never compete with, say, python), but

• it has a very nice REPL loop
• you can execute short programs a lot easier