RFR: 8201274: Launch Single-File Source-Code Programs
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs. The work is described in the JEP and CSR, and falls into various parts: * The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file. There are no changes to javac itself. JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ -- Jon
On 2018-04-12 22:15, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ Build changes look trivially fine.
/Magnus
-- Jon
Looks great - some initial comments (I can't really comment on the launcher changes): * This logic is efficient: int magic = (in.read() << 8) + in.read(); boolean shebang = magic == (('#' << 8) + '!'); but convoluted to read; perhaps could be improved slightly by making '#' << 8) + '!' a static constant, and comparing against that. * I note that the reading logic in general could be simplified, e.g. using Files.lines(Path) - but I assume that you wrote the code as is for performance reasons (e.g. to avoid creating too many string objects) ? * I see that both the file manager and the class loader reasonably share the same context: a Map<String, byte[]>. I would make this more explicit, by having a Context class, whose state is the map, and then have the context provide two methods: getClassLoader() getFileManager() This way the sharing will be automatic, no need to extract one field from one place and pass it over to the other place. * Big whohoo for being able to use the enhanced diagnostic framework with a couple of tweaks on the makefile - I hope that would have been the case when I put in the support, but since we have never done it - wasn't 100% sure it would work ;-) Overall I like it quite a lot and I think you went for a really clean design - kudos! Maurizio On 12/04/18 21:15, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
-- Jon
One small followup question - the test SourceLauncherTest is not covering any shebang cases - is that deliberate? I see that those seem to be covered in the launcher test too, but I wonder if we should have tests for clearly broken stuff, such as '#' '#!' '#!\n' Another small question - I see that the shebang process essentially replaces the first line separator with \n - that is probably ok given that the file is processed internally after that - but I wonder if you have thought about pros and cons of preserving the original line separator. Cheers Maurizio On 12/04/18 21:46, Maurizio Cimadamore wrote:
Looks great - some initial comments (I can't really comment on the launcher changes):
* This logic is efficient:
int magic = (in.read() << 8) + in.read(); boolean shebang = magic == (('#' << 8) + '!');
but convoluted to read; perhaps could be improved slightly by making '#' << 8) + '!' a static constant, and comparing against that.
* I note that the reading logic in general could be simplified, e.g. using Files.lines(Path) - but I assume that you wrote the code as is for performance reasons (e.g. to avoid creating too many string objects) ?
* I see that both the file manager and the class loader reasonably share the same context: a Map<String, byte[]>. I would make this more explicit, by having a Context class, whose state is the map, and then have the context provide two methods:
getClassLoader() getFileManager()
This way the sharing will be automatic, no need to extract one field from one place and pass it over to the other place.
* Big whohoo for being able to use the enhanced diagnostic framework with a couple of tweaks on the makefile - I hope that would have been the case when I put in the support, but since we have never done it - wasn't 100% sure it would work ;-)
Overall I like it quite a lot and I think you went for a really clean design - kudos!
Maurizio
On 12/04/18 21:15, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
-- Jon
On 4/13/18 4:15 AM, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
This looks quite good to me. One small comment on the source launcher Main class: 122 } catch (InvocationTargetException e) { 123 // leave VM to handle the stacktrace, in the standard manner 124 throw e.getTargetException(); 125 } 387 } catch (InvocationTargetException e) { 388 // remove stack frames for source launcher 389 int invocationFrames = e.getStackTrace().length; 390 Throwable target = e.getTargetException(); 391 StackTraceElement[] targetTrace = target.getStackTrace(); 392 target.setStackTrace(Arrays.copyOfRange(targetTrace, 0, targetTrace.length - invocationFrames)); 393 throw e; 394 } This could simply throw target instead of the InvocationTargetException and then the main method can propagate the target, if thrown. Mandy
On 04/12/2018 10:20 PM, mandy chung wrote:
On 4/13/18 4:15 AM, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
This looks quite good to me. One small comment on the source launcher Main class:
122 } catch (InvocationTargetException e) { 123 // leave VM to handle the stacktrace, in the standard manner 124 throw e.getTargetException(); 125 } 387 } catch (InvocationTargetException e) { 388 // remove stack frames for source launcher 389 int invocationFrames = e.getStackTrace().length; 390 Throwable target = e.getTargetException(); 391 StackTraceElement[] targetTrace = target.getStackTrace(); 392 target.setStackTrace(Arrays.copyOfRange(targetTrace, 0, targetTrace.length - invocationFrames)); 393 throw e; 394 }
This could simply throw target instead of the InvocationTargetException and then the main method can propagate the target, if thrown.
Mandy
Mandy, Yes, but that would require the execute method and its callers to declare that they throw Throwable, or at least Exception. Since the exception is already wrapped, it seems better to propagate the wrapped exception, and to only unwrap it at the last moment. -- Jon
On 4/25/18 8:53 AM, Jonathan Gibbons wrote:
On 04/12/2018 10:20 PM, mandy chung wrote:
This looks quite good to me. One small comment on the source launcher Main class:
122 } catch (InvocationTargetException e) { 123 // leave VM to handle the stacktrace, in the standard manner 124 throw e.getTargetException(); 125 } 387 } catch (InvocationTargetException e) { 388 // remove stack frames for source launcher 389 int invocationFrames = e.getStackTrace().length; 390 Throwable target = e.getTargetException(); 391 StackTraceElement[] targetTrace = target.getStackTrace(); 392 target.setStackTrace(Arrays.copyOfRange(targetTrace, 0, targetTrace.length - invocationFrames)); 393 throw e; 394 }
This could simply throw target instead of the InvocationTargetException and then the main method can propagate the target, if thrown.
Mandy
Mandy,
Yes, but that would require the execute method and its callers to declare that they throw Throwable, or at least Exception. Since the exception is already wrapped, it seems better to propagate the wrapped exception, and to only unwrap it at the last moment.
Either way works for me. Mandy
The javac part looks OK to me. A nit comment, in: launcher/Main.java/MemoryFileManager#createInMemoryClassFile, there is: return new FilterOutputStream(new ByteArrayOutputStream()) { ... It could I think be written as: return new ByteArrayOutputStream() { @Override public void close() throws IOException { super.close(); byte[] bytes = toByteArray(); map.put(className, bytes); } }; (I.e. without the cast to ByteArrayOutputStream.) Jan On 12.4.2018 22:15, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
-- Jon
Hi John, I focused mainly on the native side, looks ok, except for a couple of minor issues. java.c 1320 const char *prop = "-Djdk.internal.javac.source="; 1321 size_t size = JLI_StrLen(prop) + JLI_StrLen(value) + 1; 1322 char *propValue = (char *)JLI_MemAlloc(size + 1); I think we are allocating extra byte ^^^^^^^ 1323 JLI_StrCpy(propValue, prop); 1324 JLI_StrCat(propValue, value); I think we can do this, safer and neater, as follows: size_t size = JLI_StrLen(prop) + JLI_StrLen(value); char *propValue = (char *)JLI_MemAlloc(size + 1); JLI_Snprintf(propValue, size, "%s%s", prop, value); 1483 if (mode == LM_SOURCE) { 1484 AddOption("--add-modules=ALL-DEFAULT", NULL); 1485 *pwhat = SOURCE_LAUNCHER_MAIN_ENTRY; 1486 *pargc = argc + 1; 1487 *pargv = argv - 1; A short comment perhaps ? why we are incrementing argc, and decrementing argv, saves some head scratching for a casual reader. I looked at the launcher tests, very nice. Thanks Kumar On 4/12/2018 1:15 PM, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
-- Jon
Kumar, Thank you for your feedback; I will incorporate it in the next webrev. -- Jon On 04/25/2018 09:38 AM, Kumar Srinivasan wrote:
Hi John,
I focused mainly on the native side, looks ok, except for a couple of minor issues.
java.c 1320 const char *prop = "-Djdk.internal.javac.source="; 1321 size_t size = JLI_StrLen(prop) + JLI_StrLen(value) + 1; 1322 char *propValue = (char *)JLI_MemAlloc(size + 1);
I think we are allocating extra byte ^^^^^^^
1323 JLI_StrCpy(propValue, prop); 1324 JLI_StrCat(propValue, value);
I think we can do this, safer and neater, as follows:
size_t size = JLI_StrLen(prop) + JLI_StrLen(value); char *propValue = (char *)JLI_MemAlloc(size + 1); JLI_Snprintf(propValue, size, "%s%s", prop, value); 1483 if (mode == LM_SOURCE) { 1484 AddOption("--add-modules=ALL-DEFAULT", NULL); 1485 *pwhat = SOURCE_LAUNCHER_MAIN_ENTRY; 1486 *pargc = argc + 1; 1487 *pargv = argv - 1;
A short comment perhaps ? why we are incrementing argc, and decrementing argv, saves some head scratching for a casual reader.
I looked at the launcher tests, very nice.
Thanks Kumar
On 4/12/2018 1:15 PM, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
-- Jon
Here's an update to the previously proposed patch for JEP 330: Launch Single-File Source-Code Programs. It includes all review feedback so far. The changes are mostly minor, but with the addition of more test cases. The webrev includes a delta-webrev for those that just want to see what has changed since last time. Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html Original webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html Delta webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html Note that the work is temporarily blocked by JDK-8202387: javac --release 11 not supported. A fix for that is underway and in review: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011868.html This work has been tested using a workaround for this issue, and will be tested again when the real fix is in place. -- Jon On 04/12/2018 01:15 PM, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
-- Jon
On 5/4/18 2:59 PM, Jonathan Gibbons wrote:
Here's an update to the previously proposed patch for JEP 330: Launch Single-File Source-Code Programs. It includes all review feedback so far. The changes are mostly minor, but with the addition of more test cases.
The webrev includes a delta-webrev for those that just want to see what has changed since last time.
Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html
Original webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html Delta webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html
I looked through the change and it looks fine to me. Mandy
Thumbs up - thanks for taking the comments into account. Great job! Maurizio On 04/05/18 22:59, Jonathan Gibbons wrote:
Here's an update to the previously proposed patch for JEP 330: Launch Single-File Source-Code Programs. It includes all review feedback so far. The changes are mostly minor, but with the addition of more test cases.
The webrev includes a delta-webrev for those that just want to see what has changed since last time.
Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html
Original webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html Delta webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html
Note that the work is temporarily blocked by JDK-8202387: javac --release 11 not supported. A fix for that is underway and in review: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011868.html This work has been tested using a workaround for this issue, and will be tested again when the real fix is in place.
-- Jon
On 04/12/2018 01:15 PM, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
-- Jon
On 11.5.2018 12:31, Maurizio Cimadamore wrote:
Thumbs up - thanks for taking the comments into account.
Great job!
+1 Jan
Maurizio
On 04/05/18 22:59, Jonathan Gibbons wrote:
Here's an update to the previously proposed patch for JEP 330: Launch Single-File Source-Code Programs. It includes all review feedback so far. The changes are mostly minor, but with the addition of more test cases.
The webrev includes a delta-webrev for those that just want to see what has changed since last time.
Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html
Original webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html Delta webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html
Note that the work is temporarily blocked by JDK-8202387: javac --release 11 not supported. A fix for that is underway and in review: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011868.html This work has been tested using a workaround for this issue, and will be tested again when the real fix is in place.
-- Jon
On 04/12/2018 01:15 PM, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
-- Jon
Not a reviewer, but a minor comment: src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java + private Path getFile(String[] args) throws Fault { .... + if (!Files.exists(file)) { + // should not happen when invoked from launcher + throw new Fault(Errors.FileNotFound(file)); + } Do you think it would be better to check that the passed source file path is indeed a regular file, instead of just checking for existence, so that it won't then run into IOException in the readFile method, if the passed path happens to a directory? -Jaikiran On 05/05/18 3:29 AM, Jonathan Gibbons wrote:
Here's an update to the previously proposed patch for JEP 330: Launch Single-File Source-Code Programs. It includes all review feedback so far. The changes are mostly minor, but with the addition of more test cases.
The webrev includes a delta-webrev for those that just want to see what has changed since last time.
Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html
Original webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html Delta webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html
Note that the work is temporarily blocked by JDK-8202387: javac --release 11 not supported. A fix for that is underway and in review: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011868.html This work has been tested using a workaround for this issue, and will be tested again when the real fix is in place.
-- Jon
On 04/12/2018 01:15 PM, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
-- Jon
Just gave the patch a try by locally building it. Works great! :) A minor comment- the java usage/help text shows this: Usage: java [options] <mainclass> [args...] (to execute a class) or java [options] -jar <jarfile> [args...] (to execute a jar file) or java [options] -m <module>[/<mainclass>] [args...] java [options] --module <module>[/<mainclass>] [args...] (to execute the main class in a module) or java [options] java source-file [args] Do you think that last line could instead be: or java [options] <source-file> [args] (to launch a single-file source-codeprogram) to be consistent with the rest of the usage text? -Jaikiran On 05/05/18 3:29 AM, Jonathan Gibbons wrote:
Here's an update to the previously proposed patch for JEP 330: Launch Single-File Source-Code Programs. It includes all review feedback so far. The changes are mostly minor, but with the addition of more test cases.
The webrev includes a delta-webrev for those that just want to see what has changed since last time.
Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html
Original webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html Delta webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html
Note that the work is temporarily blocked by JDK-8202387: javac --release 11 not supported. A fix for that is underway and in review: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011868.html This work has been tested using a workaround for this issue, and will be tested again when the real fix is in place.
-- Jon
On 04/12/2018 01:15 PM, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
-- Jon
Belated reply, but yes, thanks for pointing this out. -- Jon On 05/12/2018 09:21 PM, Jaikiran Pai wrote:
Just gave the patch a try by locally building it. Works great! :)
A minor comment- the java usage/help text shows this:
Usage: java [options] <mainclass> [args...] (to execute a class) or java [options] -jar <jarfile> [args...] (to execute a jar file) or java [options] -m <module>[/<mainclass>] [args...] java [options] --module <module>[/<mainclass>] [args...] (to execute the main class in a module) or java [options] java source-file [args]
Do you think that last line could instead be:
or java [options] <source-file> [args]
(to launch a single-file source-codeprogram)
to be consistent with the rest of the usage text?
-Jaikiran
On 05/05/18 3:29 AM, Jonathan Gibbons wrote:
Here's an update to the previously proposed patch for JEP 330: Launch Single-File Source-Code Programs. It includes all review feedback so far. The changes are mostly minor, but with the addition of more test cases.
The webrev includes a delta-webrev for those that just want to see what has changed since last time.
Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html
Original webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html Delta webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html
Note that the work is temporarily blocked by JDK-8202387: javac --release 11 not supported. A fix for that is underway and in review: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011868.html This work has been tested using a workaround for this issue, and will be tested again when the real fix is in place.
-- Jon
On 04/12/2018 01:15 PM, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
-- Jon
Please review a minor update to the proposed implementation of JEP 330. The primary change is to disallow the use of the "shebang" feature in Java source files (i.e. files whose name ends in ".java") as recently proposed on this list [1]. There is some additional minor cleanup to the launcher -help text. In the webrev, the overall changes can be seen in the main webrev index. The recent changes can be see in the delta-webrev named "v3" in the main webrev index page. JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/ -- Jon [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001248.html On 04/12/2018 01:15 PM, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
-- Jon
I reviewed the delta-webrev (v3). Looks good. Thanks for fixing missing newlines in launcher.properties Mandy On 5/30/18 12:00 PM, Jonathan Gibbons wrote:
Please review a minor update to the proposed implementation of JEP 330.
The primary change is to disallow the use of the "shebang" feature in Java source files (i.e. files whose name ends in ".java") as recently proposed on this list [1].
There is some additional minor cleanup to the launcher -help text.
In the webrev, the overall changes can be seen in the main webrev index. The recent changes can be see in the delta-webrev named "v3" in the main webrev index page.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/
-- Jon
[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001248.html
On 04/12/2018 01:15 PM, Jonathan Gibbons wrote:
Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs.
The work is described in the JEP and CSR, and falls into various parts:
* The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file.
There are no changes to javac itself.
JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
-- Jon
participants (7)
-
Jaikiran Pai
-
Jan Lahoda
-
Jonathan Gibbons
-
Kumar Srinivasan
-
Magnus Ihse Bursie
-
mandy chung
-
Maurizio Cimadamore