March 2016 - core-libs-dev

[9] RFR of 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently
by Brian Burkhalter 20 May '16

20 May '16

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-5100935 Patch: http://cr.openjdk.java.net/~bpb/5100935/webrev.00/ Summary: Add multiplyFull() and multiplyHigh() methods to java.lang.Math. This change addresses the Java specification and implementation only. The addition of compiler intrinsics for these methods will be tracked separately. Thanks, Brian

4 8

[9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math
by Brian Burkhalter 20 May '16

20 May '16

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8023217 Patch: http://cr.openjdk.java.net/~bpb/8023217/webrev.00/ Summary: Add some additional methods of the same name as existing methods but with the commonly used parameter signature “long,int”: long multiplyExact(long,int) long floorDiv(long,int) int floorDiv(long,int) These methods also provide hooks for potential intrinsics. There might be room for improvement in their Java implementations. The modifications to the java.time classes are to fix warnings about “redundant cast to int.” Thanks, Brian

4 9

RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java
by Brent Christian 18 May '16

18 May '16

Hi, Please review this fix, courtesy of Peter Levart (thanks!), that I would like to get in. https://bugs.openjdk.java.net/browse/JDK-8029891 http://cr.openjdk.java.net/~bchristi/8029891/webrev.0/ There is some discussion of it in the bug report, starting at 2014-12-31. The problem, as stated by Mandy: "System Properties is a hashtable that synchronizes on itself for any access. Currently System.getProperties returns the Properties instance accessed by the system in which any application code might synchronize on it (that's what the test is doing). The problem reported JDK-6977738 is about Properties.store method that was fixed not to synchronize on this instance. System property is a common way for changing the default setting and so it's impractical to expect the class loading code path not to call System.getProperty." This fix changes java.util.Properties to store its values in an internal ConcurrentHashMap, ignoring its Hashtable heritage. In this way, Properties can be "de-sychronized": all methods inherited from Hashtable are overridden, to remove synchronization, and delegate to the internal CHM. The serialized form is unchanged. An alternative approach considered would be for System.getProperties() to return a duplicate snapshot of the current Properties. This presents a compatibility risk to existing code that keeps a reference to the return value of System.getProperties() and expects to either read new properties added afterwards, or set properties on the cached copy. -Brent

7 41

We don't need jdk.internal.ref.Cleaner any more
by Peter Levart 16 May '16

16 May '16

Hi, sun.misc.Cleaner has been moved to internal package jdk.internal.ref recently [1] to clean-up sun.misc namespace. But now that: - we have comparable public API (java.lang.ref.Cleaner & Cleanable) [2] - we have an internal shared java.lang.ref.Cleaner instance (jdk.internal.ref.CleanerFactory.cleaner()) - sun.misc.Cleaner is not a special kind of Reference any more in the JVM [3] ...I think there's no reason to keep this special internal API any more. It can be replaced with public API. I propose to remove jdk.internal.ref.Cleaner class and replace its usages with java.lang.ref.Cleaner and friends [4]. What do you say? Regards, Peter [1] https://bugs.openjdk.java.net/browse/JDK-8148117 [2] https://bugs.openjdk.java.net/browse/JDK-8138696 [3] https://bugs.openjdk.java.net/browse/JDK-8143847 [4] http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.0…

11 72

RFR: regex changes
by Xueming Shen 11 May '16

11 May '16

6 13

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 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present
by Liam Miller-Cushon 27 Apr '16

27 Apr '16

If an annotation value is an array of class literals or enum constants, calling Class.getAnnotation() fails with ArrayStoreException if the element type is not found. This patch implements the proposed fix from the bug thread, which allows getAnnotation() to succeed and a TypeNotPresentException to be thrown from Annotation.value(). bug: https://bugs.openjdk.java.net/browse/JDK-7183985 The patch is attached.

2 6

PING: RFR: JDK-4347142: Need method to set Password protection to Zip entries
by Yasumasa Suenaga 19 Apr '16

19 Apr '16

PING: Could you review it? We want to move forward this enhancement. Thanks, Yasumasa 2016/03/19 22:01 "Yasumasa Suenaga" <yasuenag(a)gmail.com>: > Hi Alan, > > > I think the main issue here is to decide whether the API > > should be extended for encryption or not. > > We've discussed on the premise that we add the API for supporting ZIP > encryption. > In this context, Sherman tried to implement AES encryption extending > current API. [1] > > IMHO, ZIP encryption should be implemented as extention of current ZIP API > because encryption/decryption will process for each ZIP entries. > > According to Developers' Guide, guideline for adding new API is TBD. [2] > What should I do next? > > > Thanks, > > Yasumsa > > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037903.ht… > [2] http://openjdk.java.net/guide/changePlanning.html#api > > > On 2016/03/19 0:25, Alan Bateman wrote: > > > > On 18/03/2016 15:02, Yasumasa Suenaga wrote: > >> Hi all, > >> > >> We (including me and Yuji Kubota (ykubota: OpenJDK jdk9 Author)) > discussed > >> about this issue from Nov. 2015. [1] > >> We heard several comments and we applied them to our patch. > >> > >> I have not heard new comment for our latest patch. > >> So I send review request for it. Could you review it? > >> > >> webrev: > >> http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/ > >> > >> Usage of new API: > >> > http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/Test.java > >> > > Yasumasa - I think the main issue here is to decide whether the API > > should be extended for encryption or not. If exposing it in the API make > > sense then I assume that alternative names to java.util.zip.ZipCryption > > needs to be explored. > > > > -Alan. > > >

8 8

RFR:JDK-8148947:DateTimeFormatter pattern letter 'g'
by nadeesh tv 19 Apr '16

19 Apr '16

Hi all, BUG ID : https://bugs.openjdk.java.net/browse/JDK-8148947 Webrev : http://cr.openjdk.java.net/~ntv/8148947/webrev.00/ Added new pattern letter 'g' for Modified Julian day. Apart from that made clarification to JulianFields and removed semicolons from docs of DateTimeFormatterBuilder as suggested by Stephen -- Thanks and Regards, Nadeesh TV

3 3

RFR 8151352, jdk/test/sample fails with "effective library path is outside the test suite"
by Felix Yang 15 Apr '16

15 Apr '16

Hi all, please review the fix for two tests under "test/sample/". Bug: https://bugs.openjdk.java.net/browse/JDK-8151352 Webrev: http://cr.openjdk.java.net/~xiaofeya/8151352/webrev.00/ Original declaration, "@library ../../../src/sample...", is invalid with the latest change in jtreg. See https://bugs.openjdk.java.net/browse/CODETOOLS-7901585. This fix doesn't resolve dependency to "src/sample", but only converts them into testng tests and declares "external.lib.roots" to avoid dot-dot. Thanks, Felix

5 7