August 2015 - core-libs-dev

RFR [9] 8133188: docs: replace <tt> tags (obsolete in html5) for java.util
by Alexander Stepanov 16 Sep '15

16 Sep '15

Hello, Could you please review the following fix: http://cr.openjdk.java.net/~avstepan/8133188/webrev.01 for https://bugs.openjdk.java.net/browse/JDK-8133188 Just a next portion of "<tt>" tags removed. specdiff report: http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary… - some constructs like "<tt>(o==null ? e==null : o.equals(e))</tt>" were replaced with "{@code Objects.equals(o, e)}" (e.g., http://cr.openjdk.java.net/~avstepan/8133188/webrev.01/src/java.base/share/…) - please see JDK-8133188 comments. Thanks, Alexander

2 5

[9] Review request JDK-8131667: JAX-WS Plugability Layer: using java.util.ServiceLoader
by Miroslav Kos 16 Sep '15

16 Sep '15

Hi everybody, I am sending changes for review. CCC: http://ccc.us.oracle.com/8131667 JBS: https://bugs.openjdk.java.net/browse/JDK-8131667 webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.01/ It's about migrating to standard java.util.ServiceLoader. This part of service discovery was implemented previously "own" way. There are some changes in javadoc and implementation has been refactored in order to use same code as is in JAX-B and SAAJ. Testing - I run JAX-WS unit tests (JAX-WS standalone repo), JCK9 + new tests specificaly developed for testing service discovery in JAX-WS. Thanks Miran

2 7

RFR JDK-8133079 LocalDate/LocalTime ofInstant()
by Stephen Colebourne 10 Sep '15

10 Sep '15

External question sites indicate that users have difficulty converting between java.util.Date and LocalDate, and also between Instant and LocalDate/LocalTime. This user difficulty can be resolved with some additional methods. Currently, the following methods exist: ZonedDateTime.ofInstant(Instant, ZoneId); OffsetDateTime.ofInstant(Instant, ZoneId); LocalDateTime.ofInstant(Instant, ZoneId); OffsetTime.ofInstant(Instant, ZoneId); This enhancement proposes to add the same method to LocalDate and LocalTime. It can reasonably be argued this was a simple oversight in the original development. Diff attached to the JIRA: https://bugs.openjdk.java.net/browse/JDK-8133079 Would also appreciate a reviewer to ensure that the code and tests pass OK (as opposed to my best efforts on a very dubious Windows/Eclipse/JDK8 setup) Stephen

3 4

Re: RFR 8072466: Deadlock when starting MulticastSocket and DatagramSocket
by Ivan Gerasimov 07 Sep '15

07 Sep '15

Can someone help review this fix please? Comments/suggestions are welcome! Sincerely yours, Ivan On 06.02.2015 20:48, Ivan Gerasimov wrote: > Hello! > > There has been a deadlock in jdk-net code noticed on Windows. > > In the bug description there's a stack snippet showing that one of the > deadlocked threads stuck in the native initialization code of > DualStackPlainDatagramSocketImpl and the other -- in initializing of > TwoStacksPlainDatagramSocketImpl. > > I suspect that the reason might be due to unordered initialization: > AbstractPlainDatagramSocketImpl, the parent of both classes above, > explicitly loads TwoStacksPlainDatagramSocketImpl from the native init(). > Thus, when both classes are being initialized concurrently, it may end > with a clash. > > > Another issue noticed by Mark Sheppard is that the Windows version of > DefaultDatagramSocketImplFactory.createDatagramSocketImpl() isn't > synchronized, but reads/modifies shared data. > Thus, I removed modification and declared all the accessed fields final. > > Would you please help review the proposed fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072466 > WEBREV: http://cr.openjdk.java.net/~igerasim/8072466/0/webrev/ > > The build went fine on all the platforms, all the tests from > (net|nio|io) passed Okay. > > Sincerely yours, > Ivan > > >

2 3

Cache which java classes are in a jar when opening jar the first time during classloading
by Adrian 01 Sep '15

01 Sep '15

Hello, I have been looking through the JVM source related to class loading. URLClassLoader#findClass calls URLClassPath#getResource URLClassPath creates a "loader" for every entry on the classpath (e.g. one JarLoader per jar file) In getResource, it loops through all its loaders in order, instantiating them lazily. For example, it will only create a JarLoader and open a jar file somewhere "farther along" the classpath if it did not find the resource in all the prior jars URLClassLoader#findClass and URLClassPath#getResource are doing linear searches on all the entries on the classpath every time they need to load a resource For a jar file, if there is an index in META-INF, at least the corresponding loader can figure out if the jar contains a class right away. If not, it searches an internal array/data structure created from the zipfile central directory (see jdk/src/share/native/java/util/zip/zip_util.c ZIP_GetEntry - if you follow the call hiearchy from URLClassPath$JarLoader#getResource, you end up at this function) If the jars on the classpath are optimal (majority of the classes are in the first few jars), there is not much overhead However, when classes are located in multiple jars along the classpath, the JVM spends nontrivial time searching through all of them One possible "solution" would be create a map of all resources -> which jar/jar loader they belong in whenever a jar file is opened. This can be done by iterating over JarFile#entries(), which just reads the central directory from the jar/zip file (which is done anyways to create some additional data structures when opening a jar/zip file) I implemented this to try it out and for a java program with ~1800 classes, it improved the find class time (taken from sun.misc.PerfCounter.getFindClassTime()) from ~1.4s to ~1s I tried to think of reasons why this was not done already; looking through the code, I believe the semantics of the loaders remain the same. There is technically a memory overhead of saving this map of resources -> jar files/loaders, but improves the algorithm complexity from O(number of jars on classpath) to O(1) Would appreciate any feedback/insight as to whether this would be a good change or why it is the way it currently is. Thank you! Best regards, Adrian

