February 2016 - core-libs-dev

RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java
by Brent Christian 18 May '16

18 May '16

Hi, Please review this fix, courtesy of Peter Levart (thanks!), that I would like to get in. https://bugs.openjdk.java.net/browse/JDK-8029891 http://cr.openjdk.java.net/~bchristi/8029891/webrev.0/ There is some discussion of it in the bug report, starting at 2014-12-31. The problem, as stated by Mandy: "System Properties is a hashtable that synchronizes on itself for any access. Currently System.getProperties returns the Properties instance accessed by the system in which any application code might synchronize on it (that's what the test is doing). The problem reported JDK-6977738 is about Properties.store method that was fixed not to synchronize on this instance. System property is a common way for changing the default setting and so it's impractical to expect the class loading code path not to call System.getProperty." This fix changes java.util.Properties to store its values in an internal ConcurrentHashMap, ignoring its Hashtable heritage. In this way, Properties can be "de-sychronized": all methods inherited from Hashtable are overridden, to remove synchronization, and delegate to the internal CHM. The serialized form is unchanged. An alternative approach considered would be for System.getProperties() to return a duplicate snapshot of the current Properties. This presents a compatibility risk to existing code that keeps a reference to the return value of System.getProperties() and expects to either read new properties added afterwards, or set properties on the cached copy. -Brent

7 41

We don't need jdk.internal.ref.Cleaner any more
by Peter Levart 16 May '16

16 May '16

Hi, sun.misc.Cleaner has been moved to internal package jdk.internal.ref recently [1] to clean-up sun.misc namespace. But now that: - we have comparable public API (java.lang.ref.Cleaner & Cleanable) [2] - we have an internal shared java.lang.ref.Cleaner instance (jdk.internal.ref.CleanerFactory.cleaner()) - sun.misc.Cleaner is not a special kind of Reference any more in the JVM [3] ...I think there's no reason to keep this special internal API any more. It can be replaced with public API. I propose to remove jdk.internal.ref.Cleaner class and replace its usages with java.lang.ref.Cleaner and friends [4]. What do you say? Regards, Peter [1] https://bugs.openjdk.java.net/browse/JDK-8148117 [2] https://bugs.openjdk.java.net/browse/JDK-8138696 [3] https://bugs.openjdk.java.net/browse/JDK-8143847 [4] http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.0…

11 72

RFR 8147984: WindowsTerminal should support function keys
by Jan Lahoda 08 May '16

08 May '16

Hello, I'd like to enhance the WindowsTerminal in jdk.internal.le with function keys handling. The intent is so that jshell can bind actions for shortcuts including function keys. The patch for adding the function keys support is here: http://cr.openjdk.java.net/~jlahoda/8147984/webrev.00/ An example of a feature that uses/may use this support is here: http://mail.openjdk.java.net/pipermail/kulla-dev/2016-January/001226.html Any comments are welcome! Thanks, Jan

3 7

RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present
by Liam Miller-Cushon 27 Apr '16

27 Apr '16

If an annotation value is an array of class literals or enum constants, calling Class.getAnnotation() fails with ArrayStoreException if the element type is not found. This patch implements the proposed fix from the bug thread, which allows getAnnotation() to succeed and a TypeNotPresentException to be thrown from Annotation.value(). bug: https://bugs.openjdk.java.net/browse/JDK-7183985 The patch is attached.

2 6

RFR: 8150469: unpack200 fails to compare crc correctly.
by Kumar Srinivasan 06 Apr '16

06 Apr '16

Hello John, Alex, Please review fix for https://bugs.openjdk.java.net/browse/JDK-8150469 The previous fix keeps the storage in the unpacker object which is reset, for a multi-segmented pack archive, thus the computed crc32 is lost. Now the storage is moved into the gzip container, which persists, across multiple segments, I also added the length check as specified by RFC 1952, as implemented by JDK. http://hg.openjdk.java.net/jdk9/dev/jdk/file/e4af8119eba4/src/java.base/sha… The review is at: http://cr.openjdk.java.net/~ksrini/8150469/webrev.00/ Thanks Kumar

3 2

RFR: 8079136: Accessing a nested sublist leads to StackOverflowError
by Ivan Gerasimov 31 Mar '16

31 Mar '16

Hello! When creating a sublist with List.subList(), it keeps a reference to its parent. Then, when accessing (get(), set(), add(), remove(), etc.) the sublist, it recursively calls the corresponding methods of its parent. This recursion, when deep enough, can cause StackOverflowError. The only reason to do things recursively here, is the need to update modCount and size of all the parents. So, the proposal is to update these fields in a loop. A few cleanups were done along the way. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8079136 WEBREV: http://cr.openjdk.java.net/~igerasim/8079136/0/webrev/ Sincerely yours, Ivan

9 45

RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type
by Joel Borggrén-Franck 30 Mar '16

30 Mar '16

Hi, When reflecting over annotated types, there is currently no way to get the potentially annotated owner of a type. For example, given you have an instance of '@A Outer . @B Inner' you can't traverse it to get '@A Outer' . This API addition fixes this. Because both parameterized and non-generic types can have an owner, this addition goes into the base AnnotatedType interface together with a default implementation. CCC has been filed. The parsing code and annotated type factory had to be fixed to deal with navigating inside nested types. Bug: https://bugs.openjdk.java.net/browse/JDK-8057804 Webrev: http://cr.openjdk.java.net/~rbackman/jbf/8057804/webrev.00/ (OCA is signed and processed). Cheers /Joel

7 14

[DING] Re: [PING] Potential infinite waiting at JMXConnection#createConnection
by KUBOTA Yuji 28 Mar '16

28 Mar '16

