April 2016 - core-libs-dev

RFR [9] 8147543: Remove sun.misc.ManagedLocalsThread
by Chris Hegarty 22 Apr '16

22 Apr '16

Another remaining JEP 260 task that can now be resolved ( remove a non-Critical API from sun.misc ). With all the subtasks of 8147543 [1] complete, i.e. all the dependencies on ManagedLocalsThread have been removed, it is time to remove the type itself ( its functionality has been superseded by the new Thread constructor [2] ). The changes are trivial: $ hr rm src/jdk.unsupported/share/classes/sun/misc/ManagedLocalsThread.java -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8147543 [2] https://bugs.openjdk.java.net/browse/JDK-8056152

2 1

Multi-Release JAR runtime support
by Hervé BOUTEMY 22 Apr '16

22 Apr '16

Hi OpenJDK Core Developers, Today, to prepare a conference talk on Java 9 (DevoxxFR, on wednesday 20th), I tested once again Maven proposed layout to produce Multi-Release JARs: https://github.com/hboutemy/maven-jep238 And I added a little script (. run-demo.sh) to run the build then execute the resulting jar with JRE 7, 8 and 9. As expected, JRE 7 and 8 gave the same result, since my JRE 8 isn't patched to support MR JARs (if there is a simple way to add support, don't hesitate to give me a pointer. Or if there is any standard Java 8 build that should support it). But the unexpected part is that JRE 9, either classical or jigsaw, don't take advantage of the MR JAR: is this really expected, or did I do something wrong? Regards, Hervé Here is the interesting part of the output of the script: Archive: multirelease/target/multirelease-0.8-SNAPSHOT.jar testing: META-INF/MANIFEST.MF OK testing: base/Base.class OK testing: mr/A.class OK testing: META-INF/versions/8/mr/A.class OK testing: META-INF/versions/9/mr/A.class OK No errors detected in compressed data of multirelease/target/multirelease-0.8- SNAPSHOT.jar. [...] # Run Multi Release JAR with JRE 7 $ java -classpath multirelease/target/multirelease-0.8-SNAPSHOT.jar base.Base 1.7.0_71-b14 BASE # Run Multi Release JAR with JRE 8 $ java -classpath multirelease/target/multirelease-0.8-SNAPSHOT.jar base.Base 1.8.0_25-b17 BASE # Run Multi Release JAR with JRE 9 classic $ java -classpath multirelease/target/multirelease-0.8-SNAPSHOT.jar base.Base 9-ea+114 BASE # Run Multi Release JAR with JRE 9 Jigsaw $ java -classpath multirelease/target/multirelease-0.8-SNAPSHOT.jar base.Base 9-ea+114-2016-04-15-162029.javare.4859.nc BASE

5 9

Review request 8154837: Class::getPackage with exploded modules when classes in modules defined to the boot loader
by Mandy Chung 22 Apr '16

22 Apr '16

Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8154837/webrev.00/ The module location from an exploded image is file URL rather than file path. This issue can be reproduced with jdk/test/java/lang/Package/GetPackages.java on windows. Mandy

3 3

RFR(S): 8154754: MethodHandles.countedLoop errors in deriving loop arguments, result type, and local state
by Michael Haupt 22 Apr '16

22 Apr '16

Dear all, please review this change. It depends on the one about 8154751 posted earlier [1]. Bug: https://bugs.openjdk.java.net/browse/JDK-8154754 Webrev: http://cr.openjdk.java.net/~mhaupt/8154754/webrev.00/ Thanks, Michael [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040386.html -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

2 3

RFR(S): 8154751: MethodHandles.countedLoop does not accept empty bodies
by Michael Haupt 22 Apr '16

22 Apr '16

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8154751 Webrev: http://cr.openjdk.java.net/~mhaupt/8154751/webrev.00/ Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

2 2

RFR(S): 8152667: MHs.iteratedLoop(...) throws unexpected WMTE, disallows Iterator subclasses, generates inconsistent loop result type
by Michael Haupt 22 Apr '16

22 Apr '16

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8152667 Webrev: http://cr.openjdk.java.net/~mhaupt/8152667/webrev.00/ Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

2 2

RFR [9] 8154919: Remove superfluous jdk.unsupported from tools/launcher/modules/limitmods/LimitModsTest.java
by Chris Hegarty 22 Apr '16

22 Apr '16

