May 2021 - core-libs-dev

RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException
by Alexander Matveev 21 May '21

21 May '21

For debug build on macOS, runtime which used for test fill be located in /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files except fastdebug and in this case our check to decide if we need to copy app or runtime will return /path/jdk-17 which is not correct. Fixed by skipping this check for runtime and only using it for app. Also, added ignoring .DS_Store to test which is needed if user used Finder to look inside runtime folder which will cause .DS_Store to be created and will cause test to fail, since this file is not being packaged. ------------- Commit messages: - 8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException Changes: https://git.openjdk.java.net/jdk/pull/4120/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4120&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267056 Stats: 15 lines in 2 files changed: 5 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4120.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4120/head:pull/4120 PR: https://git.openjdk.java.net/jdk/pull/4120

3 6

Re: Suppressed IllegalAccessException in MethodHandle.setVarargs
by Mandy Chung 20 May '21

20 May '21

This seems a good improvement. I created https://bugs.openjdk.java.net/browse/JDK-8267509 for this issue. How did you run into this illegal varargs method? Is that class file generated at runtime? Mandy On 5/20/21 10:18 AM, x4e_x4e wrote: > Hello, > > If a MethodHandles.Lookup is used to locate a MethodHandle for a varargs method who's final parameter is not an array an IllegalArgumentException will be thrown: > >> java.lang.IllegalArgumentException: not an array type: int >> at java.base/java.lang.invoke.MethodHandleStatics.newIllegalArgumentException(MethodHandleStatics.java:138) >> at java.base/java.lang.invoke.MethodHandle.spreadArrayChecks(MethodHandle.java:1066) >> at java.base/java.lang.invoke.MethodHandle.asCollectorChecks(MethodHandle.java:1259) >> at java.base/java.lang.invoke.MethodHandle.asVarargsCollector(MethodHandle.java:1427) >> at java.base/java.lang.invoke.MethodHandle.withVarargs(MethodHandle.java:1111) >> at java.base/java.lang.invoke.MethodHandle.setVarargs(MethodHandle.java:1634) >> at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:3755) >> at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:3691) >> at java.base/java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:2399) > This makes sense, however it seems that the exception is swallowed and instead a generic IllegalAccessException is thrown: > >> Caused by: java.lang.IllegalAccessException: cannot make variable arity: package.Class.method(Object[],int)Object/invokeStatic >> at java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:957) >> at java.base/java.lang.invoke.MethodHandle.setVarargs(MethodHandle.java:1636) >> at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:3755) >> at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:3691) >> at java.base/java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:2399) > It would probably be helpful to make the IllegalAccessException caused by the IllegalArgumentException, or at the very least add it as a suppressed exception. > Otherwise the only way to find the helpful exception here is through runtime debugging. > > Relevant code: https://github.com/openjdk/jdk/blob/7b98400c81900a8c779394d549b5fb61f1dd863… > > Thanks, > x4e

1 0

Make java.lang.constant.ConstantDesc selead
by Thiago Henrique Hupner 20 May '21

20 May '21

Now that Sealed classes are integrated, should be the moment to seal the ConstantDesc class and its subclasses, or would be better to wait a little bit more? Best regards Thiago

1 0

RFR: 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates
by Martin Buchholz 20 May '21

20 May '21

8246677: LinkedTransferQueue and SynchronousQueue synchronization updates ------------- Commit messages: - JDK-8246677 Changes: https://git.openjdk.java.net/jdk/pull/1645/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1645&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246677 Stats: 538 lines in 3 files changed: 143 ins; 294 del; 101 mod Patch: https://git.openjdk.java.net/jdk/pull/1645.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1645/head:pull/1645 PR: https://git.openjdk.java.net/jdk/pull/1645

4 5

RFR: 8261880: Change nested classes in java.base to static nested classes where possible
by Сергей Цыпанов 20 May '21

20 May '21

