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

Jonathan Gibbons jonathan.gibbons at oracle.com
Fri Jun 1 14:54:15 UTC 2018

On 5/31/18 8:06 PM, Thibault Kruse wrote:

On Fri, Jun 1, 2018 at 3:42 AM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:

On 05/31/2018 06:01 AM, Thibault Kruse wrote: 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,... This would be an incompatible change, since all parameters after the main class are specified to be passed as arguments to the main class. Ok, sorry, The options would have to come before the class name, like java -sourcepath HelloWorld.java HelloWorld Note module notation also allows disambiguating classes: java [options] -m [/] Adding more compilation-related options to the JVM-launcher command is a slippery slope that is best avoided..

The point being the structure could be made flexible enough to specify a class to run in several ways, and java could simply error out if there were multiple top-level classes to run instead of picking the first. I am not passionate about the exact alternative syntax, I would just like to know why disambiguating the class to run instead of picking the first one found in the file was chosen as the best solution. This is not mentioned in the JEP I think.

# 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. Initial small programs may still span multiple files. Many online java tutorials will use multiple files. Even for the purpose of scripting, it can make good sense to spread code over multiple script files. A similar scenario is to have teams where some members will appropriate tools, but some team-members don't (As an example, teams of Java-experts and newcomers deciding on the language to use for a new project). In that case, just to allow the non-tool-users to run the main class, all team members would be forced to work on the source as a single file. By allowing multiple files, you enable easier cooperation between such users. If you want to develop small programs spanning multiple files, it is better to use existing tools (javac, jar, java).

# 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. So if the shebang support were declared a non-goal, the filename check would be kept intact? I believe files needing to be run with the java command should have a standard java filename extension.

If you are just using "java ", the file must have a .java extension.

-- Jon

More information about the jdk-dev mailing list