JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs
roman at kennke.org
Thu May 24 09:45:41 UTC 2018
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...)
(/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
>> 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
>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
>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
>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
>these come from a wide range of sources, including developers,
>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
> - "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
> - 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
>pretty reasonable incremental benefit for a not-terrible incremental
>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.
>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
>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
>-- 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
>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
>Jon's distinction here between "Java source file", and a separate
>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
>into a platform-dependent thing, for all the reasons Jon mentioned, and
>> 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!
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
More information about the jdk-dev