July 2020 - 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

Re: [jpackage] Issue with upgrading from javapackager to jpackage on Windows
by James Elliott 29 Oct '20

29 Oct '20

Sorry, tried sending this with the incorrect email personality first. On Mon, 17 Feb 2020 15:32:14 +0100 Daniel Peintner <daniel.peintner(a)gmail.com <mailto:daniel.peintner@gmail.com>> wrote: > The only *working* solution we found was to *manually* uninstall the old > application before starting msi installer. > Any future update with msi installers work fine. But the first update fails! I had been previously manually creating WiX installers (with the help of a script built by one of my Windows-based users), and he discovered the same problem when I migrated to jpackage. It turns out that the jpackage-built WiX installers are missing an upgrade ID. I mentioned that on this list a few weeks ago, but there was not any interest in investigating the issue. So now I use jpackage to just create the application image, and then separately use WiX directly to create an installer that can properly upgrade older installations. You can find the GitHub Actions workflow that drives the process here: https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/work… <https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/work…> The PowerShell script that runs jpackage and WiX is here: https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scri… <https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scri…> And the WIX template it uses is here: https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/reso… <https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/reso…> Hopefully this can help you, and perhaps jpackage can be updated to do this on its own as well. Cheers, -James

4 8

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

RFR(L) 8244778 Archive full module graph in CDS
by Ioi Lam 03 Sep '20

03 Sep '20

https://bugs.openjdk.java.net/browse/JDK-8244778 http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v… Please review this patch that stores the full module graph in the CDS archive heap. This reduces the initialization time of the basic JVM by about 22%: $ perf stat -r 100 bin/java -version before: 98,219,329 instructions 0.03971 secs elapsed (+- 0.44%) after: 55,835,815 instructions 0.03109 secs elapsed (+- 0.65%) [1] Start with ModuleBootstrap.java. The current implementation is quite restrictive: the archived module graph is used only when no module options are specified. See ModuleBootstrap.mayUseArchivedBootLayer(). We can probably support options such as main module and module path in a future RFE. [2] In the current JDK implementation, there is no single object that represents "the module graph". Most of the information is stored in the archive bootLayer object, but a few additional restoration operations need to be performed: + See ModuleBootstrap.getArchivedBootLayer() + Some static fields need to be archived/restored in Module.java, BuiltinClassLoader.java, ClassLoaders.java and BootLoader.java [3] I ran into a complication with two loader instances of PlatformClassLoader and AppClassLoader. They are stored in multiple tables inside the module graph (e.g., BuiltinClassLoader$LoadedModule) so I cannot easily recreate them at runtime. However, these two loaders contain information specific to the dump time VM lifecycle (such as the classes that were loaded during CDS dumping) that need to be scrubbed. I couldn't find an elegant way of doing this, so I added a private "resetArchivedStates" method to a few classes. They are called inside HeapShared::reset_archived_object_states(). [4] Related native data structures (PackageEntry and ModuleEntry) are also archived. Start with classLoaderData.cpp Passes mach5 tiers 1-4. I will test with additional tiers. Thanks - Ioi

4 7

RFR: 8188055: (ref) Add Reference.refersTo predicate
by Kim Barrett 02 Sep '20

02 Sep '20

[Note review on both core-libs and hotspot-gc-dev lists; try not to lose either when replying.] Please review a new function: java.lang.ref.Reference.refersTo. This function is needed to test the referent of a Reference object without artificially extending the lifetime of the referent object, as may happen when calling Reference.get. Some garbage collectors require extending the lifetime of a weak referent when accessed, in order to maintain collector invariants. Lifetime extension may occur with any collector when the Reference is a SoftReference, as calling get indicates recent access. This new function also allows testing the referent of a PhantomReference, which can't be accessed by calling get. The new function uses a native method whose implementation is in the VM so it can use the Access API. It is the intent that this function will be intrinsified by optimizing compilers like C2 or graal, but that hasn't been implemented yet. Bear that in mind before rushing off to change existing uses of Reference.get. CR: https://bugs.openjdk.java.net/browse/JDK-8188055 https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) Webrev: https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ Testing: mach5 tier1 Locally (linux-x64) verified the new test passes with various garbage collectors.

9 20

RFR: JDK-8242451 : ensure semantics of non-capturing lambdas are preserved independent of execution mode
by Gilles Duboscq 26 Aug '20

26 Aug '20

