February 2019 - core-libs-dev

Method references in annotations
by Julian Ruppel 04 Apr '24

04 Apr '24

Hi, being aware that there has been a discussion quite some time ago ( http://mail.openjdk.java.net/pipermail/lambda-dev/2011-August/003768.html) I wanted to come up again with this topic as this feature would be beneficial especially for framework developers who wants to appoint behaviour to annotations. The following snippet shows what I want to vote for. @MyAnnotation(method = MyClass::myMethod)private String myVariable; This would be far more type-safe compared to using string literals to find the method via reflection. - Julian

2 2

RFR 8214761 : Bug in parallel Kahan summation implementation
by Ivan Gerasimov 03 Sep '20

03 Sep '20

Hello! DoubleSummaryStatistics takes advantage of Kahan summation algorithm to reduce the error of the total sum. Internally it maintains a field double sumCompensation, which keeps lower bits (which were rounded off) of the last addition. Note, that the compensation has to be subtracted from the result to add those bits back: 166 private void sumWithCompensation(double value) { 167 double tmp = value - sumCompensation; 168 double velvel = sum + tmp; // Little wolf of rounding error 169 sumCompensation = (velvel - sum) - tmp; 170 sum = velvel; 171 } At the line 169, tmp normally has more lower bits than (velvel - sum). However, when two DoubleSummaryStatistics objects are combined, this compensation part is *added* to the total, which may result in a less accurate result. The same bug is replicated in DoubleStreams. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8214761 WEBREV: http://cr.openjdk.java.net/~igerasim/8214761/00/webrev/ -- With kind regards, Ivan Gerasimov

3 4

RFC: JEP JDK-8208089: Implement C++14 Language Features
by Kim Barrett 04 Mar '20

04 Mar '20

I've submitted a JEP for (1) enabling the use of C++14 Language Features when building the JDK, (2) define a process for deciding and documenting which new features can be used or are forbidden in HotSpot code, (3) provide an initial list of permitted and forbidden new features. https://bugs.openjdk.java.net/browse/JDK-8208089

13 41

RE: RFR 8213031: (zipfs) Add support for POSIX file permissions
by Langer, Christoph 05 Aug '19

05 Aug '19

Hi, Ping. May I get reviews/substantial feedback on this zipfs enhancement? Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ Thanks Christoph From: Langer, Christoph Sent: Montag, 29. Oktober 2018 15:55 To: 'Alan Bateman' <Alan.Bateman(a)oracle.com>; core-libs-dev <core-libs-dev(a)openjdk.java.net>; security-dev(a)openjdk.java.net; Xueming Shen <xueming.shen(a)oracle.com> Cc: Volker Simonis <volker.simonis(a)gmail.com>; nio-dev <nio-dev(a)openjdk.java.net> Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) Hi Alan, security guys, I've proposed a CSR for this change now: https://bugs.openjdk.java.net/browse/JDK-8213082. I also updated the webrev, simplifying jdk.nio.zipfs.ZipUtils.permsFromFlags and eliminating the WeakHashMap: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ Since I've decoupled the changes to java.util.zip and jartool from those in jdk.zipfs, we're discussing only jdk.zipfs here. The implication of my change is that when working with files backed by the nio FileSystemProvider (java.nio.file.spi.FileSystemProvider) named "jar", which is the alias for zipfs, the files will support attributes of type java.nio.file.attribute.PosixFilePermissions ("posix:permissions"). It basically means that some methods of java.nio.file.Files that would return null or UnsupportedOperationException before would find an implementation now. Examples: https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/n… https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/n… https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/n… * With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/n… https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/n… * With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/n… Thanks in advance for reviewing. Best regards Christoph From: Alan Bateman <Alan.Bateman(a)oracle.com<mailto:Alan.Bateman@oracle.com>> Sent: Montag, 29. Oktober 2018 13:06 To: Langer, Christoph <christoph.langer(a)sap.com<mailto:christoph.langer@sap.com>>; core-libs-dev <core-libs-dev(a)openjdk.java.net<mailto:core-libs-dev@openjdk.java.net>>; security-dev(a)openjdk.java.net<mailto:security-dev@openjdk.java.net>; Xueming Shen <xueming.shen(a)oracle.com<mailto:xueming.shen@oracle.com>> Cc: Volker Simonis <volker.simonis(a)gmail.com<mailto:volker.simonis@gmail.com>>; Andrew Luo <andrewluotechnologies(a)outlook.com<mailto:andrewluotechnologies@outlook.com>>; nio-dev <nio-dev(a)openjdk.java.net<mailto:nio-dev@openjdk.java.net>> Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) On 29/10/2018 09:26, Langer, Christoph wrote: : As per request from Alan, I'm adding security-dev to get a review from security perspective. For security-dev then I think it would be better to write-up a summary of the overall proposal and the implications for applications/libraries that use the APIs and the jar tool. The security discussion points all relate to capture and propagation of file permissions. -Alan

5 57

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

RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.
by Lindenmaier, Goetz 09 May '19

09 May '19

Hi, since Java 5, our internal VM reports verbose null pointer exception messages. I would like to contribute this feature to OpenJDK. With this change, messages as "java.lang.NullPointerException: while trying to load from a null int array loaded from local variable 'ia1'" are printed. For more examples see the JBS bug or the test included. https://bugs.openjdk.java.net/browse/JDK-8218628 The messages are generated by parsing the bytecodes. For not to have any overhead when the NPE is allocated, the message is only generated when it is accessed by getMessage() or serialization. For this I added a field to NPE to indicate that the message still needs to be computed lazily. Please review: http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/01/ I'm happy to incorporate your comments. Best regards, Goetz

16 71

Feature suggestion: Allow generic wildcard in class literal expression
by some-java-user-99206970363698485155＠vodafonemail.de 22 Apr '19

22 Apr '19

JDK-6184881 describes that Object.getClass() should ideally not return classes of raw types anymore but instead use wildcards. The problem is that, as noted in the comments, this breaks compability with previously written code and therefore this change is not very likely (at the moment?). However, the report does not cover the class literal expression (https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.8.2) It would be good to allow the usage of the wildcard (`?`) for this expression: List<?>.class => Class<List<?>> Since it is currently not allowed to provide type parameters in the class literal expression there should not be any compatibility issues. Additionally if at some point JDK-6184881 is fixed for class literals as well, then the expression List<?>.class could just be a verbose variant of List.class without causing any problems either. This would make writing methods or constructors which determine a generic type based on a given class easier for generic classes, e.g.: public class MyContainer<T> { private final Class<T> valueClass; public MyContainer(Class<T> valueClass) { this.valueClass = valueClass; } public static void main(String[] args) { MyContainer<String> stringContainer = new MyContainer<>(String.class); // Have to use raw type (or verbose casting of class) MyContainer<List> listContainer = new MyContainer<>(List.class); // With suggested change: MyContainer<List<?>> listContainer = new MyContainer<>(List<?>.class); } }

1 1

RFR: 8215017: Improve String::equals warmup characteristics
by Claes Redestad 22 Apr '19

22 Apr '19

Hi, following up from discussions during review of JDK-8214971[1], I examined the startup and peak performance of a few different variant of writing String::equals. Webrev: http://cr.openjdk.java.net/~redestad/8215017/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215017 - folding coder() == aString.coder() into sameCoder(aString) helps interpreter without adversely affecting higher optimization levels - Jim's proposal to use Arrays.equals is _interesting_: it improves peak performance on some inputs but regress it on others. I'll defer that to a future RFE as it needs a more thorough examination. - what we can do is simplify to only use StringLatin1.equals. If I'm not completely mistaken these are all semantically neutral (and StringUTF16.equals effectively redundant). If I'm completely wrong here I'll welcome the learning opportunity. :-) This removes a branch and two method calls, and for UTF16 Strings we'll use a simpler algorithm early, which turns out to be beneficial during interpreter and C1 level. I added a simple microbenchmark to explore this, results show 1.2-2.5x improvements in interpreter performance, while remaining perfectly neutral results for optimized code on this simple micro[2]. This could be extended to clean up and move StringLatin1.equals back into String and remove StringUTF16, but we'd also need to rearrange the intrinsics on the VM side. Let me know what you think. Thanks! /Claes [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057162.h… [2] ========== Baseline ================= -Xint Benchmark Mode Cnt Score Error Units StringEquals.equalsAlmostEqual avgt 4 968.640 ± 1.337 ns/op StringEquals.equalsAlmostEqualUTF16 avgt 4 2082.007 ± 5.303 ns/op StringEquals.equalsDifferent avgt 4 583.166 ± 29.461 ns/op StringEquals.equalsDifferentCoders avgt 4 422.993 ± 1.291 ns/op StringEquals.equalsEqual avgt 4 988.671 ± 1.492 ns/op StringEquals.equalsEqualsUTF16 avgt 4 2103.060 ± 5.705 ns/op -XX:+CompactStrings Benchmark Mode Cnt Score Error Units StringEquals.equalsAlmostEqual avgt 4 23.896 ± 0.089 ns/op StringEquals.equalsAlmostEqualUTF16 avgt 4 23.935 ± 0.562 ns/op StringEquals.equalsDifferent avgt 4 15.086 ± 0.044 ns/op StringEquals.equalsDifferentCoders avgt 4 12.572 ± 0.008 ns/op StringEquals.equalsEqual avgt 4 25.143 ± 0.025 ns/op StringEquals.equalsEqualsUTF16 avgt 4 25.148 ± 0.021 ns/op -XX:-CompactStrings Benchmark Mode Cnt Score Error Units StringEquals.equalsAlmostEqual avgt 4 24.539 ± 0.127 ns/op StringEquals.equalsAlmostEqualUTF16 avgt 4 22.638 ± 0.047 ns/op StringEquals.equalsDifferent avgt 4 13.930 ± 0.835 ns/op StringEquals.equalsDifferentCoders avgt 4 13.836 ± 0.025 ns/op StringEquals.equalsEqual avgt 4 26.420 ± 0.020 ns/op StringEquals.equalsEqualsUTF16 avgt 4 23.889 ± 0.037 ns/op ========== Fix ====================== -Xint Benchmark Mode Cnt Score Error Units StringEquals.equalsAlmostEqual avgt 4 811.859 ± 8.663 ns/op StringEquals.equalsAlmostEqualUTF16 avgt 4 802.784 ± 352.884 ns/op StringEquals.equalsDifferent avgt 4 431.837 ± 1.884 ns/op StringEquals.equalsDifferentCoders avgt 4 358.244 ± 1.208 ns/op StringEquals.equalsEqual avgt 4 832.056 ± 3.541 ns/op StringEquals.equalsEqualsUTF16 avgt 4 832.434 ± 3.516 ns/op -XX:+CompactStrings Benchmark Mode Cnt Score Error Units StringEquals.equalsAlmostEqual avgt 4 23.906 ± 0.151 ns/op StringEquals.equalsAlmostEqualUTF16 avgt 4 23.905 ± 0.123 ns/op StringEquals.equalsDifferent avgt 4 15.088 ± 0.023 ns/op StringEquals.equalsDifferentCoders avgt 4 12.575 ± 0.030 ns/op StringEquals.equalsEqual avgt 4 25.149 ± 0.059 ns/op StringEquals.equalsEqualsUTF16 avgt 4 25.149 ± 0.033 ns/op -XX:-CompactStrings Benchmark Mode Cnt Score Error Units StringEquals.equalsAlmostEqual avgt 4 24.521 ± 0.050 ns/op StringEquals.equalsAlmostEqualUTF16 avgt 4 22.639 ± 0.035 ns/op StringEquals.equalsDifferent avgt 4 13.831 ± 0.020 ns/op StringEquals.equalsDifferentCoders avgt 4 13.884 ± 0.345 ns/op StringEquals.equalsEqual avgt 4 26.395 ± 0.066 ns/op StringEquals.equalsEqualsUTF16 avgt 4 23.904 ± 0.112 ns/op

5 9

RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields
by Adam Farley8 25 Mar '19

25 Mar '19

Hi All, I posit that you shouldn't be able to change the contents of a a final field. However, if you use Field.setAccessible(true) before calling Lookup.unreflectSetter(Field), then you can get a MethodHandle that allows you to set the (reflected) value of a static final field. This seems wrong to me, so here's a change to fix it. webrev: http://cr.openjdk.java.net/~afarley/8216558/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8216558 Opinions invited. Best Regards Adam Farley IBM Runtimes Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

6 50

RFR: 8214712: Archive Attributes$Name.KNOWN_NAMES
by Claes Redestad 16 Mar '19

16 Mar '19

Hi, initializing java.util.jar.Attributes.Name.<clinit> executes ~20k bytecodes setting up and eagerly calculating case-insensitive hash codes for a slew of Name objects. By archiving the resulting set of Names and initializing public constants from the archived map, we reduce time spent starting up (Name.<clinit> drops to 368 executed bytecodes) and improve the footprint sharing effect of using CDS: http://cr.openjdk.java.net/~redestad/8214712/jdk.00/ Testing: tier1-2 running Verified a 1-2.5ms startup improvement on java -jar Hello.jar - significant and stable reduction in instruction count, branches and branch misses - only adds ~1.1Kb to the dumped CDS archive Thanks! /Claes

7 18