May 2018 - core-libs-dev

Draft JEP: Enhanced pseudo-random number generators
by Guy Steele 23 May '19

23 May '19

Please check out a new draft JEP https://bugs.openjdk.java.net/browse/JDK-8193209 <https://bugs.openjdk.java.net/browse/JDK-8193209> that proposes new interface types and implementations for pseudo-random number generators. —Guy

2 3

Re: RFR: 8198526: getAnnotatedOwnerType does not handle static nested classes correctly
by Liam Miller-Cushon 20 Dec '18

20 Dec '18

(replying to edit the subject) On Wed, Feb 21, 2018 at 2:18 PM, Liam Miller-Cushon <cushon(a)google.com> wrote: > Hello, > > Please review this fix to the handling of static nested classes > in getAnnotatedOwnerType. > > webrev: http://cr.openjdk.java.net/~cushon/8198526/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8198526 >

2 6

The new optimized version of Dual-Pivot Quicksort
by Vladimir Yaroslavskiy 20 Nov '18

20 Nov '18

Hi team, In Sept 2009 Josh Bloch, Jon Bentley and I introduced new sorting algorithm, Dual-Pivot Quicksort, for primitives in JDK 7 and later I suggested several improvements of Dual-Pivot Quicksort, which were integrated into JDK 8. Now I have more optimized and faster version of Dual-Pivot Quicksort. I have been working on it for the last 5 years. Please, find the summary of changes below and sources / diff at webrev [1]. All tests and benchmarking were run on the most recent build of JDK 10, jdk-10-ea+39. The new version shows the better performance on different inputs and guarantees n*log(n) on any data. The new implementation of Dual-Pivot Quicksort is 'all-in-one' version: it contains one code for both parallel and sequential sorting algorithms. Suggested version is 10-20% faster on random data, 1.5-4 times faster on nearly structured arrays, 1.5-2 times faster on period inputs. Parallel Dual-Pivot Quicksort is 1.5-3 times faster than current algorithm based on merge sort. Benchmarking on the test suite, suggested by Jon Bentley, shows the boost of performance in 1.4 times. This test suite contains several types of inputs, such as random data, nearly structured arrays, data with period and so on. Also there are several modifications of inputs and parameters which are used in data building. We run sorting on all combinations to compare two algorithms. Please let me know if you have any questions / comments. Summary of changes: DualPivotQuicksort class ------------------------ * Pivots are chosen with another step, the 1-st and 5-th candidates are taken as pivots instead of 2-nd and 4-th. * Splitting into parts is related to the golden ratio * Pivot candidates are sorted by combination of 5-element network sorting + insertion sort * New backwards partitioning is simpler and more efficient * Quicksort tuning parameters were updated * Merging sort is invoked on each iteration from Quicksort * Additional steps for float/double were fully rewritten * Heap sort is invoked on the leftmost part * Heap sort is used as a guard against quadratic time * Parallel sorting is based on Dual-Pivot Quicksort instead of merge sort SortingAlgorithms class ----------------------- * Merging sort and pair insertion sort were moved from DualPivotQuicksort class * Pair insertion sort was simplified and optimized * New nano insertion sort was introduced for tiny arrays * Merging sort was fully rewritten * Optimized merging partitioning is used * Merging parameters were updated * Merging of runs was fully rewritten * Fast version of heap sort was introduced * Parallel merging sort was also provided Sorting / ParallelSorting classes --------------------------------- * New test cases were added * Sources of these classes were unified Arrays class ------------ * Calls of Dual-Pivot Quicksort were updated * Parallel sorting of primitives was switched to parallel Dual-Pivot Quicksort * Javadoc was modified ArraysParallelSortHelpers class ------------------------------- * Old implementation of parallel sorting for primitives was removed * Javadoc was updated Thank you, Vladimir -------------------------------------------------------------------- [1] http://cr.openjdk.java.net/~alanb/DualPivotSortUpdate/webrev.01/ --------------------------------------------------------------------

5 18

JDK-6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars
by Philipp Kunz 22 Oct '18

22 Oct '18

