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

Jonathan Gibbons jonathan.gibbons at oracle.com
Wed May 23 21:16:16 UTC 2018



On 5/17/18 11:05 PM, Volker Simonis wrote:
> ...
>
> Also notice that the shebang problem is not the only source of
> incompatibility, but also the proposal that "the compiler does not
> enforce the optional restriction defined at the end of JLS §7.6, that
> a type in a named package should exist in a file whose name is
> composed from the type name followed by the .java extension". The
> restriction is "optional", but to my knowledge still widely adapted
> (and I'm not sure, but this may still require a change to the current
> compiler in contrast to what Brian mentioned in the earlier
> conversation).
>
> Thank you and best regards,
> Volker
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/thread.html#718
>
Volker,

With regard to this specific issue, you are correct to say that this 
convention
is widely adopted, and enforced by existing use of javac. The reason for
the convention is to help compilers, including javac, locate the 
definition of
classes on the source path should that be necessary.

JEP 330 only proposes to relax the constraint for the specific case in
question: when compiling a single-file program for invocation by
the proposed single-file source-code launcher.  The reason that this
is acceptable is that by construction, no other source file will be looking
for the file in question on the source path.

It may be worth noting that if we had chosen to support reading additional
source files from the source path, we would have enforced the standard
naming convention for those files: the relaxed rule only applies to the
file being executed.

Finally, Brian was, and is, correct to say that there has been no change to
javac in the implementation of this feature. The change in behavior for
the source naming rule was accomplished by suitable configuration of
the file objects being passed to the compiler via the Compiler API in
the javax.tools package.

-- Jon


More information about the jdk-dev mailing list