April 2016 - core-libs-dev

RFR JDK9 (JAXP) 8152527: Relative rewriteSystem with xml:base at group level failed
by huizhe wang 13 Apr '16

13 Apr '16

Hi, Please review a fix to rewrite* matching issue. When the rewrite* entries are in a group entry, the current match with entries in a group entry needs to be recorded just as when they are outside of a group. JBS: https://bugs.openjdk.java.net/browse/JDK-8152527 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8152527/webrev/ Thanks, Joe

2 1

Review request 8153895 (proxy) redundant read edges to superinterfaces of proxy interfaces
by Mandy Chung 13 Apr '16

13 Apr '16

Peter spots the redundant read edges are added to dynamic module when creating a proxy class. Proxy class does not access super interfaces of proxy interfaces. I have verified this simple patch with all core tests and JCK api tests. diff --git a/src/java.base/share/classes/java/lang/reflect/Proxy.java b/src/java.base/share/classes/java/lang/reflect/Proxy.java --- a/src/java.base/share/classes/java/lang/reflect/Proxy.java +++ b/src/java.base/share/classes/java/lang/reflect/Proxy.java @@ -804,11 +804,6 @@ continue; } ensureAccess(target, c); - - // add all superinterfaces - for (Class<?> intf : c.getInterfaces()) { - deque.add(intf); - } } // set up proxy class access to types referenced in the method signature

4 11

RFR 9: 8086278 : java/lang/ProcessHandle/TreeTest.java failed - ProcessReaper StackOverflowException
by Roger Riggs 13 Apr '16

13 Apr '16

Please review an increase in the default stack size of the Process reaper thread to 48K from 32k. Some tests with various VM arguments are failing intermittently. The failures are not reproducible. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-reaper-stack-8086278/ Issue: https://bugs.openjdk.java.net/browse/JDK-8086278 Thanks, Roger

3 6

Expecting Integer.valueOf(String) to accept Literal format ...
by kedar mhaswade 13 Apr '16

13 Apr '16

