April 2016 - core-libs-dev

RFR: regex changes
by Xueming Shen 11 May '16

11 May '16

6 13

RFR 8155088, Fix module dependencies in java/sql/* and javax/* tests
by Felix Yang 09 May '16

09 May '16

Hi there, please review the changes to explicitly declare module dependencies for "java/sql/*" and "javax/*" tests; Bug: https://bugs.openjdk.java.net/browse/JDK-8155088 Webrev: http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.00/ Thanks, Felix

2 6

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: 8152084: Introduction of ssliop protocol to corbaloc
by Tomasz Adamski 06 May '16

06 May '16

Hello All, I would like to propose an extension to corbaloc resolution - the ssliop protocol. IORs created from corbaloc url with ssliop protocol will contain SSL tagged component with indication that secured invocation is required. As a result, connection to the resolved object will have to be secured. I'm attaching a webrev of proposed enhancement: http://cr.openjdk.java.net/~adinn/tomaszadamski/8152084/ Regards, Tomek -- Tomasz Adamski Software Engineer JBoss by Red Hat

3 8

JDK 9 proposal: allocating ByteBuffers on heterogeneous memory
by Dohrmann, Steve 06 May '16

06 May '16

Re: JDK-8153111<https://bugs.openjdk.java.net/browse/JDK-8153111> Hi, Below are responses to some of the points brought up in the discussion as well as is a little expansion of the reasoning that went into the proposed API. One motivation we saw for doing anything beyond a concrete ByteBuffer class was application code (e.g. Cassandra) that allocates many off-heap ByteBuffers using ByteBuffer#allocateDirect. We reasoned that if the allocation of ByteBuffers could be done using a common memory interface then only the code that provisioned instances of the the memory spaces would have to change in order to switch or mix memory types. We did think of overloading the ByteBuffer#allocateDirect method with memory space info and avoid an allocation interface. We ended up with a separate user called interface scheme because we imagined that extensions of the memory interface would enable new memory functionality that required new methods (e.g. memory transactions for persistence). Without a separate callable interface, the static method space in ByteBuffer might have to change again. For any API In general we saw the need for two things 1) something to represent a memory space from which objects are allocated (a Memory instance) and 2) a broadly usable familiar "anchor" type as the common data object (java.nio.ByteBuffer). The two points for extension with the current proposal are: 1) Constructors on Memory implementation classes -- allow implementors the ability to offer features on the memory space itself (e.g. partitioning, size limits) and 2) future extensions on the Memory interface -- for example PersistentMemory. Regarding a more elaborate scheme for memory space creation -- we did consider a factory scheme for memory object allocation but could not get comfortable with either a) standardized method signatures suitable for various kinds of memory or b) the complexity that something like a general-purpose "spec" format would add, even if we could come up with it. Direct construction does expose more to the user but it seems sufficient and might be the best given what we can say about the future of heterogeneous memory at this point. Regarding the suggested addition of keyed access to ByteBuffers, we are assuming this is only proposed to enable sharing? We thought it might take a while to properly explore the details (i.e. semantics / thread safety / predicable performance) of sharing such that it would work well and maybe even extend well to things like process-shared and cluster-shared ByteBuffers. We elected to propose nothing for JDK 9 beyond what developers can already do with schemes based on e.g. ByteBuffer#duplicate. We were thinking shared buffers could appear later, possibly as an extension of the Memory interface. The keyed access scheme is simple and appealing, however. One question: how is the request method's size parameter to be interpreted? The suggestion of parameterizing the Memory interface bounded by ByteBuffers seems useful as it gives a clean way to support extended ByteBuffers. Not sure if the change of the allocation method name from #allocateByteBuffer to #allocate was incidental or not? Alternates to the "Memory" interface name might be preferred, BufferSupplier is certainly reasonable. We imagined instances that name different memory spaces (e.g. OffHeapRAM) for allocation rather that the role played -- thinking the role is explicit in the allocation method name (allocateByteBuffer). Regarding changing the allocation size parameter to a long, this would be very nice to have. We avoided it in order to match the existing ByteBuffer API. If 64-bit ByteBuffers are planned, sticking with int sizes might have been the wrong call. We are still coming up to speed on VarHandles (JEP 193), atomics for ByteBuffers (JDK-8008240), and ByteBuffer consistency (JDK-6476827). We hope there is continued interest in this proposal and happy to provide a modified patch. Best regards, Steve Dohrmann

4 8

Review request: 8154190 & 8155513: Deprivilege java.compiler and jdk.charsets
by Mandy Chung 05 May '16

05 May '16

JDK-8154190: Deprivilege java.compiler module Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8154190/webrev.00/ JDK-8155513: Deprivilege jdk.charsets module Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8155513/webrev.00/ Very simple change. These patches move java.compiler and jdk.charsets module to be defined by the platform class loader and grant with AllPermissions initially. We could grant finer-grained permissions in the future. Mandy

4 5

Project Jigsaw, Apache Tomcat and RMI related memory leaks
by Mark Thomas 05 May '16

05 May '16

Hi, The Apache Tomcat community was asked by Rory O'Donnell for feedback on JDK 9 + Project Jigsaw. Having provided that feedback we were directed here so I have reproduced that feedback below. I've started testing Tomcat trunk with JDK 9 + Project Jigsaw and it looks like we are going to hit a bunch of problems related to Tomcat's memory leak protection. The short version is there are lots of JDK calls that can result in a reference being retained to the current class loader. If that class loader is the web application class loader it often ends up being pinned in memory. This triggers a memory leak when the web application is reloaded since the web application class loader is not eligible for GC. Tomcat generally uses reflection to find these problems. It then does one of two things: - If the JRE provides an API the application developer should have used to clean up the reference, Tomcat does this for them and then logs a very loud error message telling the developer they need to fix their app. - If there is nothing the developer could have done to avoid the problem, Tomcat cleans it up. Usually this is via reflection again. Reporting this second class of issues as JRE bugs has been on my TODO list for a long time. It looks like Java 9 is going to bump this to the top of the list. The first problem we have hit is related to RMI. The memory leak is triggered by a call to: java.rmi.registry.Registry.bind() or java.rmi.registry.Registry.rebind() The problem occurs when an object of a class loaded by the web application class loader is bound to the RMI registry. There is no standard API (that I have found) that completely removes all references. In particular java.rmi.registry.Registry.unbind() doesn't help. The code Tomcat uses to clean this up is at [1]. Essentially, we need to remove any reference to the web application's class loader from the RMI caches. With JDK 9 this fails with: java.lang.reflect.InaccessibleObjectException: Unable to make member of class sun.rmi.transport.Target accessible: module java.rmi does not export sun.rmi.transport to unnamed module ... I took a look at the JDK 9 API but I could not find a way to bypass this. Possible solutions include: 1. Some way that allows us to continue to use reflection as per the current code. 2. A new method somewhere in the RMI API that clears all references associated with a given class loader from the cache. 3. Modify Registry.unbind() so it removes all references. 4. Something else... I do have a concern with 3 on its own that, while that would allow applications to clear their own references, it would mean Tomcat would have no way to check for the problem. Ideally, I'd like to see the API extended so a) applications are able to clean up after themselves and b) Tomcat can check for leaked references and generate error messages for the ones found. Any and all suggestions gratefully received. Thanks, Mark [1] http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/W…

3 7

RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value
by nadeesh tv 04 May '16

04 May '16

Hi all, Please review a fix for Bug ID - https://bugs.openjdk.java.net/browse/JDK-8079628 Issue - Pattern 'D' is not implemented as intended by CLDR Solution - Changed the definition of 'D' to D..D 1..3 appendValue(ChronoField.DAY_OF_YEAR, n, 19, SignStyle.NORMAL) Webrev - http://cr.openjdk.java.net/~ntv/8079628/webrev.00/ <http://cr.openjdk.java.net/%7Entv/8079628/webrev.00/> -- Thanks and Regards, Nadeesh TV

3 11

RFR:JDK-8148949:DateTimeFormatter pattern letters 'A','n','N'
by nadeesh tv 04 May '16

04 May '16

HI all, Please review a fix for Bug ID - https://bugs.openjdk.java.net/browse/JDK-8148949 Issue - Pattern letters 'A' does not match the intent of LDML/CLDR Solution - Changed the definition of pattern letters 'A','n','N' Webrev - http://cr.openjdk.java.net/~ntv/8148949/webrev.00/ -- Thanks and Regards, Nadeesh TV

3 8

JDK 9 RFR of JDK-8154911: Move GCDuringIteration.java back to tier1
by Amy Lu 04 May '16

04 May '16

java/util/WeakHashMap/GCDuringIteration.java This test was failing intermittently (JDK-6842353) and demoted to tier2. Mentioned issues have been resolved and no open bug (no failure reported) till now. This patch is to move the test back to tier1. bug: https://bugs.openjdk.java.net/browse/JDK-8154911 webrev: http://cr.openjdk.java.net/~amlu/8154911/webrev.00/ Thanks, Amy --- old/test/TEST.groups 2016-04-25 10:54:59.000000000 +0800 +++ new/test/TEST.groups 2016-04-25 10:54:58.000000000 +0800 @@ -29,7 +29,6 @@ :jdk_lang \ -java/lang/ProcessHandle/TreeTest.java \ :jdk_util \ - -java/util/WeakHashMap/GCDuringIteration.java \ -java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ -java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ sun/nio/cs/ISO8859x.java \ @@ -39,7 +38,6 @@ tier2 = \ java/lang/ProcessHandle/TreeTest.java \ - java/util/WeakHashMap/GCDuringIteration.java \ java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java \ java/util/concurrent/forkjoin/FJExceptionTableLeak.java \ :jdk_io \

3 3