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

[Jonathan Gibbons]

On 05/31/2018 06:01 AM, Thibault Kruse wrote:
> 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.

This would be an incompatible change, since all parameters after the 
main class are specified to be passed as arguments to the main class.

>
> # 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.

While we permit multiple top level classes in the file, I would not 
recommend it as a style. The use cases here are for beginners writing 
initial small programs, and for use of Java in scripts. Anything beyond 
those use cases is better addressed by existing tools for building 
programs composed of many source files.

>
> # 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.

The desire to disable the file name check is specifically to support the 
shebang/scripting use case.

>
> # 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).

The reasons to prefer incorporating this feature into the launcher, and 
not into jshell, have already been discussed on this alias.

>
> # 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
> ||

FWIW, shebang lines are not specified in POSIX.

Making jar files executable is a wholly different topic to supporting 
the use of Java source code in scripts.

-- Jon