Hi all, Could someone please review and sponsor this fix ? I write the details of this issue again. Please review it. =Problem= Potential infinite waiting at TCPChannel#createConnection. This method flushes the DataOutputStream without the socket timeout settings when choose stream protocol [1]. If connection lost or the destination server do not return response during the flush, this method wait forever because the timeout settings is set the default value of SO_TIMEOUT, i.e., infinite. [1]: http://hg.openjdk.java.net/jdk9/dev/jdk/file/7adef1c3afd5/src/java.rmi/shar… I think this issue is rarely, however serious. =Reproduce= I write a test program to reproduce. You can reproduce by the below. * hg clone http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/ * cd fixLoopAtJMXConnectorFactory; mvn package * setting "stop_time" at debugcontrol.properties if you need. * java -cp .:target/debugcontrol-1.0-SNAPSHOT.jar debugcontrol.DebugController This program keep to wait at TCPChannel#createConnection due to this issue. After "debugcontroltest.stop_time" ms, this program release the waiting by sending quit to jdb which is stopping the destination server. Finally, return 2. =Solution= Set timeout by using property-configured value: sun.rmi.transport.tcp.responseTimeout. My patch is below. http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/fi… If you run the test program with modified JDK9 by my patch, the test program will get java.net.SocketTimeoutException after the connection timeout happen, then return 0. Thanks, Yuji. 2016-01-13 23:31 GMT+09:00 KUBOTA Yuji <kubota.yuji(a)gmail.com>: > Hi all, > > Can somebody please review and sponsor this fix ? > > Thanks, > Yuji > > 2016-01-05 17:56 GMT+09:00 KUBOTA Yuji <kubota.yuji(a)gmail.com>: >> Hi Jaroslav and core-libs-dev, >> >> Thank Jaroslav for your kindness! >> >> For core-libs-dev members, links the information about this issue. >> >> * details of problem >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002152.html >> >> * patch >> http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/fi… >> >> * testcase for reproduce >> http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/fi… >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-December/018… >> >> Could you please review these reports? >> Hope this patch helps to community. >> >> Thanks, >> Yuji >> >> 2016-01-04 23:51 GMT+09:00 Jaroslav Bachorik <jaroslav.bachorik(a)oracle.com>: >>> Hi Yuji, >>> >>> On 4.1.2016 15:14, KUBOTA Yuji wrote: >>>> >>>> Hi all, >>>> >>>> Could you please review this patch? >>> >>> >>> Sorry for the long delay. Shanliang has not been present for some time and >>> probably this slipped the attention of the others. >>> >>> However, core-libs mailing list might be more appropriate place to review >>> this change since you are dealing with s.r.t.t.TCPChannel >>> (http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/fi…) >>> >>> Regards, >>> >>> -JB-

2 5

RFR: JDK-8031767 Support system or alternative implementations of zlib
by Xueming Shen 25 Mar '16

25 Mar '16

Hi Please help codereview the change to build the jdk9 runtime to use the system zlib on Solaris and Linux platforms by default. Issue: https://bugs.openjdk.java.net/browse/JDK-8031767 Webrev: http://cr.openjdk.java.net/~sherman/8031767/webrev/ Background info: Compression is heavily used in Java based big data/middle-ware applications. There are many products in market today that help compression performance either through software or hardware acceleration and most likely these products support the zlib interface as API, for example Intel's IPP library has a faster version of compression libraries. To configure the Java runtime to use the system zlib would make these acceleration capabilities available to java users through java.util.zip package directly. The jdk already has a build configuration option to build the jdk to use the system zlib via "--with-zlib=system" and the OSX is by default built to use the system zlib. This proposal is to propose to build the jdk to use the system zlib library (the zlib bundled by the underlying Solaris/ Linuxplatforms), instead of the binary built from source code jdk repository (current 1.2.8 from the open source zlib.org) Thanks, Sherman btw, attached is the similar change in the closed repo: autoconf/generated-configure.sh ------------------------------------------------------------- # Do not change or remove the following line, it is needed for consistency checks: -DATE_WHEN_GENERATED=1454436146 +DATE_WHEN_GENERATED=1454626552 ############################################################################### # # Initialization / Boot-strapping # ------------------------------------------------------------------------ @@ -58839,14 +58839,14 @@ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for which zlib to use" >&5 $as_echo_n "checking for which zlib to use... " >&6; } - DEFAULT_ZLIB=bundled - if test "x$OPENJDK_TARGET_OS" = xmacosx; then - # On macosx default is system...on others default is bundled DEFAULT_ZLIB=system + if test "x$OPENJDK_TARGET_OS" = xwindows; then + # On windows default is bundled...on others default is system + DEFAULT_ZLIB=bundled fi if test "x${ZLIB_FOUND}" != "xyes"; then # If we don't find any system...set default to bundled DEFAULT_ZLIB=bundled

7 21

[8u-dev] Request for approval: 8133924: NPE may be thrown when xsltc select a non-existing node after JDK-8062518
by Aleksej Efimov 17 Mar '16

17 Mar '16

Hi, Please, help to review and approve JDK-8133924 backport to JDK8. The source fix is identical to JDK9 changes, but there was no test added for this issue in JDK9. The existing jdk/test/javax/xml/jaxp/transform/8062518/XSLTFunctionsTest.java test was modified to test the reported problem in JDK8 and it is a subject of review: http://cr.openjdk.java.net/~aefimov/8133924/8/00 No regression tests failures were observed for the proposed fix in JDK8 + the fix is in JDK9 for 3 months already. With Best Regards, Aleksej JBS: https://bugs.openjdk.java.net/browse/JDK-8133924 JDK9 changeset: http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/7c045de70a66 JDK9 Review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034969.html

4 6