Draft JEP: Launch Single-File Source-Code Programs

Jonathan Gibbons jonathan.gibbons at oracle.com
Mon Feb 12 20:26:42 UTC 2018

On 02/12/2018 11:43 AM, David Lloyd wrote:
> On Thu, Feb 8, 2018 at 5:18 PM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>> This draft JEP contains a proposal to enhance the java launcher to support
>> running a
>> program supplied as a single file of Java source code. The program will be
>> compiled
>> and run, without the need to explicit invoke javac, or to package up a jar
>> file.
>> For more details, see:
>> http://openjdk.java.net/jeps/8192920
> Sorry if I just missed this somehow, but how would one set the Java
> source version in use?  This seems like it would be necessary in order
> to ensure forwards-compatibility.

This would only be an issue for shebang files; if you are using the Java
launcher explicitly, the source version would be the default version
for the Java launcher.  For shebang files, it is normal practice to put
an absolute pathname for the executable. If you are concerned about
long term compatibility, you could use the path for a specific version
of JDK.

> Other scripting languages that launch in this way allow for printing
> (or disabling) compilation warnings, so maybe that should also be a
> consideration?
It's an interesting issue that merits discussion.  JLS does mandate
that warnings should be generated in some circumstances, but allows
them to be suppressed with @SuppressWarnings.  javac does generate
some warnings that cannot be suppressed with @SuppressWarnings,
but in all such cases, it is possible to change the source code to avoid
the warning without changing the underlying functionality. The bottom
line is that it should always be possible to compile a program without
warnings, and so there should be no need to provide any extra mechanisms
in this area in the Java launcher.

> I assume that the annotation processing pipeline would explicitly be
> excluded in this mode?
It is not clear to me that there is an inherent need to disable the 
processing pipeline, but it is true that if it is not disabled, its use 
be severely restricted, not least by the inability to specify any custom
options for annotation processing. Performing annotation processing would
seem to be way beyond the anticipated use cases, and so it may end up
being desirable, for simplicity, to disable annotation processing in 
this mode.

The general rule here is, if you need to pass options to the compiler,
you should be invoking the compiler directly, in the standard manner.

> Also I'm finding it really hard to avoid saying "Java script".  /me
> slaps self briskly

More information about the jdk-dev mailing list