While discussing with colleagues, someone said: However, my main gripe is about not supporting in String representation of > an integer what is supported in its literal representation. > Thus, Integer x = 1_000_000; is valid, whereas > Integer.valueOf("1_000_000") is not. That sucks. It seems to me that this is a reasonable expectation and has practical benefits (e.g. accepting program arguments that are integers with _'s). Supporting underscores in number literals (beginning JDK 7) was meant for readability of the Java source code. Perhaps doing this correctly incurs unwarranted implementation complexity in the JDK. As library writers however, how would you explain this mismatch? Was this side effect (arguably so) considered at all? Regards, Kedar

9 12

RFR: 8148568: LoggerFinder.getLogger and LoggerFinder.getLocalizedLogger should take a Module argument instead of a Class.
by Daniel Fuchs 13 Apr '16

13 Apr '16

Hi, Please find below a patch that slightly modifies the JEP 264 initial implementation to take advantage of the module system. The change modifies the LoggerFinder abstract service to take the Module of the caller class as parameter instead of the caller class itself. The caller class was used in the initial 9/dev implementation because java.lang.reflect.Module was not yet available. http://cr.openjdk.java.net/~dfuchs/jigsaw/webrev_8148568/webrev.01/ best regards, -- daniel

2 3

RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations
by Tagir F. Valeev 13 Apr '16

13 Apr '16

Hello! Please review and sponsor the following patch: http://cr.openjdk.java.net/~tvaleev/webrev/8153293/r1/ The patch preserves more characteristics on primitive stream operations: IntStream/LongStream/DoubleStream.boxed() preserves SORTED and DISTINCT IntStream.asLongStream() preserves SORTED and DISTINCT IntStream.asDoubleStream() and LongStream.asDoubleStream() preserves SORTED (different longs can be converted into the same double, so DISTINCT is not preserved here; not sure whether this is possible for ints) Fixing the boxed() case is especially important as distinct() for primitive streams is implemented like boxed().distinct().unbox, so the actual distinct() operation cannot take the advantage of DISTINCT flag (skip the operation at all) or SORTED flag (switch to more efficient implementation). Here's the small JMH benchmark which measures the performance boost of quite common operation: sort the input numbers and leave only distinct ones: http://cr.openjdk.java.net/~tvaleev/webrev/8153293/jmh/ new Random(1).ints(size).sorted().distinct().toArray() I've got the following results. 9ea+111: Benchmark (size) Mode Cnt Score Error Units SortDistinctTest.sortedDistinct 10 avgt 30 0,612 ± 0,004 us/op SortDistinctTest.sortedDistinct 1000 avgt 30 92,848 ± 1,039 us/op SortDistinctTest.sortedDistinct 100000 avgt 30 32147,205 ± 3487,422 us/op 9ea+111 patched: Benchmark (size) Mode Cnt Score Error Units SortDistinctTest.sortedDistinct 10 avgt 30 0,435 ± 0,001 us/op SortDistinctTest.sortedDistinct 1000 avgt 30 40,555 ± 0,772 us/op SortDistinctTest.sortedDistinct 100000 avgt 30 9031,651 ± 73,956 us/op With best regards, Tagir Valeev.

3 7

RFR 8151705 VarHandle.AccessMode enum names should conform to code style
by Paul Sandoz 13 Apr '16

13 Apr '16

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151705-VH-AccessMode-names/we… I was persuaded (in internal CCC review) to change the enum VarHandle.AccessMode constant names to conform to the expected Java style. Previously, for convenience, the names corresponded exactly with the VH sig-poly method names. Most of the patch is just refactoring. I have added two new methods to translate to/from the sig-poly method name domain: 1175 /** 1176 * Returns the {@code VarHandle} signature-polymorphic method name 1177 * associated with this {@code AccessMode} value 1178 * 1179 * @return the signature-polymorphic method name 1180 * @see #valueFromMethodName 1181 */ 1182 public String methodName() { 1183 return methodName; 1184 } 1185 1186 /** 1187 * Returns the {@code AccessMode} value associated with the specified 1188 * {@code VarHandle} signature-polymorphic method name. 1189 * 1190 * @param methodName the signature-polymorphic method name 1191 * @return the {@code AccessMode} value 1192 * @throws IllegalArgumentException if there is no {@code AccessMode} 1193 * value associated with method name (indicating the method 1194 * name does not correspond to a {@code VarHandle} 1195 * signature-polymorphic method name). 1196 * @see #methodName 1197 */ 1198 public static AccessMode valueFromMethodName(String methodName) { 1199 AccessMode am = methodNameToAccessMode.get(methodName); 1200 if (am != null) return am; 1201 throw new IllegalArgumentException("No AccessMode value for method name " + methodName); 1202 } Paul.

5 6

RFR JDK 9 (JAXP) 8151162: Public entries not searched when prefer='system'
by huizhe wang 12 Apr '16

12 Apr '16

Hi, Please review a fix for the issue that caused public entries not being searched when prefer='system'. When prefer='system', the Catalog standard only required that public entries were not searched if there is a system identifier. I added tests to reflect a combination of the settings of prefer, identifier(s), and entry types (public and/or system). The test "matchWithPrefer" covered the three test cases in the JCK mentioned in the bug report plus 9 other scenarios, while "resolveWithPrefer" covered 18 resolution scenarios by a CatalogResolver. JBS: https://bugs.openjdk.java.net/browse/JDK-8151162 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8151162/webrev/ Thanks, Joe

2 2

RFR: 8154067: Avoid early use of limited privilege escalation in InnerClassLambdaMetafactory
by Claes Redestad 12 Apr '16

12 Apr '16

Hi, the first usage of limited doPrivileged appears to have a small startup penalty (loads 8 permission-related classes and does some reflection), and is arguably excessive for this particular instance. Unrestricted doPrivileged allows for a small reduction of lambda init cost. Webrev: http://cr.openjdk.java.net/~redestad/8154067/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8154067 Thanks! /Claes

5 5

Request for comments -- resource reification vs. mrjar scheme for runtime versioning of multi-release jar files
by Steve Drach 12 Apr '16

12 Apr '16

We’ve identified two possible ways to address issue JDK-8151542. <https://bugs.openjdk.java.net/browse/JDK-8151542> One way is to append a #runtime fragment to the input URL in URLClassPath to convey to URLJarFile that we want to have the JarFile opened with the parameter Release.RUNTIME, so any loaded classes are runtime versioned. This is currently implemented and was integrated as part of issue JDK-8132734 <https://bugs.openjdk.java.net/browse/JDK-8132734> For this case, a resource URL returned from ClassLoader.getResource(s) is reified, that is the returned URL does not have the #runtime fragment appended to it, instead the URL points directly to the desired entry. The other way is to create a new URL scheme “mrjar” so that when URLJarFile sees the URL it knows to open the Jarfile with the Release.RUNTIME parameter. No fragment is required. A returned resource URL will be of the form “mrjar:<url>!/{entry} We’ve put together the following list of pros/cons for each approach. We’re soliciting feedback from the mailing list. We currently have a working patch for the reification approach, but not one for the new scheme approach. reification pros — . produces a standard/normal URL pointing directly to the jar entry . the String equivalent is parsable so it shouldn’t affect legacy code reification cons — . exposes the internals of a jar (i.e explicitly shows the META-INF/versions directory) . the input URL is modified by attaching a #runtime fragment to it . URL is not “portable” across jars as platform release version changes mrjar scheme pros — . one URL that always points to runtime versioned entries . the same URL (with entry appended) is returned by the getResource method . portable across different platform releases . jigsaw has also introduced a new URL scheme mrjar scheme cons — . may break String based parsing of URLS . non-standard URL scheme . what does it mean with non MR files? . we haven’t put together a prototype yet As I said, we’re soliciting feedback from the list. My personal opinion is that we should go with what we have, the reification approach, since it’s least likely to break existing code.

1 0