In 8232806, a system property was introduce to disable eager initialization of the classes generated by the InnerClassLambdaMetafactory (`jdk.internal.lambda.disableEagerInitialization`). However, when `disableEagerInitialization` is true, even for non-capturing lambdas, the capturing lambda path that uses a method handle to the constructor is taken. This helps prevent eager initialization but also has the side effect of always returning a fresh instance of the lambda for every invocation instead of a singleton. While this is allowed by the specs, this might change the behaviour of some (incorrect) programs that assume a singleton is used for non-capturing lambdas. I propose to keep the effects of the `disableEagerInitialization` related to initialization only. Webrev: https://cr.openjdk.java.net/~gdub/8242451/webrev.0/ Issue: https://bugs.openjdk.java.net/browse/JDK-8242451 The concrete issue we are seeing with changing both aspects at the same time is that when disableEagerInitialization for static analysis in GraalVM's native-image, some programs start to miss-behave because of assumptions about the object identity of lambdas. Note that `disableEagerInitialization` is still ineffective in the following situations: * when `useImplMethodHandle` is true, i.e., when a MethodHanlde is used to call the target because the generated hidden class is missing the necessary access rights. (the implementation require setting a static field on the generated class which causes it to be initialized, Class Data could help in the future in that case) * for non-capturing lambdas when the caller (and generated) class is in the `java.lang.invoke` or `sun.invoke.util` package. (because `findStaticGetter` will eagerly initialize the holder class if it is from those packages, see DirectMethodHandle#shouldBeInitialized) Those are acceptable rare corner cases. Thanks, Gilles

3 8

Fix for Javadoc errors in java.base
by Vipin Sharma 19 Aug '20

19 Aug '20