Hi, I tried to fix bug 6202130 about manifest utf support and come up now with a test as suggested in the bug's comments that shows that utf charset actually works before removing the comments from the code. When I wanted to remove the XXX comments about utf it occurred to me that version attributes ("Signature-Version" and "Manifest-Version") would never be broken across lines and should anyway not support the whole utf character set which sounds more like related to bugs 6910466 or 4935610 but it's not a real fit. Therefore, I could not remove one such comment of Attributes#writeMain but I changed it. The first comment in bug 6202130 mentions only two comments but there are three in Attributes. In the attached patch I removed only two of three and changed the remaining third to not mention utf anymore. At the moment, at least until 6443578 is fixed, multi-byte utf characters can be broken across lines. It might be worth a consideration to test that explicitly as well but then I guess there is not much of a point in testing the current behavior that will change with 6443578, hopefully soon. There are in my opinion enough characters broken across lines in the attached test that demonstrate that this still works like it did before. I would have preferred also to remove the calls to deprecated String(byte[], int, int, int) but then figured it relates more to bug 6443578 than 6202130 and now prefer to do that in another separate patch. Bug 6202130 also states that lines are broken by String.length not by byte length. While it looks so at first glance, I could not confirm. The combination of getBytes("UTF8"), String(byte[], int, int, int), and then DataOutputStream.writeBytes(String) in that combination does not drop high-bytes because every byte (whether a whole character or only a part of a multi-byte character) becomes a character in String(...) containing that byte in its low-byte which will be read again from writeBytes(...). Or put in a different way, every utf encoded byte becomes a character and multi-byte utf characters are converted into multiple string characters containing one byte each in their lower bytes. The current solution is not nice, but at least works. With that respect I'd like to suggest to deprecate DataOutputStream.writeBytes(String) because it does something not exactly expected when guessing from its name and that would suit a byte[] parameter better very much like it has been done with String(byte[], int, int, int). Any advice about the procedure to deprecate something? I was surprised that it was not trivial to list all valid utf characters. If someone has a better idea than isValidUtfCharacter in the attached test, let me know. Altogether, I would not consider 6202130 resolved completely, unless maybe all remaining points are copied to 6443578 and maybe another bug about valid values for "Signature-Version" and "Manifest-Version" if at all desired. But still I consider the attached patch an improvement and most of the remainder can then be solved in 6443578 and so far I am looking forward to any kind of feedback. Regards, Philipp

5 19

Reactive Streams utility API
by James Roper 28 Sep '18

28 Sep '18

Hi all, This is an email to give people a heads up that we'd like to look at creating an API, in the same vein as the JDK8 Streams API, for building reactive streams (a la JDK9 juc.Flow). Our goals for this are: * To fill a gap in the JDK where if a developer wants to do even the simplest of things with a JDK9 juc.Flow, such as map or filter, they need to bring in a third party library that implements that. * To produce an API that can build Publishers, Subscribers, Processors, and complete graphs, for the purposes of consuming APIs that use reactive streams (for example, JDK9 Http Client). * To produce an API that aligns closely with ju.stream.Stream, using it for inspiration for naming, scope, general API shape, and other aspects. The purpose of this goal is to ensure familiarity of Java developers with the new API, and to limit the number of concepts Java developers need to understand to do the different types of streaming offered by the JDK. * To produce an API that can be implemented by multiple providers (including an RI in the JDK itself), using the ServiceLoader mechanism to provide and load a default implementation (while allowing custom implementations to be manually provided). There are a lot of concerns that each different streams implementation provides and implements, beyond streaming, for example monitoring/tracing, concurrency modelling, buffering strategies, performance aspects of the streams handling including fusing, and context (eg thread local) propagation. This will allow libraries to use and provide contracts based on this API without depending on a particular implementation, and allows developers to select the implementation that meets their needs. Non goals: * To produce a kitchen sink of utilities for working with reactive streams. There already exist a number of reactive streams implementations that seek to meet this goal (eg, Akka Streams, Reactor, RxJava), and once you go past the basics (map, filter, collect), and start dealing with things like fan in/out, cycles, restarting, etc, the different approaches to solving this start to vary greatly. The JDK should provide enough to be useful for typical every day streaming use cases, with developers being able to select a third party library for anything more advanced. We will update this list when we have something ready for public review. This probably won't be far off. Our hope is that we can propose this as a JEP. Regards, James -- *James Roper* *Senior Octonaut* Lightbend <https://www.lightbend.com/> – Build reactive apps! Twitter: @jroper <https://twitter.com/jroper>

