February 2014 - core-libs-dev

8033372: Check jdk/src/share/native/java/lang for JNI pending exception issues
by Alan Bateman 04 Feb '14

04 Feb '14

There are a number of places in the native methods where there are sequences of JNI calls and where we don't check for errors or pending exceptions. This patch fixes up a number of these issues in the java.lang native code, and one remaining one in the java.io native code that may have been missed by previous clean-up in this area. The changes are trivial and the webrev is here: http://cr.openjdk.java.net/~alanb/8033372/webrev/ Thanks, Alan.

2 1

RFR [9] 8031050: [macosx] Crash while awt starting
by Chris Hegarty 04 Feb '14

04 Feb '14

Hi, An old issue has resurfaced because of a change in AWT. AWT, now, on Mac OS X, attaches a system graphics thread to the running VM, using JNI_AttachCurrentThread. This change can result in a NPE, if a security manager is installed, and the security manager tries to print the name of the current thread. In this case, attaching a thread to the VM, the j.l.Thread instance/oop is created by the VM in allocate_threadObj(), and then its constructor is run. At this point almost everything has been created for the thread, jni env, etc, so it can query currentThread() to retrieve itself. (Note: this is unusual. Typically the thread running the j.l.Thread constructor is not itself.) Since the j.l.Thread oop was allocated directly by the VM, its fields, other than those directly set by allocate_threadObj(), are not initialized. The call out from Thread.init to the security manager is problematic as the partially constructed thread can be retrieved through Thread.currentThread. Some of our internal tests run into a problem when the security manager tries to print the name of the thread, i.e. NPE. Clearly there are other concerns of accessing a partially constructed thread, not just the thread name, but it seems reasonable to simply move the setting of the name to the beginning of the init() method. I propose the following change for JDK 9, with the intention of backport exactly to JDK 8. Long term this should be revisited in JDK 9. diff --git a/src/share/classes/java/lang/Thread.java b/src/share/classes/java/lang/Thread.java --- a/src/share/classes/java/lang/Thread.java +++ b/src/share/classes/java/lang/Thread.java @@ -366,6 +366,8 @@ throw new NullPointerException("name cannot be null"); } + this.name = name.toCharArray(); + Thread parent = currentThread(); SecurityManager security = System.getSecurityManager(); if (g == null) { @@ -402,7 +404,6 @@ this.group = g; this.daemon = parent.isDaemon(); this.priority = parent.getPriority(); - this.name = name.toCharArray(); if (security == null || isCCLOverridden(parent.getClass())) this.contextClassLoader = parent.getContextClassLoader(); else -Chris.

4 3

RFR java.time cleanup of javadoc and messages
by roger riggs 04 Feb '14

04 Feb '14

Please review this group of java.time updates: 8032749 <https://bugs.openjdk.java.net/browse/JDK-8032749>: Typo in java.time.Clock 8032888 <https://bugs.openjdk.java.net/browse/JDK-8032888>: Error message typo in TemporalAccessor 8032558 <https://bugs.openjdk.java.net/browse/JDK-8032558>: Instant spec includes incorrect assertion wrt valid range 8032494 <https://bugs.openjdk.java.net/browse/JDK-8032494>: DateTimeFormatter spec includes irrelevant detail on parsing pattern Webrev: http://cr.openjdk.java.net/~rriggs/webrev-typos-8032749/ Thanks, Roger

5 4

JAXP JEP: Update Xerces implementation in the JDK
by huizhe wang 03 Feb '14

03 Feb '14

Hi, We'd like to propose a JEP to update the Xerces implementation in the JDK and bring it to up to date to the current Xerces release. Please review the draft. Thanks, Joe

5 7

RFR: (8031737) CHECK_NULL and CHECK_EXCEPTION macros cleanup (re-review)
by roger riggs 03 Feb '14

03 Feb '14

Please re-review. I missed a warning that the CHECK_NULL macros was being redefined. Retaining the previous changes to java/util/jar/pack that removed the redefinition addresses the issue. The webrev now only has a few small changes to cleanup the name and use of CHECK macros. The CHECK_NULL_* macros are more generally useful without the JNU_ prefix. The JNU_CHECK_EXCEPTION* macros apply only when there is an jni environment. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-check-cleanup-8031737/ Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8031737

5 4

JDK 9 RFR of JDK-8033416: Remove sun.misc.FpUtils
by Joe Darcy 03 Feb '14

03 Feb '14

Hello, Back in JDK 5, the sun.misc.FpUtils class was added to provide low-level floating-point manipulations methods needed to write tests of the math library. Over time, those low-level functions have generally been added to the standard Java library and most of the methods in FpUtils have thus been deprecated. Therefore, I think the start of JDK 9 is a good time to actually remove FpUtils from the platform; please review my change which does this: http://cr.openjdk.java.net/~darcy/8033416.0/ The implementation of the ilogb and isUnordered methods was moved into the "Tests" helper class in the math library test directory. (At the recommendation of Alan in the bug report, I verified that the fx jar files do not reference the FpUtils class.) Thanks, -Joe

4 4