April 2017 - core-libs-dev

RFR: 8178480: Wrong exception being thrown on an invalid MethodType
by Claes Redestad 11 Apr '17

11 Apr '17

Hi, JDK-8178387 subtly and inadvertently changed what exception was being thrown by LambdaForm.compileToBytecode in certain cases - this patch reverts this simplification and adds a comment to warn against future attempts to simplify too much.. Bug: https://bugs.openjdk.java.net/browse/JDK-8178480 diff -r 9363dd4a4fb9 src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java --- a/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Tue Apr 11 18:57:46 2017 +0200 +++ b/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Tue Apr 11 21:35:59 2017 +0200 @@ -673,9 +673,7 @@ /** * Generate customized bytecode for a given LambdaForm. */ - static MemberName generateCustomizedCode(LambdaForm form) { - final MethodType invokerType = form.methodType(); - + static MemberName generateCustomizedCode(LambdaForm form, MethodType invokerType) { MemberName pregenerated = lookupPregenerated(form, invokerType); if (pregenerated != null) return pregenerated; // pre-generated bytecode diff -r 9363dd4a4fb9 src/java.base/share/classes/java/lang/invoke/LambdaForm.java --- a/src/java.base/share/classes/java/lang/invoke/LambdaForm.java Tue Apr 11 18:57:46 2017 +0200 +++ b/src/java.base/share/classes/java/lang/invoke/LambdaForm.java Tue Apr 11 21:35:59 2017 +0200 @@ -847,9 +847,10 @@ if (vmentry != null && isCompiled) { return; // already compiled somehow } - assert(vmentry == null || vmentry.getMethodType().basicType().equals(methodType())); + MethodType invokerType = methodType(); // forces IAE to happen outside try-catch block + assert(vmentry == null || vmentry.getMethodType().basicType().equals(invokerType)); try { - vmentry = InvokerBytecodeGenerator.generateCustomizedCode(this); + vmentry = InvokerBytecodeGenerator.generateCustomizedCode(this, invokerType); if (TRACE_INTERPRETER) traceInterpreter("compileToBytecode", this); isCompiled = true; Thanks! /Claes

2 2

RFR(XS) : 8178340: remove unneeded "throws" from ProcessTools::createJavaProcessBuilder
by Igor Ignatyev 11 Apr '17

11 Apr '17

http://cr.openjdk.java.net/~iignatyev//8178340/webrev.00/index.html > 8 lines changed: 0 ins; 2 del; 6 mod; Hi all, could you please review this tiny fix which clean up testlibary? ProcessTools::createJavaProcessBuilder methods can not throw any checked exceptions, but were declared with 'throws Exception', which forced all users of these methods to either have redundant try-catch or throws. the fix cleans up the method declaration in all three copies of testlibary. webrev: http://cr.openjdk.java.net/~iignatyev//8178340/webrev.00/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8178340 testing: hotspot, jdk, langtools and jaxp tests Thanks, -- Igor

2 2

RFR 9: 8178347 Process and ProcessHandle getPid method name inconsistency
by Roger Riggs 11 Apr '17

11 Apr '17

Please review this change to the name of the ProcessHandle.getPid and Process.getPid methods as observed and recommended in email: [1] The methods are new in JDK 9 and the renaming corrects the method name style to be consistent within each class. The change sets propagate the name change to the openjdk uses of the pid method. Libraries using getPid will need to be updated. Issue: https://bugs.openjdk.java.net/browse/JDK-8178347 Webrevs: http://cr.openjdk.java.net/~rriggs/webrev-pid-8178347 http://cr.openjdk.java.net/~rriggs/webrev-pid-jaxp-8178347 http://cr.openjdk.java.net/~rriggs/webrev-pid-jdk-8178347 http://cr.openjdk.java.net/~rriggs/webrev-pid-hotspot-8178347 Thanks, Roger [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-April/047103.html

3 5

[10] RFR: 8178384: Reduce work in java.lang.invoke initializers
by Claes Redestad 11 Apr '17

11 Apr '17

Hi, profiling initializers in java.lang.invoke shows we're still doing various things during class initialization which could be done lazily or not at all. The proposed patch reduce bytecode executed, memory churn and retained heap footprint when initializing java.lang.invoke: Webrev: http://cr.openjdk.java.net/~redestad/8178384/jdk.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8178384 Testing: java.lang.invoke jtreg tests, sanity performance testing Thanks! /Claes

5 10

RFR 9: JDK-8178012: Finish removal of -Xmodule:
by Jan Lahoda 11 Apr '17

11 Apr '17

Hi, javac used to have an option, -Xmodule:, that allowed to compile given sources as if they were part of the specified module. This functionality has been merged into the --patch-module option, but the -Xmodule: option couldn't be fully removed at that time, as some tests and tools (e.g. jtreg) depended on it. The option was however removed from the javac help, etc. Since jtreg can use --patch-module instead of -Xmodule: now, I'd like to propose further demoting the option to an unsupported -XD-Xmodule: setting (the functionality is not removed completely, as there is a small amount of remaining dependencies). The option may be removed completely eventually when the remaining dependencies are resolved. The patch spans many repositories besides langtools, as it adjusts TEST.ROOT files, and the <top-level>/test/lib/jdk/test/lib/InMemoryJavaCompiler.java. The latter is used by hotspot tests, and this change is a small tweak to translate -Xmodule: to --patch-module. This could be later improved by enhancing the test library API to pass the module name explicitly. Bug: https://bugs.openjdk.java.net/browse/JDK-8178012 Webrev: http://cr.openjdk.java.net/~jlahoda/8178012/webrev.00/ Any feedback is welcome. Thanks, Jan