Hi, This patch fixes Javadoc errors in java.base, please sponsor this patch and help to create a bug id for this. I have signed OCA, this is my third patch. --- old/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java 2020-07-25 23:46:21.233726447 +0530 +++ new/src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java 2020-07-25 23:46:20.721720857 +0530 @@ -96,8 +96,6 @@ * @param p the prime modulus * @param g the base generator * @param l the private-value length - * - * @exception InvalidKeyException if the key cannot be encoded */ DHPrivateKey(BigInteger x, BigInteger p, BigInteger g, int l) { this.x = x; --- old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java 2020-07-25 23:46:22.241737383 +0530 +++ new/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java 2020-07-25 23:46:21.745732013 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -208,7 +208,7 @@ * * @return a CallSite, which, when invoked, will return an instance of the * functional interface - * @throws ReflectiveOperationException + * @throws LambdaConversionException */ abstract CallSite buildCallSite() throws LambdaConversionException; --- old/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java 2020-07-25 23:46:23.261748361 +0530 +++ new/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java 2020-07-25 23:46:22.761742991 +0530 @@ -200,7 +200,6 @@ * * @return a CallSite, which, when invoked, will return an instance of the * functional interface - * @throws ReflectiveOperationException * @throws LambdaConversionException If properly formed functional interface * is not found */ --- old/src/java.base/share/classes/java/math/BigDecimal.java 2020-07-25 23:46:24.285759291 +0530 +++ new/src/java.base/share/classes/java/math/BigDecimal.java 2020-07-25 23:46:23.785753966 +0530 @@ -5413,7 +5413,7 @@ * * @param n the numerator; must be negative * @param d the denominator; must not be unity - * @return a two-element {@long} array with the remainder and quotient in + * @return a two-element {@code long} array with the remainder and quotient in * the initial and final elements, respectively */ private static long[] divRemNegativeLong(long n, long d) { --- old/src/java.base/share/classes/java/math/MutableBigInteger.java 2020-07-25 23:46:25.381770889 +0530 +++ new/src/java.base/share/classes/java/math/MutableBigInteger.java 2020-07-25 23:46:24.877765572 +0530 @@ -145,7 +145,6 @@ * Makes this number an {@code n}-int number all of whose bits are ones. * Used by Burnikel-Ziegler division. * @param n number of ints in the {@code value} array - * @return a number equal to {@code ((1<<(32*n)))-1} */ private void ones(int n) { if (n > value.length) --- old/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25 23:46:26.449782093 +0530 +++ new/src/java.base/share/classes/java/net/ServerSocket.java 2020-07-25 23:46:25.937776742 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -315,7 +315,7 @@ /** * Creates the socket implementation. * - * @throws IOException if creation fails + * @throws SocketException if creation fails * @since 1.4 */ void createImpl() throws SocketException { --- old/src/java.base/share/classes/java/net/Socket.java 2020-07-25 23:46:27.485792869 +0530 +++ new/src/java.base/share/classes/java/net/Socket.java 2020-07-25 23:46:26.973787565 +0530 @@ -533,7 +533,7 @@ * * @param stream a {@code boolean} value : {@code true} for a TCP socket, * {@code false} for UDP. - * @throws IOException if creation fails + * @throws SocketException if creation fails * @since 1.4 */ void createImpl(boolean stream) throws SocketException { --- old/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java 2020-07-25 23:46:28.545803801 +0530 +++ new/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java 2020-07-25 23:46:28.029798501 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -773,7 +773,7 @@ * an "annotation structure" OR two bytes into an annotation * structure (i.e., after the type index). * - * @parameter complete true if the byte buffer points to the beginning + * @param complete true if the byte buffer points to the beginning * of an annotation structure (rather than two bytes in). */ private static void skipAnnotation(ByteBuffer buf, boolean complete) { Regards, Vipin

8 12

RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’
by Patrick Concannon 18 Aug '20

18 Aug '20

Hi, Could someone please review myself and Julia's RFE and CSR for JDK-8238286 - 'Add new flatMap stream operation that is more amenable to pushing’? This proposal is to add a new flatMap-like operation: `<R> Stream<R> mapMulti(BiConsumer<Consumer<R>, ? super T> mapper)` to the java.util.Stream class. This operation is more receptive to the pushing or yielding of values than the current implementation that internally assembles values (if any) into one or more streams. This addition includes the primitive variations of the operation i.e. mapMultiToInt, IntStream mapMulti, etc. issue: https://bugs.openjdk.java.net/browse/JDK-8238286 <https://bugs.openjdk.java.net/browse/JDK-8238286> csr: https://bugs.openjdk.java.net/browse/JDK-8248166 <https://bugs.openjdk.java.net/browse/JDK-8248166> webrev: http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/ <http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.00/> specdiff: http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview… <http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.00/overview…> Kind regards, Patrick & Julia

12 44

RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
by Alexey Bakhtin 14 Aug '20

14 Aug '20

Hello, Could you please review the following patch: JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding (based on the TLS server certificate). The channel binding data is calculated as following : • The client calculates a hash of the TLS server certificate. The hash algorithm is selected on the base of the certificate signature algorithm. Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based • The channel binding information is the same as defined in rfc4121 [1] with small corrections: • initiator and acceptor addresses should be set to NULL • initiator and acceptor address types should be zero. It contradicts to the “Using Channel Bindings in GSS-API” document [2] that say that the address type should be set to GSS_C_AF_NULLADDR=0xFF, instead of GSS_C_AF_UNSPEC=0x00. This patch introduces changes in the LDAP, SASL and JGSS modules to generate channel binding data automatically if requested by an application. This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. The patch introduces new environment property “com.sun.jndi.ldap.tls.cbtype” that indicates Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. Right now "tls-server-end-point" Channel Binding type is supported only. The client extracts server certificate from the underlying TLS connection and creates Channel Binding data for JGSS/Kerberos authentication if application indicates com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. Client application should also specify existing "com.sun.jndi.ldap.connect.timeout” property to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 [2] - https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/inde… Initial discussion of this issue is available at security-dev list: https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.h… https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.ht… https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.h… https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html

9 72

Review Request JDK-8244090: public lookup should find public members of public exported types
by Mandy Chung 12 Aug '20

12 Aug '20

Prior to JDK-8173978, publicLookup().in(C.class) produces a Lookup object on C with PUBLIC access which can be used to look up unconditionally exported public types from the module of C. Such lookup can only look up this C class defined by loader 1 but not another class named "C" defined by loader 2. JDK-8173978 adds the support for cross-module teleporting. publicLookup().in(C.class) was changed to produce a public Lookup i.e. with UNCONDITIONAL access. A public lookup should be able to look up public members of any unconditionally exported public types including a class named "C" loaded by different loaders. It reveals a bug in VM resolution for Lookup API that adds the loader constraints with java.lang.Object as the accessor that constraints a public lookup to load one type named C but any more. The lookup class of a public lookup is irrelevant to the lookup context. Type consistency on P/Q/R live Class objects from the given MethodType (MT)is ensured at the following: 1. P/Q/R are consistent from the loader of the declaring class of the resolved member (D's loader) 2. P/Q/R are consistent w.r.t. the invoking class and the caller's MT at invocation time (the method handle carries the caller's MT that will be verified). The loader constraints added for public lookup is not necessary and adds undesirable constraints. The proposed fixis to skip adding loader constraints if the lookup mode is either TRUSTED or UNCONDITIONAL. Webrev: http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8244090/webrev.00/index.ht… Thanks Mandy

2 2