February 2015 - core-libs-dev

ConcurrentModificationException in java.util.ServiceLoader (not a multi-thread issue)
by Martin Desruisseaux 24 Feb '15

24 Feb '15

Hello all java.util.ServiceLoader does not seem to support usage of a second Iterator in the middle of a previous iteration. The attached Java file provides two simple tests with a ServiceLoader iterating over two elements. The first test creates two iterators and invokes their hasNext() / next() methods in the following order: * Iterator 1 * Iterator 2 * Iterator 1 * Iterator 2 - unexpected end of iteration here. The second test creates two iterators and invoke the hasNext() methods on both iterators before to invoke their next() methods. This result is the following exception (tested on 1.8.0_31-b13): Exception in thread "main" java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711) at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:744) at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:742) at java.util.ServiceLoader$1.next(ServiceLoader.java:479) at test.ServiceLoaderTest.test2(ServiceLoaderTest.java:47) at test.ServiceLoaderTest.main(ServiceLoaderTest.java:12) (note: to run the test, the attached test.ServiceLoaderTest file needs to be in the META-INF/services/ directory). I found a Stackoverflow thread mentioning this issue 4 years ago [1], but apparently without solution. Should I look for a patch, or is the current behaviour considered okay (in which case I would suggest to warn the users in the Javadoc)? Martin [1] http://stackoverflow.com/questions/2593777/serviceloader-double-iterator-is…

4 7

RFR: 8073394: Clock.systemUTC() should return a constant
by Daniel Fuchs 24 Feb '15

24 Feb '15

Hi, Please find below a small patch for 8073394: Clock.systemUTC() should return a constant http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.00/ best regards, -- daniel

5 11

Review Request for 8073696: Remove redundant import from javax/rmi/CORBA/GetORBPropertiesFileAction.java
by Mandy Chung 24 Feb '15

24 Feb '15