Non-static classes hold a link to their parent classes, which in many cases can be avoided. ------------- Commit messages: - 8261880: Change nested classes in java.base to static nested classes where possible Changes: https://git.openjdk.java.net/jdk/pull/2589/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2589&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261880 Stats: 20 lines in 16 files changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/2589.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2589/head:pull/2589 PR: https://git.openjdk.java.net/jdk/pull/2589

7 14

RFR: 8260517: implement Sealed Classes as a standard feature
by Vicente Romero 20 May '21

20 May '21

Please review this PR that intents to make sealed classes a final feature in Java. This PR contains compiler and VM changes. In line with similar PRs, which has made preview features final, this one is mostly removing preview related comments from APIs plus options in test cases. Thanks ------------- Commit messages: - Merge branch 'master' into JDK-8260517 - Merge branch 'master' into JDK-8260517 - fixing failing regression tests - JVM related changes - 8260517: Compiler implementation for Sealed Classes Changes: https://git.openjdk.java.net/jdk/pull/3526/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3526&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260517 Stats: 450 lines in 56 files changed: 48 ins; 282 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/3526.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3526/head:pull/3526 PR: https://git.openjdk.java.net/jdk/pull/3526

4 13

JEP draft: Scope Locals
by Andrew Haley 20 May '21

20 May '21

There's been considerable discussion about scope locals on the loom-dev list, and it's now time to open this to a wider audience. This subject is important because. although scope locals were motivated by the the needs of Loom, they have many potential applications outside that project. The draft JEP is at https://bugs.openjdk.java.net/browse/JDK-8263012 I've already received some very helpful suggestions for enhancements to the API, and it'll take me a while to work through them all. In particular, Paul Sandoz has suggested that I unify the classes Snapshot and Carrier, and it will take me some time to understand the consequences of that. In the meantime, please have a look at the JEP and comment here. For reference, earlier discussions are at https://mail.openjdk.java.net/pipermail/loom-dev/2021-March/002268.html https://mail.openjdk.java.net/pipermail/loom-dev/2021-April/002287.html https://mail.openjdk.java.net/pipermail/loom-dev/2021-May/002427.html -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

7 19

ReversibleCollection proposal
by Stuart Marks 20 May '21

20 May '21

