February 2016 - core-libs-dev

RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the constructor
by Ramanand Patil 02 Mar '16

02 Mar '16

Hi all, Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8087104 Bug Description: DateFormatSymbols caches its own instance and calls this.clone() in the constructor. Because of this, any subclass implementation (which expects a field is always initialized to non-null in the constructor) will throw NPE in its overridden clone() method while using any instance variables which it assumed are initilaized in its contructor. Webrev: http://cr.openjdk.java.net/~rpatil/8087104/webrev.00/ Fix: Instead of using its own instance for caching and calling clone in DateFormatSymbols, a nested class SymbolsCacheEntry is introduced. Regards, Ramanand.

3 3

RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary
by Ivan Gerasimov 01 Mar '16

01 Mar '16

Hello! When the capacity of a StringBuilder needs to be increased (either due to append() or due to explicit call to ensureCapacity()), the new capacity is calculated as "twice the old capacity, plus 2", rounded down to Integer.MAX_VALUE: http://docs.oracle.com/javase/8/docs/api/java/lang/StringBuilder.html#ensur… Because of that, StringBuilder throws OOM early, even though there may be room to grow. The proposed solution is to reserve a few bytes at the top of the range and only try to allocate them if absolutely required. The regression test is @ignored by default, as it is too greedy for memory. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8149330 WEBREV: http://cr.openjdk.java.net/~igerasim/8149330/00/webrev/ Sincerely yours, Ivan

4 15

RFR: 8150856 - Inconsistent API documentation for @param caller in System.LoggerFinder.getLogger
by Daniel Fuchs 01 Mar '16

01 Mar '16

Hi, Please find below a trivial fix for: https://bugs.openjdk.java.net/browse/JDK-8150856 8150856: Inconsistent API documentation for @param caller in System.LoggerFinder.getLogger http://cr.openjdk.java.net/~dfuchs/webrev_8150856/webrev.00 The @param caller clause says that caller can be null, whereas the @throws clause says that NPE will be thrown. The @throws clause is correct and @param needs to be fixed. best regards, -- daniel --- old/src/java.base/share/classes/java/lang/System.java 2016-02-29 18:41:30.000000000 +0100 +++ new/src/java.base/share/classes/java/lang/System.java 2016-02-29 18:41:30.000000000 +0100 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1994, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1994, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -1419,7 +1419,6 @@ * * @param name the name of the logger. * @param caller the class for which the logger is being requested; - * can be {@code null}. * * @return a {@link Logger logger} suitable for the given caller's * use.

3 3

[9] RFR: 8150174: Update JAX-WS RI integration to latest version (2.3.0-SNAPSHOT)
by Aleksej Efimov 01 Mar '16

01 Mar '16

Hi, Please, review the bulk update of JAX-WS/B from upstream projects: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8150174/9/00/ Details (list of fixed issues) can be found in bug report: https://bugs.openjdk.java.net/browse/JDK-8150174 The following test sets were executed over JDK9 with integrated changes: jdk_other JTREG tests; JCK9 jaxws tests; JAXWS unit tests; Thanks, Aleksej

2 2

RFR(M): 8150635: j.l.i.MethodHandles.loop(...) throws IndexOutOfBoundsException
by Michael Haupt 01 Mar '16

01 Mar '16

Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8150635 Webrev: http://cr.openjdk.java.net/~mhaupt/8150635/webrev.00 There were two issues to address that led to IOOBE being thrown. 1. Lack of support for deriving the loop signature from given parameter type lists in case no init function is given at all. 2. The loop combinator reporting a wrong exception in case a parameter type list is longer than the common parameter sequence. In this case, an error about non-effectively identical parameter type lists should be signalled. See the JIRA issue for details and examples. Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

2 4

[PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries
by KUBOTA Yuji 01 Mar '16

01 Mar '16

Hi all, We need reviewer(s) for this PoC. Could you please review this proposal and PoC ? Thanks, Yuji 2015-11-26 13:22 GMT+09:00 KUBOTA Yuji <kubota.yuji(a)gmail.com>: > Hi all, > > * Sorry for my mistake. I re-post this mail because I sent before get > a response of subscription confirmation of core-libs-dev. > > Our customers have to handle password-protected zip files. However, > Java SE does not provide the APIs to handle it yet, so we must use > third party library so far. > > Recently, we found JDK-4347142: "Need method to set Password > protection to Zip entries", and we tried to implement it. > > The current zlib in JDK is completely unaffected by this proposal. The > traditional zip encryption encrypts a data after it is has been > compressed by zlib.[1] So we do NOT need to change existing zlib > implementation. > > We've created PoC and uploaded it as webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/ > > Test code is as below. This code will let you know how this PoC works. > http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java > > In NTT, a Japanese telecommunications company. We are providing many > enterprise systems to customers. Some of them, we need to implement to > handle password-protected zip file. I guess that this proposal is > desired for many developers and users. > > I'm working together with Yasumasa Suenaga, jdk9 committer (ysuenaga). > We want to implement it if this proposal accepted. > > [1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT > (6.0 Traditional PKWARE Encryption) > > Thanks, > Yuji

7 23

RFR 9: 8150346 : java/lang/ProcessHandle/Infotest.java failed: startTime after process spawn completed
by Roger Riggs 29 Feb '16

29 Feb '16

Please review a test fix to resolve a timing race with the start time of a spawned process. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-start-8150346/ Jira: https://bugs.openjdk.java.net/browse/JDK-8150346 Thanks, Roger

3 5

RFR [9] 8150162: Move sun.misc.Version to a truly internal package
by Chris Hegarty 29 Feb '16

29 Feb '16

sun.misc.Version is the core libraries part of a private interface with the JVM to query and set specific JVM version and capabilities, as well as being responsible for setting the system properties for "java.version”, "java.runtime.version", and "java.runtime.name" ( which are generated during the build ). It is not a "Critical API", as defined by JEP 260, so should be moved out of sun.misc and placed into a more appropriate package where it can be encapsulated. Version is only used by j.l.System during initialization, so I’ve taken the liberty of moving it into java.lang as package-private. It could, however, be placed in jdk.internal.misc, if it is more generally useful. That said, most other usages should be able to use the JDK specific Version API. http://cr.openjdk.java.net/~chegar/8150162/ https://bugs.openjdk.java.net/browse/JDK-8150162 -Chris. P.S. 8150163 & 8150168 are in progress to replace unnecessary usages of sun.misc.Version with the JDK specific Version.

6 11

RFR [9] 8149122: Move sun.misc.URLClassPath and Resource to an internal package
by Chris Hegarty 29 Feb '16

29 Feb '16

sun.misc.URLClassPath, and its accompanying Resource, are not "Critical APIs", as defined by JEP 260, so they should be moved out of sun.misc and placed into a more appropriate package where they can be encapsulated. http://cr.openjdk.java.net/~chegar/8149122/ https://bugs.openjdk.java.net/browse/JDK-8149122 -Chris.

3 2

Frequent allocations / promotions of StringCoding$String{Encoder,Decoder} objects
by Tony Printezis 29 Feb '16

29 Feb '16

Hi all, We recently noticed that in several of our production services there are very frequent allocations / promotions of coder objects from the StringCoding class (e.g. java.lang.StringCoding$String{Encoder,Decoder} instances). We are pretty sure that these are allocated to replace the coders cached in the StringCoding ThreadLocals (we also see SoftReferences being allocated / promoted along with the coder objects): /** The cached coders for each thread */ private final static ThreadLocal<SoftReference<StringDecoder>> decoder = new ThreadLocal<>(); private final static ThreadLocal<SoftReference<StringEncoder>> encoder = new ThreadLocal<>(); We seem to be doing encoding / decoding using at least two different charsets (we also see Encoder / Decoders for those two charsets being allocated / promoted) which is causing this churn (i.e., the coder allocations are not caused by the SoftReferences being cleared; they are frequently replaced when a coder for a different charset is required). Even though we observed this behavior with JDK 8 it should also exist in JDK 9 (StringCoding still has the same two ThreadLocals; we can confirm this very easily). Has anyone identified this issue before? We believe that caching a small number of coders per thread (instead of just one) could avoid this unnecessary churn. We’ll be happy to contribute such a fix if there’s interest in getting it accepted. Also, why are SoftReferences used here? In our case, if a thread does some encoding / decoding once it’s likely it will likely keep doing it for ever. So the use of SoftReferences here is not very helpful (it adds unnecessary overhead to the GC, not only due to the extra copying but also due to the extra work required during reference processing). Was there a specific reason for the use of SoftReferences here? Finally, the StringCoding coder c'tor allocates a new Charset coder (Charset{Encoder,Decoder}) for the specific charset. But such Charset coders already seem to be cached in ThreadLocals in the sun.nio.cs.ThreadLocalCoders class. Any reason why we cannot re-use those? (Oh, and also note that this cache does not use SoftReferences, which makes their use by the StringCoding class even more perplexing.) (a tip of the hat to my colleague Peter Beaman for discovering this issue) Tony ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis(a)twitter.com

5 8