JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs
neugens at redhat.com
Fri Jun 1 14:59:52 UTC 2018
I would like to give a bit of feedback following the last discussions
and as a closure since I understand you would like to proceed with the
My main concern is still with the shebang proposal, even in the
current form I find it weird that we need special casing and while I
agree with the points that the JSL (and to some extent the compiler)
should be left out of the equation, at the same time I can't help
thinking that allowing Java code to be run and interpreted as script
should be somewhat regulated. Nevertheless, this is a much better
alternative than the original version so if the strong opinion is to
move forward then I do prefer this version and I won't object further.
Also, the benefit of not touching the spec is that we can revisit this
JEP in the future if we understand more side effects or concerns.
On Fri, May 25, 2018 at 3:55 PM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
> On 5/25/18 3:18 AM, Mario Torre wrote:
>> On Fri, May 25, 2018 at 1:23 AM, Jonathan Gibbons
>> <jonathan.gibbons at oracle.com> wrote:
>>> Regarding your specific proposal for using "here" documents, I do not
>>> your argument that your example is better for being "proper Java, with
>>> the benefits like debugging, IDE support etc.". At least to a casual
>>> observer, the shebang line and the couple of lines to invoke java using a
>>> "here" document look very similar: in both cases, there is a cryptic
>>> followed by some Java source code. In both cases the file can be seen as
>>> script that contains Java source code, as compared to a Java source file
>>> that is a script.
>> The difference is subtle, with the shebang the "#!" is part of the
>> java file, with the here syntax it isn't, that means every single line
>> you write is actually proper java. One is an invalid .java file
>> unrecognized by IDE and compilers, the other is a shell script.
> I agree with your general concern about polluting Java source files,
> which is why we have suggested modifying the feature to prohibit the use
> of shebang lines in Java source files, as identified by a filename ending
> in ".java".  With this proposed change, the source-file launcher
> will only remove shebang lines in files which are not identified as
> Java source files, thus drawing a clear distinction between files which
> are Java source files and those which are not. In particular, there
> will not be any invalid .java files, unrecognized by IDEs and compilers,
> to be worried about.
> -- Jon
>  http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001248.html
>> The implication is that a developer that wants to embed it in a shell
>> script is more forced to think about the embedding as part of the
>> process of writing the utility, but can do so at a later stage with no
>> modifications and without introducing an incompatible java artefact
>> (which is great for reuse for instance).
>> You are right there's not much difference from an IDE point of view
>> though, except that again a .java class that is loaded in an IDE but
>> contains the "#!"line won't be valid and will be unrecognized, while a
>> shell script will be essentially seen as a shell script. I suspect
>> that java code that is mean to be embedded like this will likely be
>> small utilities, but there's nothing stopping someone from creating a
>> full applications in the IDE and then just embed it in a script. The
>> shebang in this case would be tying the two process too tightly, if we
>> only support the here documents we are decoupling things which is
>> better imho.
>>> As to the possible ways forward:
>>> * Support for "//!" is attractive but requires a manual or automated
>>> to the underlying system, which is beyond our control.
>>> * Support for using "here" documents as you suggest is possible: it is
>>> ultimately more flexible than shebang lines, and should be advertised in
>>> JEP, but it requires a more advanced understanding of shell, when much of
>>> the current focus is about simplifying the on-ramp to Java.
>> I would go with that and drop the shebang, I strongly suspect that
>> shebang will create long term problems we are not carefully
>> considering at this stage.
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
More information about the jdk-dev