The jdk.unsupported module was added to the LimitModsTest.java test temporally, until the problematic dependency from the java.logging module on the jdk.unsupported module could be resolved. This is now resolved, see 8153158 [1]. It was an oversight of the changes for 8153158 that this test was not updated to remove the, now superfluous, dependency the jdk.unsupported module. diff --git a/test/tools/launcher/modules/limitmods/LimitModsTest.java b/test/tools/launcher/modules/limitmods/LimitModsTest.java --- a/test/tools/launcher/modules/limitmods/LimitModsTest.java +++ b/test/tools/launcher/modules/limitmods/LimitModsTest.java @@ -103,10 +103,10 @@ public void testWithAddMods() throws Exception { int exitValue; - // java -limitmods java.base -addmods java.logging,jdk.unsupported -listmods + // java -limitmods java.base -addmods java.logging -listmods exitValue = executeTestJava("-limitmods", "java.base", "-addmods", - "java.logging,jdk.unsupported", // TODO: add bug No. + "java.logging", "-listmods") .outputTo(System.out) .errorTo(System.out) -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8153158

2 2

JDK 9 RFR of JDK-8153933: Remove intermittent key from TimeZone/Bug6772689.java and move back to tier1
by Amy Lu 22 Apr '16

22 Apr '16

java/util/TimeZone/Bug6772689.java This test was failing intermittently (JDK-8149898, JDK-8150804). Mentioned issues have been resolved and no open bug (no failure reported) till now. This patch is to remove @key intermittent from the test and move it back to tier1. bug: https://bugs.openjdk.java.net/browse/JDK-8153933 webrev: http://cr.openjdk.java.net/~amlu/8153933/webrev.00/ Thanks, Amy --- old/test/TEST.groups 2016-04-21 15:32:52.000000000 +0800 +++ new/test/TEST.groups 2016-04-21 15:32:52.000000000 +0800 @@ -32,7 +32,6 @@ -java/util/WeakHashMap/GCDuringIteration.java \ -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ -java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ - -java/util/TimeZone/Bug6772689.java \ sun/nio/cs/ISO8859x.java \ java/nio/Buffer \ com/sun/crypto/provider/Cipher \ @@ -43,7 +42,6 @@ java/util/WeakHashMap/GCDuringIteration.java \ java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ - java/util/TimeZone/Bug6772689.java \ :jdk_io \ :jdk_nio \ -sun/nio/cs/ISO8859x.java \ --- old/test/java/util/TimeZone/Bug6772689.java 2016-04-21 15:32:53.000000000 +0800 +++ new/test/java/util/TimeZone/Bug6772689.java 2016-04-21 15:32:53.000000000 +0800 @@ -24,7 +24,6 @@ /* * @test * @bug 6772689 - * @key intermittent * @summary Test for standard-to-daylight transitions at midnight: * date stays on the given day. */

2 1

@Deprecated(since) and Javadoc
by Paul Benedict 22 Apr '16

22 Apr '16

Is there a requirement that the new "since" attribute on @j.l.Deprecated lead to an automatic JavaDoc @deprecated in the doc generation? It's a bona fide replacement, right? I'm just curious because I think, if that's true, @j.l.Deprecated should mention this tool coordination in its own JavaDoc header. Cheers, Paul

3 4

java.lang.reflect.Module.WeakSet is not thread-safe
by Peter Levart 21 Apr '16

21 Apr '16

Hi, While browsing code in java.lang.reflect.Module (I sometimes do that just to see how thinks work ;-) I stumbled on the following nested class: private static class WeakSet<E> { private final ReadWriteLock lock = new ReentrantReadWriteLock(); private final Lock readLock = lock.readLock(); private final Lock writeLock = lock.writeLock(); private final WeakHashMap<E, Boolean> map = new WeakHashMap<>(); /** * Adds the specified element to the set. */ void add(E e) { writeLock.lock(); try { map.put(e, Boolean.TRUE); } finally { writeLock.unlock(); } } /** * Returns {@code true} if this set contains the specified element. */ boolean contains(E e) { readLock.lock(); try { return map.containsKey(e); } finally { readLock.unlock(); } } } ...while this seems OK from 1st look, it is not. WeakHashMap is not thread-safe even for seemingly read-only operations. All its operations can mutate internal state in a non-thread-safe way. The simplest way to fix this is to use a writeLock for containsKey operation too. But such structure does not scale well to multiple threads for frequent lookups. WeakSet is used in Module to keep track of transient read edges, exports and uses of services added dynamically to the module. Modification operations are not so performance critical, but lookup operations are. I propose to add a thread-safe WeakPairMap data structure which associates a pair of weakly-reachable keys with a strongly-reachable value based on ConcurrentHashMap. Such data structure is footprint-friendly, since only a single instance exists for a particular purpose, totaling 3 instances for the transient structures serving all Modules in the system: http://cr.openjdk.java.net/~plevart/jdk9-dev/Module.WeakSet.multithreadUnsa… So, what do you think? Regards, Peter

1 1