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:
![Venn diagram showing how JShell, .jsh and JEP330 intersect]()
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
