JEP proposed to target JDK 11: 330: Launch Single-File, Source-Code Programs

[Thibault Kruse]

Hello, I have a few minor concerns.

# Regarding the command structure

The JEP330 (2018/05/30) states: "The source file should contain one or 
more top-level classes, the first of which is taken as the class to be 
executed.
No other source files are found and compiled, as if the source path is 
set to an empty value."

So why should the java command not continue to take a class name as a 
positional parameter, and get an additional optional parameter like 
"-sourcepath" taking one sourcefile (or later maybe more) to compile?
As it is specified in the JEP, changing the order of top-level classes 
in the file could affect the outcome, something that seems very 
un-java-like. Also this prevents users from specifying classes to run, 
or running nested classes, etc.

The effort of typing

     java HelloWorld.java
     vs.
     java HelloWorld -sourcepath HelloWorld.java

seems small enough to be suffered for this first day of learning java, 
in particular since a shell can easily run commands again from the 
history (the second day of learning java would start with installing an 
IDE).
And that structure does not share the quirks of heuristically guessing 
what the user meant.
Also this would more easily allow later addition of specifying multiple 
files or sourcefolders along with a main class to run.

# Regarding the single-file restriction

Why not allow users to modularize their first few classes in java and 
load them all to run a main method? Teaching them to put all classes in 
a single file does not seem java-like. A source-path option could well 
point to a folder or a list of folders to load sources from.

# Regarding the source filename

JEP330 (2018/05/30) currently also states: "The compiler does not 
enforce the optional restriction defined at the end of JLS §7.6, [...] 
the type name followed by the .java extension. [...] If the file does 
not have the|.java|extension..."
I see no significant benefit in allowing users to use a different 
filename (unless for the shebang line / scripting issue), and IDEs will 
again struggle to turn off compiler errors for such files. I believe it 
is better to keep the experience consistent.

# Regarding jshell as alternative

JEP330 (2018/05/30) currently states jshell "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."

This seems insufficient justification. People are already using jshell 
for this purpose, e.g. see
* 
https://stackoverflow.com/questions/44916618/how-to-execute-a-java-script-with-jshell
* https://gist.github.com/ffissore/012d7e32a096fde5266f49038c93dcaf
* https://dzone.com/articles/jdk9-execute-java-code-like-unix-shell-script
Why burdening java with this feature for interactive programming 
sessions and not jshell seems quite mysterious to me. Several other 
programming languages also have a unified executable for running both 
interactive mode and individual files, so it's not generally considered 
counter-intuitive.
I might be wrong, but jshell seems to be part of the JDK, which would 
also help compared to the java command being part of the JRE, which by 
itself would not be able to compile source files (I assume).

# Regarding POSIX scripting support (shebang lines)

This should be a JEP in it's own right, and may well also consider 
approaches like this: 
https://coderwall.com/p/ssuaxa/how-to-make-a-jar-file-linux-executable
||