4 5

LittleEndian in DataInputStream
by Sergey Bylokhov 31 Aug '15

31 Aug '15

Hello, Does anybody know, do we plan to add LittleEndian support to the DataInputStream or probably to some other InputStream? -- Best regards, Sergey.

2 1

WebSocket client API
by Pavel Rappo 31 Aug '15

31 Aug '15

Hi, If anybody is interested in discussing WebSocket client API proposed for JDK 9, you could participate on net-dev mailing list here: http://mail.openjdk.java.net/pipermail/net-dev/2015-August/009077.html I'd be happy to gather as much feedback on it as possible. Thanks. -Pavel

1 0

Re: JAVADOC clarification needed in Class.getMethod
by Kyung Koo Yoon 29 Aug '15

29 Aug '15

Hi, Jochen. -- -------------------- Software Innovation Driver yoonforh at gmail dot com Analyze, Reason, Reshape the Question PGP http://www.javadom.com/personal/yoonforhatgmaildotcom.asc <http://www.javadom.com/personal/yoonforhatgmaildotcom.asc> > 2015. 8. 29., 오후 10:01, Jochen Theodorou <blackdrag(a)gmx.org> 작성: > > Am 29.08.2015 10:56, schrieb Kyung Koo Yoon: >> Hi, all. >> >> The javadoc comment of java.lang.Class.getMethod API has following clause. >> >> @CallerSensitive >> public Method getMethod(String name, Class<?>... parameterTypes) >> throws NoSuchMethodException, SecurityException >> >> >> "The {@code parameterTypes} parameter is an array of {@code Class} >> objects that identify the method's formal parameter types, in declared >> order. If {@code parameterTypes} is {@code null}, it is >> treated as if it were an empty array." >> >> As you know the method signature changed to use varargs since JDK 1.5, >> if parameterTypes is given null, the compiler will interpret the parameter with “new Class[] { null }”. > > you are making a wrong assumption here. If null is given there will be > no wrapping in an array. varargs are defined that there is no wrapping > if the given argument type is compatible. For Class[] this is Class[] > and of course null. Even if you had been right, you could still give > produce a call with null by reflection or using the MethodHandles API You can check by simply decompiling the generated byte codes. vararg is not a JVM feature so the compiler pre-processes and the compiler handles the given null as array’s first element. Originally class.getMethod(“methodName”, null) should have meant a static method, but with vararg, it’s not. > > bye blackdrag > > -- > Jochen "blackdrag" Theodorou > blog: http://blackdragsview.blogspot.com/ <http://blackdragsview.blogspot.com/>

2 2

JAVADOC clarification needed in Class.getMethod
by Kyung Koo Yoon 29 Aug '15

29 Aug '15

Hi, all. The javadoc comment of java.lang.Class.getMethod API has following clause. @CallerSensitive public Method getMethod(String name, Class<?>... parameterTypes) throws NoSuchMethodException, SecurityException "The {@code parameterTypes} parameter is an array of {@code Class} objects that identify the method's formal parameter types, in declared order. If {@code parameterTypes} is {@code null}, it is treated as if it were an empty array." As you know the method signature changed to use varargs since JDK 1.5, if parameterTypes is given null, the compiler will interpret the parameter with “new Class[] { null }”. So, the javadoc comment can’t be happen and inaccurate in the view of the code. I think it can be safely changed as below. or even better just remove the clause ; If {@code parameterTypes} is missing, it is treated as if it were an empty array. Regards, Yoon Kyung Koo -- -------------------- Software Innovation Driver yoonforh at gmail dot com Analyze, Reason, Reshape the Question PGP http://www.javadom.com/personal/yoonforhatgmaildotcom.asc <http://www.javadom.com/personal/yoonforhatgmaildotcom.asc>

1 0

JDK 9 RFR of JDK-8134678: Problem list SecurityManager/CheckPackageAccess.java
by joe darcy 28 Aug '15

28 Aug '15

Hello, Please review the patch below to problem list java/lang/SecurityManager/CheckPackageMatching.java while a fix for JDK-8134677: SecurityManager/CheckPackageAccess.java still failing on windows is worked on. Thanks, -Joe diff -r 3142555a4a1a test/ProblemList.txt --- a/test/ProblemList.txt Thu Aug 27 18:12:45 2015 -0700 +++ b/test/ProblemList.txt Fri Aug 28 07:38:12 2015 -0700 @@ -136,6 +136,9 @@ # 8133552 java/lang/ProcessHandle/InfoTest.java generic-all +# 8134677 +java/lang/SecurityManager/CheckPackageMatching.java windows-all + ############################################################################ # jdk_instrument

2 1