May 2016 - core-libs-dev

RFR JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register()
by Xueming Shen 26 May '16

26 May '16

Hi, Please help review the changes for the following zipfs related bug fixes JDK-8147539: (zipfs) ZipPath should throw ProviderMismatchException when invoking register() JDK-8153248: (zipfs) ZipPath#getFileName( ) returns inconsistent result JDK-8146754: (zipfs) ZipPath.relativize() returns wrong result for path ending with slash / JDK-8139956: (zipfs) ZipPath does not produce correct empty path on relativize() issue: https://bugs.openjdk.java.net/browse/JDK-8147539 https://bugs.openjdk.java.net/browse/JDK-8153248 https://bugs.openjdk.java.net/browse/JDK-8146754 https://bugs.openjdk.java.net/browse/JDK-8139956 webrev: http://cr.openjdk.java.net/~sherman/8139956_8146754_8147539_8153248/webrev/ The changes are relative easy. (1) ZipPath.initOffsets() should deal with empty path specially, as the UnixPath impl does (2) ZipPath.normalize(byte[]) should take care of tailing "/" (it is taken care of at ZipPath.normalize(byte[], int), but is missed in the "main" method) (3) ZipPath.register() should throw PME as suggested. Thanks, Sherman

5 12

JDK 9 RFR of JDK-8157663: Remove tools/jimage/JImageTest.java from ProblemList.txt
by Amy Lu 26 May '16

26 May '16

tools/jimage/JImageTest.java This test is in ProblemList.txt with related bugid JDK-8150975. JDK-8150975 has been closed since previously reported image recreate issue now is not an issue anymore because the support for jimage recreate has been removed in JDK-8154090, in which test also updated. This patch is to remove mentioned test from ProblemList.txt. bug: https://bugs.openjdk.java.net/browse/JDK-8157663 webrev: http://cr.openjdk.java.net/~amlu/8157663/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2016-05-26 12:45:36.000000000 +0800 +++ new/test/ProblemList.txt 2016-05-26 12:45:36.000000000 +0800 @@ -390,7 +390,5 @@ # core_tools -tools/jimage/JImageTest.java 8150975 linux-i586,windows-i586 - ############################################################################

2 1

RFR: 8157716: jdk.internal.loader.ClassLoaders.addURLToUCP() should return converted real path URL
by Jiangli Zhou 25 May '16

25 May '16

Hi, Please review the following webrev that changes the jdk.internal.loader.ClassLoaders.addURLToUCP() to java.internal.loader.ClassLoaders.toFileURL(). The change is provided by Alan (thanks, Alan!). webrev: http://cr.openjdk.java.net/~jiangli/8157716/webrev.00/ but: https://bugs.openjdk.java.net/browse/JDK-8157716 Thanks, Jiangli

4 17

Review request JDK-8157877: Clean up StackWalker permission checks
by Mandy Chung 25 May '16

25 May '16

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157877/webrev.00/ Trivial cleanup to do the check after the options are cloned. Mandy

2 1

VarHandles on non-int-sized fields and atomic operations
by Martin Buchholz 25 May '16

25 May '16

I believe C++ allows anything to be atomic using their atomic<> template. Having the atomic annotation at the declaration site: - makes it obvious to the human and the compiler that the data must be accessed atomically. - allows the compiler to lay out the data so that native cpu instructions can access the data efficiently and atomically. So it is likely that atomic<short> will be stored in a 32-bit field, since the cpu is likely to have a 32-bit cas, but not 16-bit cas. With VarHandles, the declared fields are Ordinary Java Fields, so they are likely to be layed out as with normal fields. As a result, it looks like you can't do a cas with a VarHandle to a short field. If that's true, then the hardware is intruding into the API. What happens when a platform with only a 64-bit CAS comes along? Since atomic fields need different field layout from regular fields, it seems to make sense to require that fields which will be accessed via a VarHandle are clearly marked as being "atomic" in some way. With the Unsafe API, we sort-of got this by requiring that fields be volatile (although some users surely cheated here), and because there was no Unsafe.compareAndSwapShort (but there is with VarHandles!) My original motivation was to be able to replace an AtomicBoolean with a VarHandle to a boolean field.

5 21

RFR [9] 8157825: Remove JDK 9 specific methods from sun.misc.Unsafe
by Chris Hegarty 25 May '16

25 May '16

