November 2021 - core-libs-dev

RFR: 8277059: Use blessed modifier order in java.xml
by Magnus Ihse Bursie 15 Nov '21

15 Nov '21

I ran bin/blessed-modifier-order.sh on source code in java.xml and java.xml.crypto. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound. ------------- Commit messages: - 8277059: Use blessed modifier order in java.xml Changes: https://git.openjdk.java.net/jdk/pull/6369/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6369&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277059 Stats: 505 lines in 140 files changed: 0 ins; 0 del; 505 mod Patch: https://git.openjdk.java.net/jdk/pull/6369.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6369/head:pull/6369 PR: https://git.openjdk.java.net/jdk/pull/6369

2 3

RFR (CSR): 8202555: Double.toString(double) sometimes produces incorrect results
by Raffaello Giulietti 15 Nov '21

15 Nov '21

Hello, PR [1] and the accompanying article [2] have been subject to some positive reactions in the last couple of weeks. A fresh set of about 20 thousand additional hard test cases kindly provided by Paul Zimmermann of INRIA and other tests proposed by Guy Steele have been added to the code. The corresponding CSR [3] is in Finalized state for review. The proposed spec has been carefully written to uniquely define the outcomes and the code in the PR has been extensively tested to match the proposed spec. Behavioral backward compatibility has been a major goal for the CSR. In fact, in the vast majority of cases, the CSR and the current implementation agree on the outcomes. As the CSR is a prerequisite for the advancement of the PR, I beg everybody entitled (and interested) to review and approve it and/or discuss it further. Greetings Raffaello ---- [1] https://github.com/openjdk/jdk/pull/3402 [2] https://drive.google.com/file/d/1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN/view [3] https://bugs.openjdk.java.net/browse/JDK-8202555

1 1

EmptyStream to boost performance
by Dr Heinz M. Kabutz 13 Nov '21

13 Nov '21

Good evening, a couple of months ago a fellow Java Champion told me that he had "banned" streams at his company, or at least discouraged their use. The reason was their high allocation rates with empty collections. With traditional for loops, if the collection is empty, then hardly any objects are allocated and it is very fast. But if we have a stream, then we first have to build up the entire pipeline, only to discover that we didn't need all those objects and throw them away again. When communicating with Brian Goetz last week, I mentioned this to him and he suggested that perhaps we could have the stream() method inside Collection check whether it is empty, and if so, to return a specialized class EmptyStream that returns "this" for methods such as filter() and map(). I spent a bit of time trying to write such a class, together with EmptyIntStream, EmptyLongStream and EmptyDoubleStream. I've also written a set of tests that compare our Empty[Int|Long|Double]Streams to what would be returned with Stream[Int|Long|Double].empty(). I've also written a little benchmark to demonstrate its effectiveness. You can see what I've done here: https://github.com/openjdk/jdk/pull/6275 (I think I was premature in issuing the PR) However, I have hit a brick wall with the way that the streams are currently being tested in the JDK. First off, there are several tests that make assumptions about how Stream is implemented and down-casts it to an AbstractPipeline. Since our EmptyStream is not an AbstractPipeline, the tests fail. Secondly, with a normal stream, some of the methods can only be called once, for example filter() and map(). They return a new stream and we have to continue working with those. With my EmptyStream, since filter() and map() return "this", we would not get an exception if we continued using it. Thirdly, with a normal stream, the method parallel() changes the state of the current stream, but then returns "this". In order to keep the EmptyStream consistent with the current Stream.empty() behavior, I return StreamSupport.stream(Spliterators.emptySpliterator(), true) from the parallel() method. Thus with the EmptyStream this is opposite to how it currently happens to work. The Javadocs say that the parallel() method "may return itself", but it does not have to, whereas the filter() method seems to suggest that it would be a new stream objects, but it also does not prescribe that it absolutely has to be. How important is the white-box testing with the streams? And could we perhaps make special cases for empty streams? Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java™ Specialists' Newsletter" - www.javaspecialists.eu Java Champion - www.javachampions.org JavaOne Rock Star Speaker Tel: +30 69 75 595 262 Skype: kabutz

1 1

RFR: 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File
by Lance Andersen 12 Nov '21

12 Nov '21

Hi all, This patch addresses a regression introduced in JDK 15 via JDK-8242959 where you can no longer access a file entry contained within a Zip file when there is also a directory entry with the same name via ZipFile:getEntry(). Once fixed, the behavior will be consistent with earlier JDK releases. Mach5 tiers 1-3 have been run without failure Best Lance ------------- Commit messages: - Address javadoc typo - Fix for JDK-8276123 Changes: https://git.openjdk.java.net/jdk/pull/6342/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6342&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276123 Stats: 598 lines in 2 files changed: 593 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6342.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6342/head:pull/6342 PR: https://git.openjdk.java.net/jdk/pull/6342

