June 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

RFR: 8148188: Enhance the security libraries to record events of interest
by Seán Coffey 16 Nov '18

16 Nov '18

Following on from the recent JDK-8203629 code review, I'd like to propose enhancements on how we can record events in security libs. The introduction of the JFR libraries can give us much better ways of examining JDK actions. For the initial phase, I'm looking to enhance some key security library events in JDK 11 so that they can be either recorded to JFR, logged to a traditional logger, or both. Examples of how useful JFR recordings could be can be seen here : http://cr.openjdk.java.net/~coffeys/event_snaps/X509Event_1.png http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_1.png http://cr.openjdk.java.net/~coffeys/event_snaps/securityProp_2.png http://cr.openjdk.java.net/~coffeys/event_snaps/TLSEvent_1.png securityProp_2.png gives an example of how the JFR recording can be queried to quickly locate events of interest (in this case, code setting the jdk.tls.* Security properties). I still need to clean up the TLSEvents testcase to improve test coverage and hope to do that in coming days. JBS record : * https://bugs.openjdk.java.net/browse/JDK-8148188 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v1/webrev/ -- Regards, Sean.

5 31

RFR: 8203629: Produce events in the JDK without a dependency on jdk.jfr
by Erik Gahlin 30 Oct '18

30 Oct '18

Hi, Could I have a review of an enhancement that will make it possible to add JFR events to java.base, and possibly other modules in the JDK, without a compile time dependency on jdk.jfr. Bug: https://bugs.openjdk.java.net/browse/JDK-8203629 Webrev: http://cr.openjdk.java.net/~egahlin/8203629.0 Testing: Tests in test/jdk/jdk/jfr The functionality is a prerequisite for an upcoming enhancement that will add JFR events to the security libraries. In short, jdk.jfr.Event (located in jdk.jfr) extends jdk.internal.event.Event (located in java.base). Metadata for events, such as labels and descriptions, are added using a mirror event class located in jdk.jfr module. If the fields of the mirror class and the event class don't match an InternalError is thrown. To illustrate how the mechanism can be used, see the following example (not meant to be checked in). http://cr.openjdk.java.net/~egahlin/8203629.example Since the implementation of jdk.internal.event.Event is empty, the JIT will typically eliminate all traces of JFR functionality unless Flight Recorder is enabled. Thanks Erik

4 11

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

RFR: JDK-8205461 Create Collector which merges results of two other collectors
by Tagir Valeev 25 Sep '18

25 Sep '18

Please review and sponsor: https://bugs.openjdk.java.net/browse/JDK-8205461 http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r1/ See also previous discussion thread at [1]. It seems that we did not reach the final conclusion about the collector name, so in this review it's still named as "pairing" (proposed by me). Other name proposals: bisecting - by Paul Sandoz (sounds like input is split by two parts like in partitioningBy, which is not the case) tee or teeing - by Brian Goetz (IIUC from the T shape, it's assymmetrical operation, while our collector is symmetrical) duplex(ing) - by Jacob Glickman (well, probably ok?) bifurcate - by James Laskey (or bifurcating?) replicator - by James Laskey (as in DNA) replicating - by Peter Levart fanout or fanningOut - Chris Hegarty (sounds cryptic to me, checked Wikipedia [2], does not look like suitable) distributing - by Brian Goetz (like in distributive law a(b+c) = ab+ac; but common meaning of "distributing" is different) tapping - by Kirk Pepperdine (I have no associations; Google images shows some acupuncture procedures) split - by Kirk Pepperdine (may be confused with Spliterator) unzipping - by John Rose biMapping - by Zheka Kozlov (but he also suggests to change signature which is unnecessary) toBoth - by Peter Levart (but usually toXyz shows target container like toArray/toList/toSet, but there's not "Both" container) collectionToBothAndThen - by Zheka Kozlov (but too long) collectingToBoth - by Zheka Kozlov collectingTo - by Brian Goetz (isn't collect(collectingTo(...)) a little bit repititive?) biCollecting - by Zheka Kozlov expanding - by Paul Sandoz (doesn't sound very descriptive to me) forking - by Victor Williams Stafusa da Silva (could be thought that something is parallelized as forking is usually something connected to parallel computations) I think that it's better to concentrate not on the "splitting" part (each element is passed to two collectors), but on the "joining" part (results of two collectors are combined together). So my preference now is "merging" or "combining". If limiting the selection to the suggested options I'd prefer "duplexing" or "bifurcating" or to stay with my original version "pairing". Of course original Stream API author voices have more weight here, so if you insist on particular version, I will follow. By the way looking into CollectorsTest.java I found some minor things to cleanup: 1. `.map(mapper::apply)` and `.flatMap(mapper::apply)` can be replaced with simple `.map(mapper)` and `.flatMap(mapper)` respectively 2. In many methods redundant `throws ReflectiveOperationException` is declared while exception is never thrown 3. The `if (!Map.class.isAssignableFrom(map.getClass()))` looks useless as `map` is already of `Map<Boolean, D>` type, so this check is always false (we would never enter this method if it's true). Similarly `if (!List.class.isAssignableFrom(value.getClass()))` 4. Deprecated `clazz.newInstance()` is used 5. Test named `testGroupubgByWithReducing` should be renamed to `testGroupingByWithReducing` Should I fix some or all of these issues? As separate changeset or within this one? With best regards, Tagir Valeev. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053718.html [2] https://en.wikipedia.org/wiki/Fan-out

8 29

[RFR] 8205525 : Improve exception messages during manifest parsing of jar archives
by Baesken, Matthias 12 Sep '18

12 Sep '18

Hello, please review this small change that improve exception messages during manifest parsing of jar archives . Thanks, Matthias Bug : https://bugs.openjdk.java.net/browse/JDK-8205525 Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8205525/

9 73

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