JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs (original) (raw)
Mario Torre neugens at redhat.com
Thu May 24 09:02:29 UTC 2018
- Previous message: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs
- Next message: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I hear those concern, and I agree with you, but this shows why this is an unwanted feature if any. I find this JEP dangerous to some extent (ok, that may be perhaps a strong wording) because it turns Java into a scripting language without full support from the JLS. Now, the controversial point is clearly the shebang support, the rest seems fine and reasonable, and like others have said if we allow to read files from stdin we should have full equivalence of shell scripting without all the unwanted side effects:
#!/bin/bash exec java --source 11 /dev/fd/3 "$@" 3<<EOF public class Hello { public static void main(String[] args) { String name = System.console().readLine("Please enter your name: "); System.console().printf("Hello, %s!%n", name); } } EOF
Is functionally the same and almost as convenient as:
#!/bin/java public class Hello { public static void main(String[] args) { String name = System.console().readLine("Please enter your name: "); System.console().printf("Hello, %s!%n", name); } }
Except that is proper Java, with all the benefits like debugging, IDE support etc.. in fact, the added benefit is that such utility is more naturally projected toward a use "at the end of their development phase", as it requires a developer to thing through the embedding, but at the same time it keeps the option open, since this is instantly compatible with any scripted java code you may have already around or any actual compiled class, no need to touch anything to make it work in the script, platform idiosyncrasies are where they belong, no special casing. Yes, the difference is really a one liner but the perception in how this is meant to be used is drastic.
I think this should be part of the JEP and the controversial line about Shebang removed instead.
Cheers, Mario
On Wed, May 23, 2018 at 11:01 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
On 5/17/18 1:12 PM, mark.reinhold at oracle.com wrote:
The following JEP is proposed to target JDK 11:
330: Launch Single-File Source-Code Programs http://openjdk.java.net/jeps/330 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Thursday, 24 May, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. - Mark
[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html A number of points have been raised, regarding the interaction with javac and shebang scripts. It was never a goal to modify javac to support shebang-java scripts. This can be seen indirectly in the JEP in the description of how the first line may be removed before passing the rest of the file as a normal CompilationUnit to the compiler. With hindsight, this deserves to be stated as an explicit Non-Goal. There are various reasons to not want to change JLS or javac: 1. Changing JLS is a Big Deal, and comes with its own costs and constraints. Further, shebang files are a platform-specific feature, and are not even defined in the POSIX standard. The feature does not warrant changing a JCP-controlled specification. 2. Changing javac to accept shebang-java files is also a Big Deal. Modifying the command-line options to accept files that do not follow the standard naming conventions would introduce complexity and potential ambiguity. 3. There is no compelling need to change JLS or javac. As demonstrated by the proposed implementation, no change to JLS or javac is actually necessary in order to implement the feature. It is therefore at most a convenience if javac were to be adapted to ignore shebang lines. Shebang scripts are an executable format defined on some, but not all, platforms. Creating a shebang script is typically more than just adding an initial first line to a file; it typically involves a number of steps: a. Add an initial shebang line to the file b. Rename the file to a "command-friendly" name c. Make the file executable d. Install the file in some standard location While renaming the file to a command-friendly name is optional, it is also expected to be common practice. For example, a source file named
HelloWorld.java
might be installed ashelloworld
. And, while the JEP describes use cases for executing a small single-file program withjava_ _HelloWorld.java
or executing it as a platform-specific shebang script with justhelloworld
, it does not seem like there is a common use case to executeHelloWorld.java
. So, if the shebang script is typically renamed to a command-friendly name, it will not be possible to compile it directly, with "javac helloworld", because that is not a valid command line for javac. This reduces any potential convenience of having javac ignore shebang lines. Since Java source files are different artifacts to platform-specific executable scripts, it makes sense to treat them differently, and since we do not want to change the Java language to support shebang lines, the suggestion is to amend the JEP and implementation so that shebang lines are never stripped from Java source files, i.e. files ending in.java
. This avoids the problem of having the ecosystem of tools handling Java source files having to deal with arbitrary artifacts like shebang lines. The change would still permit the direct execution of Java source files, such asjava HelloWorld.java
, and the execution of shebang scripts, such ashelloworld
. -- Jon
-- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
- Previous message: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs
- Next message: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]