February 2015 - core-libs-dev

RFR: 8071585: Update JAX-WS RI integration to latest version (2.2.11-b150127.1410)
by Aleksej Efimov 12 Feb '15

12 Feb '15

Hi, Can I have a review for a bulk update of JAX-B/WS from upstream projects - webrev: http://cr.openjdk.java.net/~aefimov/8071585/webrev/ more details in JBS: https://bugs.openjdk.java.net/browse/JDK-8071585 There is a lot of changes (947 lines) but almost all of them are minor (comments changes/(c) years) Thank you, Aleksej

3 5

[9] RFR of 8066842: java.math.BigDecimal.divide(BigDecimal, RoundingMode) produces incorrect result
by Brian Burkhalter 12 Feb '15

12 Feb '15

Hello, Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8066842 Patch: http://cr.openjdk.java.net/~bpb/8066842/webrev.00/ The problem appears to have been that at line 4941 of the old source, in the divWord() method, one or both of the long variables ‘r’ and ‘q’ overflowed the range of int so that information was lost when these variables were truncated to 32 bits. The code of divWord() seems to have been ported from a method of the same name in MutableBigInteger wherein its constraints were made explicit. In the patch, divWord() is replaced by divRemNegativeLong(), and the use of the former in divideAndRound128() replaced with inline code for the non-negative dividend cases, and by divRemNegativeLong() for the negative dividend cases. Thanks, Brian

3 7

List.indexOf and List.lastIndexOf lambda version.
by Andrey Nazarov 12 Feb '15

12 Feb '15

Hi everyone, I there any reason why java.util.List doesn't have lambda versions of indexOf and lastIndexOf methods like list.indexOf(Predicate<>) ? --Thanks, Andrey

2 1

[9] 8064562: (doc) errors in java.io.PushbackInputStream API documentation
by Brian Burkhalter 11 Feb '15

11 Feb '15

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8064562 Patch: http://cr.openjdk.java.net/~bpb/8064562/webrev.00/ Thanks, Brian

3 4

RFR (xs): JDK-8072611: (process) ProcessBuilder redirecting output to file should work with long file names (win)
by Thomas Stüfe 11 Feb '15

11 Feb '15

Hi all, please review this small change at your convenience: http://cr.openjdk.java.net/~stuefe/webrevs/8072611/webrev.01/webrev/ It fixes a small issue which causes ProcessBuilder not to be able to open files to redirect into (when using Redirect.append) on windows, if that file name is longer than 255 chars. Kind Regards, Thomas Stuefe

3 5

Unsafe.park/unpark, j.u.c.LockSupport and Thread
by Paul Sandoz 11 Feb '15

11 Feb '15

Hi, As part of the effort around Unsafe (some may have noticed some cleanup work) i have been recently looking at the park/unpark methods. The class java.util.concurrent.locks.LockSupport [1] has some thin public wrappers around these methods: public static void unpark(Thread thread) { if (thread != null) U.unpark(thread); } public static void park() { U.park(false, 0L); } public static void parkNanos(long nanos) { if (nanos > 0) U.park(false, nanos); } public static void parkUntil(long deadline) { U.park(true, deadline); } Is not clear to me what is exactly unsafe about park/unpark and why they were not originally placed on Thread itself given the above wrapping. There is mention of unpark being unsafe with regards to native code and ensuring the thread has not been destroyed: /** * Unblock the given thread blocked on <tt>park</tt>, or, if it is * not blocked, cause the subsequent call to <tt>park</tt> not to * block. Note: this operation is "unsafe" solely because the * caller must somehow ensure that the thread has not been * destroyed. Nothing special is usually required to ensure this * when called from Java (in which there will ordinarily be a live * reference to the thread) but this is not nearly-automatically * so when calling from native code. * @param thread the thread to unpark. * */ public native void unpark(Object thread); However, native code is anyway inherently unsafe. In addition this class has a cosy relationship with Thread (it wants to poke into Thread's non-public fields): // Hotspot implementation via intrinsics API private static final sun.misc.Unsafe U = sun.misc.Unsafe.getUnsafe(); private static final long PARKBLOCKER; private static final long SEED; private static final long PROBE; private static final long SECONDARY; static { try { PARKBLOCKER = U.objectFieldOffset (Thread.class.getDeclaredField("parkBlocker")); SEED = U.objectFieldOffset (Thread.class.getDeclaredField("threadLocalRandomSeed")); PROBE = U.objectFieldOffset (Thread.class.getDeclaredField("threadLocalRandomProbe")); SECONDARY = U.objectFieldOffset (Thread.class.getDeclaredField("threadLocalRandomSecondarySeed")); } catch (ReflectiveOperationException e) { throw new Error(e); } } Although only PARKBLOCKER and SECONDARY are used AFAICT. I am sure there is some history behind all this... but in my ignorance of the past perhaps it's time to reconsider? We could reduce the coupling on Thread and dependency on Unsafe if we consider moving park/unpark and LockSupport functionality to Thread itself. Thoughts? Paul. [1] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/conc…

4 12

JDK 9 RFR of JDK-8072843: Typo in the description of the j.l.r.Executable.getAnnotatedReceiverType
by joe darcy 10 Feb '15

10 Feb '15

Hello, Please review this typo fix for JDK-8072843: Typo in the description of the j.l.r.Executable.getAnnotatedReceiverType Patch below; I spellchecked the rest of the comments and strings and didn't find any other problems. Thanks, -Joe diff -r 30f5fa716218 src/java.base/share/classes/java/lang/reflect/Executable.java --- a/src/java.base/share/classes/java/lang/reflect/Executable.java Mon Feb 09 17:49:26 2015 -0800 +++ b/src/java.base/share/classes/java/lang/reflect/Executable.java Tue Feb 10 11:24:10 2015 -0800 @@ -662,7 +662,7 @@ * * If this {@code Executable} object represents a static method or * represents a constructor of a top level, static member, local, or - * anoymous class, then the return value is null. + * anonymous class, then the return value is null. * * @return an object representing the receiver type of the method or * constructor represented by this {@code Executable} or {@code null} if

2 1

RFR: JDK-8068682 - Deprivilege/move java.corba to the ext class loader
by Mark Sheppard 10 Feb '15

10 Feb '15

Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8068682/webrev/ http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev/ which address the issue in https://bugs.openjdk.java.net/browse/JDK-8068682 this change means CORBA ORB is loaded by the extension class loader and no longer has has its former privilege of system code. as an interim measure corba is afforded all permissions privilege. this will be reduced in coming iterations. regards Mark

4 10

RFR 8068587: ScriptEngineFactory.getParameter() should specify NPE for a null key
by A. Sundararajan 10 Feb '15

10 Feb '15

Please review http://cr.openjdk.java.net/~sundar/8068587/ for https://bugs.openjdk.java.net/browse/JDK-8068587 Thanks, -Sundar

3 2

JDK 9 RFR of JDK-8069255: Suppress deprecation warnings in jdk.rmic module
by Amy Lu 10 Feb '15

10 Feb '15

Please review these changes to address a few stray deprecation warnings in the jdk.rmic module: JDK-8069255: Suppress deprecation warnings in jdk.rmic module http://cr.openjdk.java.net/~amlu/8069255/webrev.00/ I also need a sponsor for this. Thanks, Amy

3 7