March 2017 - core-libs-dev

JDK-8067661: transferTo proposal for Appendable
by Patrick Reinhart 15 Nov '17

15 Nov '17

Hi Chris & Pavel, Based on the transferTo Method on the InputStream I would propose to introduce a default method on the Readable interface. In that way the method can be used for all existing implementations of Readable and still be implemented in a special way by a individual implementer. /** * Reads all characters from this readable and writes the characters to * the given appendable in the order that they are read. On return, this * readable will be at end its data. * * This method may block indefinitely reading from the readable, or * writing to the appendable. The behavior for the case where the readable * and/or appendable is asynchronously closed, or the thread * interrupted during the transfer, is highly readable and appendable * specific, and therefore not specified. * * If an I/O error occurs reading from the readable or writing to the * appendable, then it may do so after some characters have been read or * written. Consequently the readable may not be at end of its data and * one, or both participants may be in an inconsistent state. It is strongly * recommended that both readable and appendable be promptly closed * if needed and an I/O error occurs. * * @param out the appendable, non-null * @return the number of characters transferred * @throws IOException if an I/O error occurs when reading or writing * @throws NullPointerException if {@code out} is {@code null} * * @since 1.9 */ default long transferTo(Appendable out) throws IOException { .... } -Patrick

5 26

RFR 8145635 : Add TCP_QUICKACK socket option
by vyom 12 Oct '17

12 Oct '17

Hi All, Please review my code changes for the below issue. Bug: JDK-8145635 : Add TCP_QUICKACK socket option Webrev: http://cr.openjdk.java.net/~vtewari/8145635/webrev0.0/index.html <http://cr.openjdk.java.net/%7Evtewari/8145635/webrev0.0/index.html> Currently TCP_QUICKACK is only supported on Linux( since Linux 2.4.4) so i implemented is as "ExtendedSocketOption". Thanks, Vyom

5 8

ISO-8859-16 charset/decoder/encoder
by Charles Oliver Nutter 25 Aug '17

25 Aug '17

Again, apologies if this is not the right list. OpenJDK does not currently contain support for encoding/decoding ISO-8859-16. A JRuby user recently reported that they needed this encoding. So, I implemented it. Here's a link to the charset/decoder/encoder in JRuby's repository: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/uti… I tried to follow the general form of the other ISO-8859 charsets, but there's probably more reuse possible (I believe they use sun.nio.cs classes I can't access). Happy to contribute this. Unsure of the process. - Charlie

4 5

RFR: jsr166 jdk10 integration wave 1
by Martin Buchholz 22 Jul '17

22 Jul '17

First jdk10 integration http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/ Mostly focused on thread pools.

2 7

RFR: 8176508 Update JAX-WS RI integration to latest version
by Roman Grigoriadi 16 Jun '17

16 Jun '17

Hi, Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ Summary of changes: jaxws/src/java.activation/share/classes/javax/activation/* These are from Bill, fixing JDK-8049379 jaxws/src/java.xml.bind/share/classes/javax/xml/bind/* JDK-8169496 - JAXB annotated classes needs to be open for JAXB impl module. Javadoc updates + propagation of openness if JAXB impl is in other module than java.xml.bind. This needs an update to JAXB JCK tests. jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/** Contains a fix for reported bug after removal dependencies to JDK internal classes from SAAJ + formattig updates according to review comments on last sync. jaxws/src/java.xml.ws/share/classes/**/*Messages.java jaxws/src/jdk.xml.ws/share/classes/**/*Messages.java These are generated files, which were modified manually in JDK in order to solve JDK-8153944. Generation of these file was updated (removed Lambda), these changes should respect JDK-8153944 fix. Patch also contains several small bugfixes, not tracked in JBS. Best regards, Roman

8 30

8169425: Values computed by a ClassValue should not strongly reference the ClassValue
by Paul Sandoz 11 May '17

11 May '17

