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

[Jonathan Gibbons]

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 <module>[/<mainclass>]
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 <filename>", the file must have a .java 
extension.

-- Jon