sun.misc.Unsafe, in the jdk.unsupported module, should not have any new public methods that were not already part of its API in JDK 8. This issue will remove three such methods, getUncompressedObject, getJavaMirror, and getKlassPointer, that were added by JDK-8022853, in JDK 9. diff --git a/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java b/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java --- a/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java +++ b/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java @@ -296,45 +296,6 @@ theInternalUnsafe.putDouble(o, offset, x); } - - // These read VM internal data. - - /** - * Fetches an uncompressed reference value from a given native variable - * ignoring the VM's compressed references mode. - * - * @param address a memory address locating the variable - * @return the value fetched from the indicated native variable - */ - @ForceInline - public Object getUncompressedObject(long address) { - return theInternalUnsafe.getUncompressedObject(address); - } - - /** - * Fetches the {@link java.lang.Class} Java mirror for the given native - * metaspace {@code Klass} pointer. - * - * @param metaspaceKlass a native metaspace {@code Klass} pointer - * @return the {@link java.lang.Class} Java mirror - */ - @ForceInline - public Class<?> getJavaMirror(long metaspaceKlass) { - return theInternalUnsafe.getJavaMirror(metaspaceKlass); - } - - /** - * Fetches a native metaspace {@code Klass} pointer for the given Java - * object. - * - * @param o Java heap object for which to fetch the class pointer - * @return a native metaspace {@code Klass} pointer - */ - @ForceInline - public long getKlassPointer(Object o) { - return theInternalUnsafe.getKlassPointer(o); - } - // These work on values in the C heap. /** -Chris.

5 4

JDK 9 RFR of JDK-8157813: Remove sun/rmi/transport/proxy/EagerHttpFallback.java from ProblemList.txt
by Amy Lu 25 May '16

25 May '16

sun/rmi/transport/proxy/EagerHttpFallback.java This test has been removed in JDK-8155978: JDK-8155978: Remove HTTP proxy implementation and tests from RMI https://bugs.openjdk.java.net/browse/JDK-8155978 This patch is to remove this test from ProblemList.txt as well. bug: https://bugs.openjdk.java.net/browse/JDK-8157813 webrev: http://cr.openjdk.java.net/~amlu/8157813/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2016-05-25 17:34:27.000000000 +0800 +++ new/test/ProblemList.txt 2016-05-25 17:34:26.000000000 +0800 @@ -195,8 +195,6 @@ java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java 7191877 generic-all -sun/rmi/transport/proxy/EagerHttpFallback.java 7195095 generic-all - java/rmi/activation/Activatable/extLoadedImpl/ext.sh 8062724 generic-all sun/rmi/rmic/newrmic/equivalence/run.sh 8145980 generic-all

2 1

8157677: Subclasses of Reader do not inherit the contents in the exception tag from the parent Reader class in the latest spec
by Pavel Rappo 25 May '16

25 May '16

Hi, Could you please review a trivial change for JDK-8157677? http://cr.openjdk.java.net/~prappo/8157677/webrev.00/ http://cr.openjdk.java.net/~prappo/8157677/specdiff.00/overview-summary.html Thanks, -Pavel -------------------------------------------------------------------------------- The problem is caused by a glitch in handling '@exception' tag by javadoc tool: https://bugs.openjdk.java.net/browse/JDK-8157682

3 5

JDK 9 RFR of JDK-8151904: test/java/lang/StackWalker/VerifyStackTrace.java needs to handle update releases
by Hamlin Li 24 May '16

24 May '16

The test currently hardcodes the version number "9". We should build a JDK with a different release number e.g. 9.1 and checks if this test handles it properly. Test run successfully on 9-ea+118, dummybundles(9-ea+255, 9.1-ea+255, 9.0.1-ea+255, 9.0.0.1-ea+255). bug: https://bugs.openjdk.java.net/browse/JDK-8151904 webrev: http://cr.openjdk.java.net/~mli/8151904/webrev.00/ Thank you -Hamlin

2 1

JDK 9 RFR of JDK-8157724: Improve javadoc tag usage in java.math
by joe darcy 24 May '16

24 May '16

Hello, The javadoc of the java.math package has various locations where the @jls, @apiNote, etc. javadoc tags could be used. Those tags should be used as appropriate. Please review the webrev below which makes those updates along with some typo fixes: http://cr.openjdk.java.net/~darcy/8157724.0/ Thanks, -Joe

3 7