Hi, Please review the addition of an api note to ClassValue.computeValue. There is some history behind this issue. Another issue was logged [1] related to Groovy using ClassValue and there being a memory leak with classes/loaders not being GC’ed, but it turned out the problem was with Groovy's explicit retention of computed values in a global set. So i closed that issue down. But, there is an edge case where it’s possible to induce out of memory errors with ClassValue, specifically if the computed value holds onto the corresponding ClassValue instance. I think this is an edge case and does not warrant a change to the ClassValue implementation to support weak refs to computed values which is likely to complicate an already intricate implementation and perturb its performance characteristics. So i have opted for an api note. I don’t want to normatively specify this, nor do i want to allude to various implementation details. (One can argue a similar note could be written for ThreadLocal.) Thanks, Paul. [1] https://bugs.openjdk.java.net/browse/JDK-8136353 --- a/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 12:36:21 2016 -0800 +++ b/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 15:25:04 2016 -0800 @@ -62,6 +62,13 @@ * If this method throws an exception, the corresponding call to {@code get} * will terminate abnormally with that exception, and no class value will be recorded. * + * @apiNote + * Care should be taken to ensure that this {@code ClassValue} is not + * <a href="../ref/package-summary.html#reachability">strongly reachable</a> + * from the computed value. Doing so may prevent classes and their loaders + * from being garbage collected which in turn may induce out of memory + * errors. + * * @param type the type whose class value must be computed * @return the newly computed value associated with this {@code ClassValue}, for the given class or interface * @see #get

5 15

[RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider
by Rob McKenna 27 Apr '17

27 Apr '17

Hi folks, I'm looking for feedback on this suggested fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-816076 http://cr.openjdk.java.net/~robm/8160768/webrev.01/ This is something that has come up a few times. Basically in certain environments (e.g. MS Active Directory) there is a dependence on DNS records to provide a pointer to the actual ldap server to be used for a given LdapCtx.PROVIDER_URL where the url itself simply points to the domain name. This fix add a new Ldap context property which allows a user to specify a class (implementing BiFunction) which can perform any necessary extra steps to derive the ldap servers hostname/port from the PROVIDER_URL. -Rob

3 9

RFR [9] 8177738: Runtime.Version must be a value-based class
by Pavel Rappo 18 Apr '17

18 Apr '17

Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8177738/webrev.00/ This is an attempt to resolve a group of issues related to Version-String API and its implementation: 8177738: Runtime.Version must be a value-based class 8148822: (spec) Regex in Runtime.Version and JEP 223 should match 8160954: (spec) Runtime.Version regex and $PRE/$OPT issues 8148877: (spec) Specify when an empty '+' is required in a version string A good amount of work has been already done here and we just need to finish it. Let me explain what this patch does starting from the most trivial changes. - Fixes certain javadoc issues [a] (e.g. dangling html tags, overly qualified symbol references in @link tags, etc.) - Refactors Basic.java test, making it a little bit easier to read/modify this test in the future. - Addresses [2] in Runtime.java:963,1050. In addition I've rephrased Runtime.java:951 to reflect the fact a version string contains only the mentioned components and nothing else. In other words, $VSTR *matches* a valid version-string rather than *finds* itself somewhere in this version-string. - Makes Runtime.Version a value-based class [1][5]. The class has gotten `final` modifier, the only constructor has become private and the usual (in this case) verbiage has been added to the javadoc. Before that, Runtime.Version had ticked all other the boxes in the value-based class checklist already. - Improves $VNUM list mechanics in VersionProps.java.template and Runtime.java:1149-1153 by providing immutable list instead of unmodifiable. This change has become possible due to the fact Runtime.Version constructor has become private and, thus, all the callers are known and trusted. - Removes redundant/explicit javadoc declarations in `hashCode`, `equals` and `compareTo` methods. These methods are documented needlessly explicit. The only truly justified comment sits inside `compareToIgnoreOptional` method. Since `compareToIgnoreOptional` and `equalsIgnoreOptional` are not inherited, I marked the "consistent-with" relationship between them explicitly [c]. - Now a few words about a not-so-pleasant part which addresses [3][4]. In a nutshell the regex-style format ($VSTR) which is used in the spec to define the version-string, matches all valid version strings and *some more*. Here's the format: $VNUM(-$PRE)?(\+($BUILD)?(-$OPT)?)? If we expand all optional elements we will get the following 8 possibilities: ## $VSTR $PRE $BUILD $OPT EXAMPLE -------------------------------------------------------------------------------- 1 $VNUM 0 0 0 9.0.1 2 $VNUM+-$OPT 0 0 1 9.0.1+-longcat.dev 3 $VNUM+$BUILD 0 1 0 9.0.1+256 4 $VNUM+$BUILD-$OPT 0 1 1 9.0.1+256-longcat.dev 5 $VNUM-$PRE 1 0 0 9.0.1-ea * 6 $VNUM-$PRE+-$OPT 1 0 1 9.0.1-ea+-longcat.dev 7 $VNUM-$PRE+$BUILD 1 1 0 9.0.1-ea+256 8 $VNUM-$PRE+$BUILD-$OPT 1 1 1 9.0.1-ea+256-longcat.dev Now, ##6 was disallowed by design. In the case when $BUILD is not present, but both $PRE and $OPT are, the $VSTR will instead look like this: 6 $VNUM-$PRE-$OPT 1 0 1 9.0.1-ea-longcat.dev (i.e. without the "+" separator). This is a problem because it means that in addition to the format it needs a clear description of exceptional cases which are to be subtracted from the set of matched version-strings. Such a description has been proposed in [6] (you can have a look at the webrev that thread refers to): * If the build number is unset, then {@code '+'} may only be present * when {@code $OPT} is present and {@code $PRE} is not. It indeed may be a satisfactory solution. However I would argue that it's probably not the best one. I suspect spec readers will jump straight to the format completely missing "the special case" paragraph simply because the format attracts attention and neatly defines the version-string. Neatly but wrongly. Another option would be to split the $VSTR format into a minimal number of sub-cases (e.g. Runtime:1032-1034). This will require no extra "special case" paragraph and will draw reader's attention to all the subtleties on the spot. # ## -------------------------------------------------------------------------------- 1 $VNUM(-$PRE)?\+$BUILD(-$OPT)? 3, 4, 7, 8 2 $VNUM-$PRE(-$OPT)? 5, 6 3 $VNUM(+-$OPT)? 1, 2 One more option would be to require "+" to be there in the case where any component to the right from $PRE is present (i.e. $BUILD or $OPT or both). This will greatly simplify the rules and allow the $VSTR to stay as it is today. This option would affect only the case ##6: 6 $VNUM-$PRE+-$OPT 1 0 1 9.0.1-ea+-longcat.dev ^^ Yes, it looks a bit ugly, but we already have this ugliness in case 2 (and we can't get rid of it because of [3]): 2 $VNUM+-$OPT 0 0 1 9.0.1+-longcat.dev ^^ I suspect both 2 and 6 will be pretty rare anyway as it would mean optional build information is there, but the build number is not. Sounds like a corner case to me. Thanks, -Pavel -------------------------------------------------------------------------------- [1] https://bugs.openjdk.java.net/browse/JDK-8177738 [2] https://bugs.openjdk.java.net/browse/JDK-8148822 [3] https://bugs.openjdk.java.net/browse/JDK-8148877 [4] https://bugs.openjdk.java.net/browse/JDK-8160954 [5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046813.html [6] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-October/044277.ht… [a] If you build locally or use promoted builds, please keep in mind there's a known issue with rendering documentation for Runtime.Version in some browsers: https://bugs.openjdk.java.net/browse/JDK-8177727 [b] Startup time/memory footprint might benefit as well (it will definitely require some benchmarking to determine if it is the case) [c] Even though I'm fully aware I do not have the full knowledge the design decisions were based upon, I must say I fail to see why equalsIgnoreOptional and compareToIgnoreOptional methods have been introduced from the day 1. It looks like something that could be neatly solved by providing a custom Comparator if needed.

3 4

RFR 9: 8165641 : Deprecate Object.finalize
by Roger Riggs 17 Apr '17

17 Apr '17

Finalizers are inherently problematic and their use can lead to performance issues, deadlocks, hangs, and other problematic behavior. The problems have been accumulating for many years and the first step to deprecate Object.finalize and the overrides in the JDK to communicate the issues, recommend alternatives, and motivate changes where finalization is currently used. The behavior of finalization nor any uses of finalize are not modified by this change. Most of the changes are to suppress compilation warnings within the JDK. Please review and comment. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641/ Issue: https://bugs.openjdk.java.net/browse/JDK-8165641 Thanks, Roger

20 71

JDK 10 RFR of 8176894: Provide specialized implementation for default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute in TreeMap
by Sergey Kuksenko 10 Apr '17

10 Apr '17

Hi All, Please, review: https://bugs.openjdk.java.net/browse/JDK-8176894 http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.00/ The issue was created for JDK10 in order to don't disturb JDK9 before launch. -- Best regards, Sergey Kuksenko

5 10