This is a proposal to add a ReversibleCollection interface to the Collections Framework. I'm looking for comments on overall design before I work on detailed specifications and tests. Please send such comments as replies on this email thread. Here's a link to a draft PR that contains the code diffs. It's prototype quality, but it should be good enough to build and try out: https://github.com/openjdk/jdk/pull/3533 And here's a link to a class diagram showing the proposed additions: https://cr.openjdk.java.net/~smarks/ReversibleCollection/ReversibleCollecti… Thanks, s'marks # Ordering and Reversibility A long-standing concept that's been missing from collections is that of the positioning, sequencing, or arrangement of elements as a structural property of a collection. (This is sometimes called the "iteration order" of a collection.) For example, a HashSet is not ordered, but a List is. This concept is mostly not manifested in the collections API. Iterating a collection produces elements one after another in *some* sequence. The concept of "ordered" determines whether this sequence is defined or whether it's a coincidence of implementation. What does "having an order" mean? It implies that there is a first element and that each element has a successor. Since collections have a finite number of elements, it further implies that there is a last element that has no successor. However, it is difficult to discern whether a collection has a defined order. HashSet generally iterates its elements in the same undefined order, and you can't actually tell that it's not a defined order. Streams do have a notion of ordering ("encounter order") and this is preserved, where appropriate, through the stream pipeline. It's possible to detect this by testing whether its spliterator has the ORDERED characteristic. Any collection with a defined order will have a spliterator with this characteristic. However, this is quite a roundabout way to determine whether a collection has a defined order. Furthermore, knowing this doesn't enable any additional operations. It only provides constraints on the stream's implementations (keeping the elements in order) and provides stronger semantics for certain operations. For example, findFirst() on an unordered stream is the same as findAny(), but actually finds the first element if the stream is ordered. The concept of ordering is thus present in the system but is surfaced only in a fairly indirect way. We can strengthen abstraction of ordering by making a few observations and considering their implications. Given that there is a first element and a last element, the sequence of elements has two ends. It's reasonable to consider operations (add, get, remove) on either end. Indeed, the Deque interface has a full complement of operations at each end. This is an oft-requested feature on various other collections. Each element except for the last has a successor, implying that each element except for the first has a predecessor. Thus it's reasonable to consider iterating the elements from first to last or from last to first (that is, in forward or reverse order). Indeed, the concept of iterating in reverse order appears already in bits and pieces in particular places around the collections: - List has indexOf() and lastIndexOf() - Deque has removeFirstOccurrence() and removeLastOccurrence() - List has a ListIterator with hasPrevious/previous methods - Deque and NavigableSet have descendingIterator methods Given an ordered collection, though, there's no general way to iterate it in reverse order. Reversed iteration isn't the most common operation, but there are some frequent use cases, such as operating on elements in most-recently-added order. Questions and bug reports about this have come up repeatedly over the years. Unfortunately, iterating in reverse order is much harder than iterating in forward order. There are a variety of ways to iterate in forward order. For example, given a List, one can do any of the following: for (var e : list) { ... } list.forEach(...) list.stream() list.toArray() However, to iterate a list in reverse order, one must use an explicit loop over ListIterator: for (var it = list.listIterator(list.size()); it.hasPrevious(); ) { var e = it.previous(); ... } Streaming the elements of a List in reverse order is even worse. One approach would be to implement a reverse-ordered Iterator that wraps a ListIterator and delegates hasNext/next calls to the ListIterator's hasPrevious/previous methods. Then, this Iterator can be turned into a Spliterator, which is then turned into a Stream. (The code to do this is left as an exercise for the reader.) Obtaining the elements in reverse via other means -- forEach() or toArray() -- is similarly difficult. Obtaining the elements in reverse order can be accomplished by adopting a concept from NavigableSet's descendingSet() method, which provides a reverse-ordered view collection. This view is also a NavigableSet, which means that any operation that can be performed on the original set can also be applied to the reverse-ordered view. If it were possible to obtain a similar reverse-ordered view on any kind of ordered collection, this would enable the elements to be processed in reverse order in any fashion, not just special-purposes APIs such as ListIterator or descendingIterator(). # LinkedHashSet The main feature of LinkedHashSet is that it does have a defined ordering, as opposed to HashSet, which does not. LinkedHashSet clearly has a first and a last element. However, LinkedHashSet is deficient in a number of ways: - access to and removal of the first element is reasonable (using an iterator) but it is not possible to add at the front - it is possible to add an element at the end, but access to and removal of the last element are expensive - it's not possible to iterate in reverse without copying the entire collection Most frustratingly, LinkedHashSet is implemented using a doubly-linked list, so there is no fundamental implementation reason that prevents these operations from being supported. The main reason these operations aren't supported is probably that there hasn't been a good place to push such APIs. # Proposal Introduce a new ReversibleCollection<E> interface. This provides a new method to obtain a reverse-ordered view. It also contains several methods (copied from Deque) that allow operating on elements at both ends. interface ReversibleCollection<E> extends Collection<E> { ReversibleCollection<E> reversed(); default void addFirst(E e) default void addLast(E e) default E getFirst() default E getLast() default E removeFirst() default E removeLast() } The List, Deque, and SortedSet interfaces, and the LinkedHashSet class are retrofitted to implement ReversibleCollection. They provide covariant overriding implementations of the reversed() method. For example, List.reversed() returns a List. Default implementations for all of these methods are provided in the appropriate interfaces. Covariant overrides are also provided in several other classes. This presents a difficulty for LinkedHashSet, as there's no suitable return type for reversed(). To remedy this, we add another interface interface ReversibleSet<E> extends ReversibleCollection<E>, Set<E> { } This adds no new methods but is essentially an intersection of ReversibleCollection and Set. As such, it's suitable as the return type of LinkedHashSet.reversed() and the set views of LinkedHashMap. SortedSet::addFirst and addLast throw UnsupportedOperationException. This is because SortedSet's ordering is determined by the comparison method and cannot be controlled explicitly. LinkedHashSet::addFirst and addLast add the element at the appropriate position or reposition the element if it is already present in the set. New methods are added to LinkedHashMap V putFirst(K, V) V putLast(K, V) which put the mapping at the designated position or reposition the mapping if is already present in the map. # Design & Implementation Issues Covariant overrides for reversed() are provided where possible. However, there is a conflict between List and Deque, as there are examples in the JDK (such as LinkedList) that implement both List and Deque. Since List is much more popular than Deque, I've decided against adding a covariant override to Deque. Instead, a method Deque::reversedDeque is added that returns a Deque, and Deque::reversed returns ReversibleCollection. There is no ReversibleMap interface. Most iteration over maps is over the entrySet, keySet, or values views. NavigableMap already has descendingMap(), and LinkedHashMap provides ReversibleX views, which cover most of the cases already. Introducing new methods into an interface hierarchy always raises the possibility of name clashes. I've done some searching but I haven't found any major issues, but we should be on the lookout for this. I'll continue to do more searching for such conflicts. Introducing covariant overrides on existing methods (notably LinkedHashMap entrySet, keySet, and values) could present incompatibility issues with subclasses that override these methods. I've done some searching and again I haven't found major problems, but this is nonetheless a point of concern. I'll do more searching here, too. The default implementations for List::reversed, Deque::reversed, and SortedSet::reversed return reverse-ordered views that are implemented using only public methods of the original interface. This demonstrates the feasibility of retrofitting reverse ordering onto any instance of these interfaces. Similarly, the various add/get/remove methods' default implementations are all implementable in terms of an iterator or reverse-ordered iterator. That said, some concurrent collection implementations will need to override these default implementations in order to preserve their safety invariants. It would probably also be wise to add optimized implementations to the more commonly-used collection implementations. Given that a ReversibleCollection has a defined ordering, any spliterator obtained from such a collection should have the Spliterator.ORDERED characteristic. This proposal is related to a previous discussion on a similar topic, where Tagir Valeev had proposed OrderedSet and OrderedMap: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066028.html I think there were some good ideas in there and in the ensuing discussion, but it didn't go anywhere. Several of the concepts in this proposal are an evolution of some ideas discussed in that thread. One of the ideas from that thread was to use Deque as a common interface for many collections to support reversibility and operations at the ends. We've abandoned that idea in this proposal. The reasons are that it's cluttered with a bunch of methods that are inherited from Queue. Also, some methods are null-returning instead of throwing, which introduces confusion for collections that can contain nulls. # END

12 75

RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
by PROgrm_JARvis 19 May '21

19 May '21

Please review this change moving lookup of MD5 digest in `java.lang.UUID` to an internal holder class. ------------- Commit messages: - 8258588: MD5 MessageDigest in java.util.UUID should be cached Changes: https://git.openjdk.java.net/jdk/pull/1821/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1821&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258588 Stats: 33 lines in 1 file changed: 26 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1821.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1821/head:pull/1821 PR: https://git.openjdk.java.net/jdk/pull/1821

7 28

jpackage java commands
by Michael Hall 19 May '21

19 May '21

I added --jlink-options '--strip-debug --no-man-pages --no-header-files’ to my invocation, avoiding --strip-native-commands, so that the native java commands are not stripped. I believe currently recommended jpackage way to do this. I get the following commands in my embedded JDK java jdb jshell rmid serialver javac jrunscript keytool rmiregistry The installed jdk bin directory has 29 different commands including ones like jpackage, jlink, javap, jcmd… What if I want to run one of those from the application? I can exec them but the version might not match the embedded? Not a current problem that I know of, I will use the installed for now.

2 2