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

[Thibault Kruse]

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 <module>[/<mainclass>]


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.

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