4 13

RFR: 8274835: Remove unnecessary castings in java.base
by Andrey Turbanov 12 Nov '21

12 Nov '21

Redundant castings make code harder to read. Found them by IntelliJ IDEA. I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts. ------------- Commit messages: - [PATCH] Remove unnecessary castings in java.base - [PATCH] Remove unnecessary castings in java.base Changes: https://git.openjdk.java.net/jdk/pull/5454/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5454&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274835 Stats: 38 lines in 15 files changed: 1 ins; 4 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5454.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5454/head:pull/5454 PR: https://git.openjdk.java.net/jdk/pull/5454

8 7

Always false condition in jdk.internal.jrtfs.JrtFileSystem#getPathMatcher
by Andrey Turbanov 12 Nov '21

12 Nov '21

Hello. I found suspicious condition in implementation of method JrtFileSystem.getPathMatcher(String) https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/… public PathMatcher getPathMatcher(String syntaxAndInput) { int pos = syntaxAndInput.indexOf(':'); if (pos <= 0 || pos == syntaxAndInput.length()) { throw new IllegalArgumentException("pos is " + pos); } Variable pos is a result of String.indexOf(char) call. It is compared with the length() of the same String. This condition 'pos == syntaxAndInput.length()' will always be false: String.indexOf() can't return any value greater than length()-1. Perhaps it was intended to be 'pos == syntaxAndInput.length() - 1'? BTW, I think exception message could be improved. Current message 'pos is -1' is not user friendly. Andrey Turbanov

1 0

JEP 416: Missing throws IllegalArgumentException declaration for Method::invoke?
by Marc Hoffmann 12 Nov '21

12 Nov '21

Hi, with the implementation of JEP 416 (https://github.com/openjdk/jdk/commit/c6339cb8a255d387bb182ad20dd69f3d460cf… <https://github.com/openjdk/jdk/commit/c6339cb8a255d387bb182ad20dd69f3d460cf…>) the throws declaration for IllegalArgumentException on Method::invoke was removed — while it is still described in JavaDoc. Was this on purpose? Sorry if this was discussed before, but I was not able to find a review discussion around this commit. Also I’m not sure what the policy is whether unchecked exceptions should be declared if mentioned in JavaDoc. Best regards, -marc

2 2

RFR: 8275197: Remove unused fields in ThaiBuddhistChronology
by Andrey Turbanov 11 Nov '21

11 Nov '21

Remove 3 unused HashMap's. Reported here https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866… I did the similar PR to treetenbp and it was merged https://github.com/ThreeTen/threetenbp/pull/155 ------------- Commit messages: - [PATCH] Remove unused fields in ThaiBuddhistChronology Changes: https://git.openjdk.java.net/jdk/pull/5917/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5917&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275197 Stats: 37 lines in 1 file changed: 0 ins; 36 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5917.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5917/head:pull/5917 PR: https://git.openjdk.java.net/jdk/pull/5917

4 4

RFR: 8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges
by Claes Redestad 11 Nov '21

11 Nov '21

This changes the specification of `DateTimeFormatterBuilder.appendFraction` to more clearly specify that the formatter will throw an exception if you attempt to print a value outside of the value range of the given field. Changes suggested by @jodastephen in #6188. ------------- Commit messages: - Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges Changes: https://git.openjdk.java.net/jdk/pull/6335/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6335&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276947 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6335.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6335/head:pull/6335 PR: https://git.openjdk.java.net/jdk/pull/6335

3 4

RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI
by Aleksei Efimov 11 Nov '21

11 Nov '21

This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver. The following API classes are added to `java.net.spi` package to facilitate this: - `InetAddressResolverProvider` - abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers. - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations. - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations. - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation. More details in [JEP-418](https://openjdk.java.net/jeps/418). Testing: new and existing `tier1:tier3` tests ------------- Commit messages: - 8244202: Implementation of JEP 418: Internet-Address Resolution SPI Changes: https://git.openjdk.java.net/jdk/pull/5822/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244202 Stats: 2779 lines in 50 files changed: 2524 ins; 134 del; 121 mod Patch: https://git.openjdk.java.net/jdk/pull/5822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822 PR: https://git.openjdk.java.net/jdk/pull/5822

6 48