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

[Roman Kennke]

Thanks Brian and Jon for clarification. I'd be happy with a short version of this in the non-goals section of the JEP.

Also, //! sounds like a cool idea. Indeed I seem to remember that some version of Unix already does this (was it some BSD variant to support csh scripts? don't remember...)

Cheers, Roman
(/me goes back to the beach...)

Am 24. Mai 2018 02:41:20 MESZ schrieb Brian Goetz <brian.goetz at oracle.com>:
>
>
>> On 21/05/18 16:41, Brian Goetz wrote:
>>> I think this is mostly a "glass 5% empty" argument.  Let's retrace
>our
>>> steps.
>> Before we 'retrace' may I ask: was that meant to be 5% or 50%?
>
>I did mean 5%.  The small number was not intended to minimize Roman's 
>concern, but to minimize the place of the shebang feature in this JEP 
>itself.  In setting our goals for the project, shebang support was 
>always a pretty small, and entirely optional, part of the picture (a 
>"stretch goal").  So if a small part of the whole is somewhat smaller 
>than some might prefer, the difference is, necessarily, pretty small.  
>(If we hadn't found a reasonably stable place to draw the line (I think
>
>we were kind of lucky to have done so), we would have been perfectly 
>fine to have no shebang support, but I do think the status quo is much 
>better than that.)
>
>> It certainly is not what I
>> was expecting and hoping to hear given your use of the word
>'retrace'.
>
>OK, let me explain the sense of "retrace" here.  As one of the 
>instigators for this project, I am in a position to speak 
>authoritatively to motivation, intentions, and goals.  While we of 
>course attempt to lay these out in the JEP and in related 
>communications, the reality is that one will never capture all the 
>possible tradeoffs and interpretations in a short document.  So, when 
>someone comes along with a different idea of what the goals of the 
>project could have been, the sensible first step is to go back to our 
>motivation, and clarify, in the context of the current relevant 
>question.  (This isn't necessarily a failing of the expression of the 
>JEP; no one would be served by a 200 page JEP that tries to anticipate 
>every possible interaction and interpretation, and the cost of
>producing 
>such a document would be way out of line with its value.)  So by 
>retrace, I mean "let's go back to the inception of the project, which
>is 
>necessarily uncaptured, and look at the thoughts that were in our heads
>
>at that time that might shed light on how we ended up where we did."
>
>Since my first attempt seems to have missed the mark, let me retrace in
>
>slightly more detail.
>
>We have spent countless hours listening to people's concerns about
>Java; 
>these come from a wide range of sources, including developers,
>students, 
>teachers, etc.  A general theme that people have expressed concern over
>
>is "activation energy"; that doing simple things in Java requires too 
>much fixed work.  Examples include:
>  - you have to download/install a JDK and IDE before you can write 
>Hello World
>  - "public static void main"
>  - You have to compile HelloWorld.java before you run it.
> - Many libraries have a large fixed setup cost before you can do
>anything.
>  - the list goes on
>
>Obviously, even a small amount of brainstorming along these lines could
>
>generate hundreds of man-years of project work, so we can't do all of 
>them.  So we made subjective choices about which had the best impact, 
>and we consider both the cost (in multiple dimensions) and benefit (or 
>our subjective estimates of the benefits) when making these choices.
>
>One example of a project aimed, at least in part, at this problem was 
>JShell.  I think this was very successful (but it was surely 
>expensive.)  JEP 330 has both a smaller cost and a smaller benefit, but
>
>the balance seemed in line, and the cost was in budget.  So the goal 
>here was to simplify approachability and streamline simple tasks that 
>are perceived to have a high subjective activation energy.  That's the 
>backdrop behind why we undertook this in the first place -- it provides
>
>some relief in the activation energy department, as long as it has a 
>reasonable balance of cost and benefit.
>
>Actually, the step-retracing goes much farther back than this.  When we
>
>did jshell, we considered whether jshell should also serve as a "batch 
>script runner", and this issue has been brought up plenty of times 
>since.  But from the very beginning of the jshell project, we felt 
>strongly that this would be asking jshell to serve two masters; jshell 
>is intended as an interactive tool, and many decisions were made in 
>favor of a better interactive experience.  If people want to just run a
>
>single Java file in source form, a more principled approach would be to
>
>teach the launchers about source files -- which was entirely practical,
>
>and a much better fit for "I just want to run a 'script' file that is 
>written in Java."  So the seeds of this project were sown several years
>
>ago, and over those years, there have been many discussions (in many 
>places) about how to address this particular use case.
>
>When we first started discussing this feature, we were thinking mostly 
>in terms of a more streamlined means of execution, but it didn't take 
>long to ask the question about packaging.  If people want to write 
>"scripty" programs in Java, once developed, they're going to want to 
>package and install them, and this is also a high-activation-energy 
>aspect of Java (JARs, build scripts, etc). Shebang is a very 
>low-overhead form of packaging, and -- as long as it didn't perturb the
>
>main goal or drive the cost or complexity over budget -- seemed to
>offer 
>pretty reasonable incremental benefit for a not-terrible incremental
>cost.
>
>But, one can go too far, and turning this into a language feature would
>
>have been taking it too far.  The Java Language and VM try very hard to
>
>be platform-neutral; shebang is definitively not platform-neutral. 
>And, 
>anything having to do with the language spec incurs greater costs (I'm 
>not just talking development costs) and complexity.  So, this isn't a 
>language feature, it's a platform integration feature.  Which is why
>the 
>launcher is the right vehicle here -- this is where the Java platform 
>meets the underlying platform.
>
>Volker raised this question early on.  We had already thought about the
>
>implications of this (we generally think pretty deeply about the many 
>possible roads one could take before we propose a project), and we 
>didn't like them -- because, as mentioned above, this is a platform 
>integration issue, not a language issue.  I don't deny that it would be
>
>nice in certain situations if we made no distinction between "Java 
>source file" and "scripts that happen to contain Java source code" -- 
>and that might be a perfectly reasonable choice for some other
>languages 
>-- but the goal was never "Java as a scripting language".   So, while 
>"why not go all the way with shebang" is a reasonable question to ask, 
>it seemed (and still seems) the wrong match for Java.  When the
>question 
>came up again (as they always do in a large community), no new 
>information had come to light to cause us to come to a different 
>conclusion.
>
>Jon's distinction here between "Java source file", and a separate
>notion 
>of "script that contains Java code" or "platform-specific executable 
>script", is a good one; we'd implicitly been thinking of these as two 
>different things, but its clear that this is confusing to people, and 
>making the distinction explicit should dispel some of that confusion.  
>Sure, they _could_ be merged, but highlighting this distinction seems 
>much more in keeping with the spirit of the platform than blurring the 
>distinction (though that might be a fine choice for other languages.)  
>So, +1 to Jon's suggestion.
>
>So, what can be done here?  We could:
>  - move forward with the feature, as is.
>  - clarify the distinction between "Java source file" and "script 
>containing Java", and tweak accordingly, as Jon suggests.
>  - drop the JEP entirely.
>  - drop the shebang support and keep the rest.
>
>What does not seem like a reasonable choice is to turn the Java
>Language 
>into a platform-dependent thing, for all the reasons Jon mentioned, and
>
>more.
>
>> I am afraid that adopting pejorative terms like 'infecting' doesn't
>> really make your case stronger.
>
>I'm sorry if you were offended by my use of this term.  I take the Java
>
>Language very seriously, and defend its boundaries vigorously!
>
>
>Cheers,
>-Brian

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.