3 11

Initial JDK 11 RFR of JDK-8202385: Annotation to mark serial-related fields and methods
by joe darcy 10 Aug '18

10 Aug '18

Hello, Please review the webrev (code below) to address JDK-8202385: Annotation to mark serial-related fields and methods http://cr.openjdk.java.net/~darcy/8202385.0/ The proposed java.io.Serial annotation type is intended to be used along with an augmented implementation of javac's "serial" lint check; that work will be done separately as part of JDK-8202056: "Expand serial warning to check for bad overloads of serial-related methods". Currently, javac's serial lint check looks for serialVersionUID fields to be declared in Serializable classes. However, there are various other structural properties of the declaration of serialization-related fields and methods that could be checked at compile-time. The proposed java.io.Serial annotation type (name subject to change [*]) explicitly marks fields and methods that are intended to be called as part of the Serialization machinery. This marking allows using the wrong name for a method or field to be easily caught; the serialization mechanism will generally silently ignore mis-declared serialization-related fields and methods. Since the annotation is intended for compile-time checking, the annotation type has has source retention, like the Override annotation type. Cheers, -Joe [*] Unleash the bikes from the bikeshed! On the name and package of the annotation type, since the other serialization types are in the java.io package and the checks are not proposed to be part of the language, this annotation type more appropriately lives in java.io package rather than java.lang. The name "Serial" is consistent with the "@serial" javadoc tag. Other possible names include "Serialize" and "SerialRelated". Another possibility would be to have the annotation type be a nested type in java.io.Serializable. -=-=-=-=-=-=- // GPLv2 elided. package java.io; import java.lang.annotation.*; /** * Indicates that a field or method is related to the {@linkplain * Serializable serialization mechanism}. This annotation type is * intended to allow compile-time checking of serialization-related * declarations, analogous to the checking enabled by the {@link * java.lang.Override} annotation type to validate method overriding. * * Specifically, annotations of this type are intended to be * applied to serialization-related methods and fields in classes * declared to be {@code Serializable}. The five serialization-related * methods are: * * <ul> * <li>{@code private void writeObject(java.io.ObjectOutputStream stream) throws IOException} * <li>{@code private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException} * <li>{@code private void readObjectNoData() throws ObjectStreamException} * <li>ANY-ACCESS-MODIFIER {@code Object writeReplace() throws ObjectStreamException} * <li>ANY-ACCESS-MODIFIER {@code Object readResolve() throws ObjectStreamException} * </ul> * * The two serialization-related fields are: * * <ul> * <li>{@code private static final ObjectStreamField[] serialPersistentFields} * <li>{@code private static final long serialVersionUID} * </ul> * * A compiler can validate that a method or field marked with a * <code>@Serial</code> annotation is one of the defined serialization-related * methods declared in a meaningful context. * * It is a semantic error to apply this annotation to other fields or methods, including: * <ul> * <li>fields or methods in a class that is not {@code Serializable} * * <li>fields or methods of the proper structural declaration, but in * a type where they are ineffectual. For example, {@code enum} types * are defined to have a {@code serialVersionUID} of {@code 0L} so a * {@code serialVersionUID} field declared in an {@code enum} type is * ignored. The five serialization-related methods identified above * are likewise ignored for an {@code enum} type. * * </ul> */ @Target({ElementType.METHOD, ElementType.FIELD}) @Retention(RetentionPolicy.SOURCE) public @interface Serial { }

4 11

Add x-IBM-1129 charset
by Nasser Ebrahim 03 Aug '18

03 Aug '18