diff --git a/src/java.corba/share/classes/javax/rmi/CORBA/GetORBPropertiesFileAction.java b/src/java.corba/share/classes/javax/rmi/CORBA/GetORBPropertiesFileAction.java --- a/src/java.corba/share/classes/javax/rmi/CORBA/GetORBPropertiesFileAction.java +++ b/src/java.corba/share/classes/javax/rmi/CORBA/GetORBPropertiesFileAction.java @@ -43,7 +43,6 @@ import java.security.AccessController; import java.security.PrivilegedAction; -import sun.security.action.GetPropertyAction; import java.util.Properties; class GetORBPropertiesFileAction implements PrivilegedAction { Mandy

3 3

[9] RFR of 8073187: Unexpected side effect in Pack200
by mikhail cherkasov 24 Feb '15

24 Feb '15

Hi all, Bug: https://bugs.openjdk.java.net/browse/JDK-8073187 The problem is that packer changes global state( default time zone ) without proper synchronization: http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/… however javadoc says that it's save to use it in concurrent way if each thread has it's own packer instance: http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/… The fix isn't perfect but it the only possible solution: 1. first packer saves default time zone 2. the last set it back. Webrev: http://cr.openjdk.java.net/~mcherkas/8073187/webrev/src/share/classes/com/s… Thanks, Mikhail.

2 2

RFR: 8068790: ZipEntry/JarEntry.setCreation/LastAccessTime(null) don't throw NPE as specified
by Claes Redestad 21 Feb '15

21 Feb '15

Hi all, please review this simple fix to do the right null checks in a few ZipEntry methods. bug: https://bugs.openjdk.java.net/browse/JDK-8068790 webrev: http://cr.openjdk.java.net/~redestad/jdk9/8068790/webrev.0/ /Claes

3 6

RFR: JDK-8051990 - Uninitialised memory in jdk/src/share/native/java/lang/fdlibm/src/k_standard.c
by Mark Sheppard 21 Feb '15

21 Feb '15

Hi please review the small change http://cr.openjdk.java.net/~msheppar/8051990/webrev/ to address the parfait issue in https://bugs.openjdk.java.net/browse/JDK-8051990 regards Mark

3 3

[8u60] RFR of 8071599: (so) Socket adapter sendUrgentData throws IllegalBlockingMode when channel configured non-blocking
by Brian Burkhalter 20 Feb '15

20 Feb '15

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8071599 Patch: http://cr.openjdk.java.net/~bpb/8071599-8u/webrev.00/ Summary: allow MSG_OOB (out-of-band byte) to be sent on the Socket associated with a SocketChannel when the Socket is in non-blocking mode. All JPRT tests pass as well as does a test which verifies that the intended objective of the change has been achieved. Yes, I am aware that the copyright years need to be updated. This request is being made directly to the JDK-8u60 project but is intended to be ported forward to the JDK 9 project in short order. Thanks, Brian

1 0

Lexicographic array comparators
by Paul Sandoz 20 Feb '15

20 Feb '15

Hi, One common use of Unsafe is boost the performance of comparing unsigned byte[] by viewing as long[] (for example as performed by Guava or Cassandra). To reduce the dependency on Unsafe we need a public and safe equivalent that works on all platforms while meeting the performance expectations. In the past we have discussed exposing something on ByteBuffer but i think the right thing to explore are comparators for all basic types on java.util.Arrays: https://bugs.openjdk.java.net/browse/JDK-8033148 This should be explored with the following issue in mind to expose an intrinsic that could be leveraged when implemented: https://bugs.openjdk.java.net/browse/JDK-8044082 Some preliminary work can be found here: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/… The "explosion" in methods is annoying. Out of the 8 primitives 4 can be signed or unsigned. Objects can be comparable or an explicit comparator can be used. There are implicit and explicit ranges. That makes a maximum of 28 methods, but could be reduced to a minimum of 10, for all basic types. Comparator instances, for implicit ranges, can easily be created from method refs or lambdas. Thoughts? Paul.

4 11

Logging FileHandler: static locks and hardcoded maximum number
by Behrooz Nobakht 20 Feb '15

20 Feb '15

Hi, The following describes my situation: 1. I have a long running JVM process (p1). 2. The long running process instantiate another JVM process (p2). 3. On every instantiation of p2, p1 prepares an instance of FileHandler for p2 (used through a redirect thread of logging) as: new FileHandler("/path/to/log/app.stdouterr.%u.%g.log" 4. p2 is short-lived and on its JVM exit, it closes FileHandler 5. p1 can start p2 an arbitrary number of times Our observation started with the following exception: Caused by: java.io.IOException: Couldn't get lock for /path/to/log/app.stdouterr.%u.%g.log at java.util.logging.FileHandler.openFiles(FileHandler.java:422) at java.util.logging.FileHandler.<init>(FileHandler.java:318) (...) Then, I tried to understand why, and I used the following on the running server: $ lsof -uappuser | grep -E "\/path\/to\/log" It's interesting that I see 100 files as ".lck" in generation 0 as the following shows (the results are trimmed): === java 14515 appuser 182wW REG 252,0 0 109052248 /path/to/log/app.stdouterr.0.0.log.lck (deleted) java 14515 appuser 183wW REG 252,0 0 92274968 /path/to/log/app.stdouterr.1.0.log.lck (deleted) java 14515 appuser 184wW REG 252,0 0 125829396 /path/to/log/app.stdouterr.2.0.log.lck (deleted) . . . java 14515 appuser 206wW REG 252,0 0 109052253 /path/to/log/app.stdouterr.98.0.log.lck (deleted) java 14515 appuser 207wW REG 252,0 0 125829401 /path/to/log/app.stdouterr.99.0.log.lck (deleted) java 14515 appuser 168wW REG 252,0 0 8388893 /path/to/log/app.stdouterr.100.0.log.lck java 14515 appuser 176w REG 252,0 367 8388894 /path/to/log/app.stdouterr.100.0.log === Please note that except the last two, all the *.lck files are marked as (deleted), which means they are not available in the file system (confirmed) but a process has an open handle on the path. Simply, based on (3) and (4), when p1 would reach the 100th time it wants to instantiate p2, we start to observe the exception. As far as I can see the source for FileHandler: - a static field is used to hold the lock files - in our setup, the JVM in p1 initiates the above static field as part of the first time preparing p2 - the (deleted) in the above, means that FileHandler#close has been called with success. Questions/Suggestions: (a) The above (deleted) handles would not be released until p1 JVM goes down, correct? (b) If (a) is correct, is there way to ask JVM to do so on FileHandler? If yes, where should I look into? (c) If (b) is no, is there a chance FileHandler could introduce a new API method to be able to perform such clean-up without having to exit p1 JVM? Thanks, Behrooz

2 9

Review request: 8073374: Re-examine jdk.xml.ws dependency on java.xml.ws SOAPNamespaceConstants
by Mandy Chung 19 Feb '15

19 Feb '15

This eliminates the dependency from jdk.xml.ws to com.sun.xml.internal.ws.encoding.soap.streaming.SOAPNamespaceConstants from java.xml.ws. I chatted with Miran offline who confirms that it's okay to define the constant value directly. diff --git a/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java b/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java --- a/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java +++ b/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java @@ -25,8 +25,6 @@ package com.sun.tools.internal.ws.wsdl.document.soap; -import com.sun.xml.internal.ws.encoding.soap.streaming.SOAPNamespaceConstants; - import javax.xml.namespace.QName; /** @@ -37,7 +35,9 @@ public interface SOAPConstants { // namespace URIs - public static final String URI_ENVELOPE = SOAPNamespaceConstants.ENVELOPE; + public static final String URI_ENVELOPE = + "http://schemas.xmlsoap.org/soap/envelope/"; + public static final String NS_WSDL_SOAP = "http://schemas.xmlsoap.org/wsdl/soap/"; public static final String NS_SOAP_ENCODING = "http://schemas.xmlsoap.org/soap/encoding/"; Mandy

2 1