2 1

[9] RFR 8177969: Faster FilePermission::implies by avoiding the use of Path::relativize
by Weijun Wang 10 Apr '17

10 Apr '17

http://cr.openjdk.java.net/~weijun/8177969/webrev.00/ This new implementation of containsPath(Path,Path) uses the logic of Path::relativize without directly calling it, which is much faster now. Thanks Max

3 6

JDK 10 RFR of 8176894: Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute in TreeMap
by Sergey Kuksenko 10 Apr '17

10 Apr '17

Hi All, Please, review: https://bugs.openjdk.java.net/browse/JDK-8176894 http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.00/ The issue was created for JDK10 in order to don't disturb JDK9 before launch. -- Best regards, Sergey Kuksenko

5 10

Review Request: JDK-8177855: Clean up legal files
by Mandy Chung 10 Apr '17

10 Apr '17

Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177855/webrev.00/index.html The patch is trivial: diff --git a/src/jdk.xml.bind/share/legal/relaxngdatatype.md b/src/jdk.xml.bind/share/legal/relaxngdatatype.md --- a/src/jdk.xml.bind/share/legal/relaxngdatatype.md +++ b/src/jdk.xml.bind/share/legal/relaxngdatatype.md @@ -3,7 +3,7 @@ ### RelaxNG Datatype License <pre> -Copyright (c) 2001, Thai Open Source Software Center Ltd, Sun Microsystems. +Copyright (c) 2005, 2010 Thai Open Source Software Center Ltd All rights reserved. Redistribution and use in source and binary forms, with or without diff --git a/src/java.desktop/share/legal/jpeg.md b/src/java.desktop/share/legal/jpeg.md --- a/src/java.desktop/share/legal/jpeg.md +++ b/src/java.desktop/share/legal/jpeg.md @@ -1,4 +1,4 @@ -## JPEG release 6b +## Independent JPEG Group: JPEG release 6b ### JPEG License <pre> diff --git a/src/jdk.crypto.ec/share/legal/ecc.md b/src/jdk.crypto.ec/share/legal/ecc.md --- a/src/jdk.crypto.ec/share/legal/ecc.md +++ b/src/jdk.crypto.ec/share/legal/ecc.md @@ -6,7 +6,8 @@ This notice is provided with respect to Elliptic Curve Cryptography, which is included with JRE, JDK, and OpenJDK. -You are receiving a copy of the Elliptic Curve Cryptography library in source +You are receiving a [copy](http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/bd00098fc2d7/src/jdk.cr… +of the Elliptic Curve Cryptography library in source form with the JDK and OpenJDK source distributions, and as object code in the JRE & JDK runtimes.

3 3

[10] RFR: 8178387: Reduce memory churn when creating java.lang.invoke entities
by Claes Redestad 10 Apr '17

10 Apr '17

Hi, another startup optimization for java.lang.invoke, this one collecting a set of small fixes I've been wanting to get done for a while, including: - no need to generate the signature strings in BoundMethodHandle.makeCbmhCtor - trusted MethodType lookups could be promoted without constructing new objects - InvokerBytecodeGenerator: creation of className and sourceFile can be done lazily, which reduces String allocations in those cases where there's a pre-generated form to be found - MethodType lookup done twice when looking up pregenerated members (oops!) - A lot of vararg array creation during startup in various places. A larger rewrite could be warranted, but we can some startup gain by simply constant-izing oft-used constant arguments such as MethodType.invokerType Webrev: http://cr.openjdk.java.net/~redestad/8178387/jdk.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8178387 Test: java.lang.invoke jtreg tests, verified each change in this patch (and JDK-8178384) reduces the amount of bytecode executed during lambda bootstrap. Thanks! /Claes

2 4

JDK 9 RFR(s): 8150488: add note to Scanner.findAll() regarding possible infinite streams
by Stuart Marks 08 Apr '17

08 Apr '17

Hi all, Please review these non-normative textual additions to the Scanner.findAll() method docs. These methods were added earlier in JDK 9; there's a small pitfall if the regex can match zero characters. Thanks, s'marks # HG changeset patch # User smarks # Date 1490749958 25200 # Tue Mar 28 18:12:38 2017 -0700 # Node ID 6b43c4698752779793d58813f46d3687c17dde75 # Parent fb54b256d751ae3191e9cef42ff9f5630931f047 8150488: add note to Scanner.findAll() regarding possible infinite streams Reviewed-by: XXX diff -r fb54b256d751 -r 6b43c4698752 src/java.base/share/classes/java/util/Scanner.java --- a/src/java.base/share/classes/java/util/Scanner.java Mon Mar 27 15:12:01 2017 -0700 +++ b/src/java.base/share/classes/java/util/Scanner.java Tue Mar 28 18:12:38 2017 -0700 @@ -2808,6 +2808,10 @@ * } * }</pre> * + * <p>The pattern must always match at least one character. If the pattern + * can match zero characters, the result will be an infinite stream + * of empty matches. + * * @param pattern the pattern to be matched * @return a sequential stream of match results * @throws NullPointerException if pattern is null @@ -2829,6 +2833,11 @@ * scanner.findAll(Pattern.compile(patString)) * }</pre> * + * @apiNote + * The pattern must always match at least one character. If the pattern + * can match zero characters, the result will be an infinite stream + * of empty matches. + * * @param patString the pattern string * @return a sequential stream of match results * @throws NullPointerException if patString is null

3 12