Hello, With the following three bugs, all the default locale charsets except two (Vi_VN.IBM-1129 & ja_JP.IBM-eucJP) are fixed for AIX platform. - JDK-8201540: [AIX] Extend the set of supported charsets in java.base - JDK-8202329: Codepage mappings for IBM-943 and Big5 (aix) - http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html : [AIX] Add charset IBM-964 (default charset for zh_TW.IBM-eucTW) to stdcs [bug not yet opened]. For those fixed charsets, the charsets were existing in the extended charsets (jdk.charsets) and they were not working with default locale charset as it did not exist in the standard charset (java.base). The charsets correspond to the two pending locale (Vi_VN.IBM-1129 & ja_JP.IBM-eucJP) does not exist in the jdk. They need to be added to the extended charsets before adding to stdcs on AIX platform. Here, am including the patch to fix the charset IBM-1129 for the locale Vi_VN.IBM-1129. We are working on the other missing charset (for ja_JP.IBM-eucJP) which will be contributed in some time. The webrev of the fix is available at http://cr.openjdk.java.net/~aleonard/IBM1129/webrev.00/ Kindly request you to open a bug and review the fix. Please let me know if you have any questions. Thank you, Nasser Ebrahim

3 4

Draft JEP proposal: JDK-8200758: Packaging Tool
by Kevin Rushforth 27 Jul '18

27 Jul '18

I would like to propose the following Draft JEP [1] for discussion. JDK-8200758: Packaging Tool This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX. Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758

9 12

Re: Add x-IBM-1129 charset
by Nasser Ebrahim 26 Jul '18

26 Jul '18

Hello, I just realized that I missed to provide the details of the test I have conducted for the new charset IBM-1129. Please note that I have done the following jtreg tests to make sure the new charset is working properly. sun.nio.cs.TestCharsetMapping java.nio.charset.Charset.RegisteredCharsets sun.nio.cs.CheckHistoricalNamesTest java.nio.charset.RemovingSunIO.SunioAlias Please let me know if I have to run any additional tests. Am aware of the suggestion from Alan and Thomas in the mail thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053316.html to move the IBM platform specific charsets to a separate module instead of adding to jdk.charsets. We will open another thread to discuss that topic as we would like to contribute many more extended charsets. However, I believe we can still consider integrating this charset without waiting for the conclusion of that discussion as this charset is part of default charset for AIX and needs to be part of the java.base. If we decided to move the IBM charsets out of jdk.charsets, we can move this charsets as well for non-AIX platforms. Kindly request you to open a bug/RFE for this change request, review the fix and provide your feedback. Thank you, Nasser Ebrahim From: Nasser Ebrahim/India/IBM To: core-libs-dev(a)openjdk.java.net Date: 05/19/2018 12:51 PM Subject: Add x-IBM-1129 charset Hello, With the following three bugs, all the default locale charsets except two (Vi_VN.IBM-1129 & ja_JP.IBM-eucJP) are fixed for AIX platform. - JDK-8201540: [AIX] Extend the set of supported charsets in java.base - JDK-8202329: Codepage mappings for IBM-943 and Big5 (aix) - http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html : [AIX] Add charset IBM-964 (default charset for zh_TW.IBM-eucTW) to stdcs [bug not yet opened]. For those fixed charsets, the charsets were existing in the extended charsets (jdk.charsets) and they were not working with default locale charset as it did not exist in the standard charset (java.base). The charsets correspond to the two pending locale (Vi_VN.IBM-1129 & ja_JP.IBM-eucJP) does not exist in the jdk. They need to be added to the extended charsets before adding to stdcs on AIX platform. Here, am including the patch to fix the charset IBM-1129 for the locale Vi_VN.IBM-1129. We are working on the other missing charset (for ja_JP.IBM-eucJP) which will be contributed in some time. The webrev of the fix is available at http://cr.openjdk.java.net/~aleonard/IBM1129/webrev.00/ Kindly request you to open a bug and review the fix. Please let me know if you have any questions. Thank you, Nasser Ebrahim

3 4

RFR 8198882: Add 10 JNDI tests to com/sun/jndi/dns/AttributeTests/
by Chris Yin 25 Jul '18

25 Jul '18

Please review the changes to add 10 JNDI tests to com/sun/jndi/dns/AttributeTests/, thanks bug: https://bugs.openjdk.java.net/browse/JDK-8198882 <https://bugs.openjdk.java.net/browse/JDK-8198882> webrev: http://cr.openjdk.java.net/~xyin/8198882/webrev.00/ <http://cr.openjdk.java.net/~xyin/8198882/webrev.00/> Regards, Chris

3 9