Withdrawn: 8217501: Matcher.hitEnd returns false for incomplete surrogate pairs

On Mon, 27 Sep 2021 21:16:11 GMT, Ian Graves wrote: > Fixing a bug where character matcher doesn't mark hitEnd as true if it's a > code point with more than one character. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/5725

Re: RFR: 8277507: Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures

On Mon, 22 Nov 2021 08:14:20 GMT, Alan Bateman wrote: > It might be that jlink is throwing IAE for cases where another exception is > more appropriate, but it does suggests something intermittent in the jpackage > tests to trigger it. Issue https://bugs.openjdk.java.net/browse/JDK-8277058 now

Re: RFR: 8277507: Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures

On Sun, 21 Nov 2021 12:39:17 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to add more > diagnostics when a failure occurs in the jlink tool during the jpackage tests? > > As noted in https://bugs.openjdk.java.net/browse/JDK-8277507, so far 3 > failures hav

Re: RFR: 8277507: Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures

On Sun, 21 Nov 2021 12:39:17 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to add more > diagnostics when a failure occurs in the jlink tool during the jpackage tests? > > As noted in https://bugs.openjdk.java.net/browse/JDK-8277507, so far 3 > failures hav

Re: RFR: 8277322: Document that setting an invalid property `jdk.serialFilter` disables deserialization

On Mon, 22 Nov 2021 19:57:25 GMT, Roger Riggs wrote: > The effects of an invalid `jdk.serialFilter` property are not completely > documented. If the value of the system property jdk.serialFilter is invalid, > deserialization should not be possible and it should be clear in the > specification.

Re: RFR: 8261847: performace of java.lang.Record::toString should be improved [v5]

> Please review this PR which aims to optimize the implementation of the > `toString` method we provide for records. A benchmark comparing the > implementation we are providing for records with lombok found out that lombok > is much faster mainly because our implementation uses `String::format`.

Re: RFR: 8272042: java.util.ImmutableCollections$Map1 and MapN should not be @ValueBased [v2]

On Fri, 19 Nov 2021 20:47:40 GMT, Roger Riggs wrote: >> The `jdk.internal.ValueBased` annotation was incorrectly applied to >> subclasses of java.util.AbstractMap. >> [ValueBased](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/doc-files/ValueBased.html) >> requires that

Re: [External] : Re: jpackage - notarizing

> On Nov 22, 2021, at 9:01 PM, Kevin Rushforth > wrote: > > By way of clarification, JNF was never part of the JDK. What we removed was > the JDK's *usage* of JNF. And we did so because Apple deprecated it and never > even provide a JNF framework for aarch64. > > Applications either need t

Re: [External] : Re: jpackage - notarizing

By way of clarification, JNF was never part of the JDK. What we removed was the JDK's *usage* of JNF. And we did so because Apple deprecated it and never even provide a JNF framework for aarch64. Applications either need to migrate off JNF and find an alternative, or take Apple's open-source p

Re: RFR: 8261847: performace of java.lang.Record::toString should be improved [v4]

On Mon, 22 Nov 2021 15:53:53 GMT, Claes Redestad wrote: > FWIW I did a few experiments trying to move the chunking to `SCF`. Most made > things worse, but this is getting close: > https://github.com/openjdk/jdk/compare/master...cl4es:scf_split?expand=1 > > The threshold for when the JIT fails

Re: RFR: 8277322: Document that setting an invalid property `jdk.serialFilter` disables deserialization

On Mon, 22 Nov 2021 19:57:25 GMT, Roger Riggs wrote: > The effects of an invalid `jdk.serialFilter` property are not completely > documented. If the value of the system property jdk.serialFilter is invalid, > deserialization should not be possible and it should be clear in the > specification.

Re: RFR: 8261847: performace of java.lang.Record::toString should be improved [v3]

On Sat, 20 Nov 2021 12:10:40 GMT, Jim Laskey wrote: >> @stuart-marks yes, a general purpose splitting logic moved into the >> `StringConcatFactory` would be able to get rid of the arbitrary 200 slot >> limit (we would hit a harder but less arbitrary limit at around 253 instead). >> >> @JimLask

Re: RFR: 8277606: String(String) constructor could copy hashIsZero

On Mon, 22 Nov 2021 22:59:21 GMT, PROgrm_JARvis wrote: > This is a trivial fix to make `String(String)` constructor copy the value of > `hashIsZero` field. LGTM - Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6511

Re: Constructor `String(String)` does not copy `hashIsZero`

Thanks, I've created the PR [1] with the fix. [1]: https://github.com/openjdk/jdk/pull/6511 вт, 23 нояб. 2021 г., 01:42 Claes Redestad : > Hi, > > this appears to be unintentionally left out. I've filed a bug[1]. > > While marked as an @IntrinsicCandidate, I can't see that HotSpot/C2 is > actual

RFR: 8277606: String(String) constructor could copy hashIsZero

This is a trivial fix to make `String(String)` constructor copy the value of `hashIsZero` field. - Commit messages: - fix: copy `hashIsZero` in `String#String(String)` Changes: https://git.openjdk.java.net/jdk/pull/6511/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6

Re: Constructor `String(String)` does not copy `hashIsZero`

Hi, this appears to be unintentionally left out. I've filed a bug[1]. While marked as an @IntrinsicCandidate, I can't see that HotSpot/C2 is actually intrinsifying this constructor. The signature is used for some pattern matching in the legacy stringopts.cpp code, though. So the trivial fix shou

Re: RFR: 8276904: Optional.toString() is unnecessarily expensive

On Wed, 10 Nov 2021 17:44:04 GMT, Eamonn McManus wrote: > Use string concatenation instead of `String.format`. I talked to Brian about this a bit. Changing `format` to concatenation is probably ok this case for two reasons: 1) it's the simplest possible such transformation, and as such it's no

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v26]

On Mon, 22 Nov 2021 12:09:30 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] - https://openjd

Re: RFR: 8277322: Document that setting an invalid property `jdk.serialFilter` disables deserialization

On Mon, 22 Nov 2021 19:57:25 GMT, Roger Riggs wrote: > The effects of an invalid `jdk.serialFilter` property are not completely > documented. If the value of the system property jdk.serialFilter is invalid, > deserialization should not be possible and it should be clear in the > specification.

Constructor `String(String)` does not copy `hashIsZero`

According to openjdk/jdk [1] current copy-constructor of String class does not copy the value of hashIsZero field which may lead to 0-hash being recalculated on copy even if it is known to be 0. Could you please tell me if I am right with this point or if this behaviour is intentional? If this is a

Re: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]

On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy wrote: >> The time to get JDK 19 underway draws nigh, please review this usual set of >> start-of-release updates, including CSRs for the javac and javax.lang.model >> updates: >> >> JDK-8277512: Add SourceVersion.RELEASE_19 >> https://bugs.openjdk.j

String.indexOf(single-char-String)

Hello, I kept forgetting which variants of the String methods perform better with single-char-Strings and which with char (IDEs had the tendency to suggest the wrong variant since it changed between JDK releases). So i wrote JMH benchmarks and noticed that the last method with a performance d

Re: RFR: 8272042: java.util.ImmutableCollections$Map1 and MapN should not be @ValueBased [v2]

On Sun, 21 Nov 2021 11:15:53 GMT, Jens Li wrote: > Should this change also update the Javadoc on `java.util.Map` and remove the > statement that the return values of `Map#of` are value-based? > This PR is only correcting the application of the internal use annotation to some implementation cl

Re: RFR: JDK-8277451: java.lang.reflect.Field::set on static field with invalid argument type should throw IAE [v2]

On Mon, 22 Nov 2021 20:01:50 GMT, Mandy Chung wrote: >> java.lang.reflect.Field::set on static field with invalid argument type >> should throw IAE. But this regression is introduced by JEP 416 throwing NPE >> instead. >> >> `ensureObj` is called as the first check of the `Field::set` method

RFR: 8277322: Document that setting an invalid property `jdk.serialFilter` disables deserialization

The effects of an invalid `jdk.serialFilter` property are not completely documented. If the value of the system property jdk.serialFilter is invalid, deserialization should not be possible and it should be clear in the specification. Specify an implementation specific exception is thrown in th

Re: RFR: JDK-8277451: java.lang.reflect.Field::set on static field with invalid argument type should throw IAE [v2]

> java.lang.reflect.Field::set on static field with invalid argument type > should throw IAE. But this regression is introduced by JEP 416 throwing NPE > instead. > > `ensureObj` is called as the first check of the `Field::set` method to ensure > the receiver object is checked first before the

Re: RFR: JDK-8277451: java.lang.reflect.Field::set on static field with invalid argument type should throw IAE [v2]

On Sun, 21 Nov 2021 21:05:19 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/reflect/MethodHandleFieldAccessorImpl.java >> line 72: >> >>> 70: */ >>> 71: protected IllegalArgumentException >>> newGetIllegalArgumentException(Object o) { >>> 72: return new I

Re: jpackage - notarizing

> On Nov 22, 2021, at 12:39 PM, Alan Snyder wrote: > > >> On Nov 22, 2021, at 10:12 AM, Kevin Rushforth >> wrote: >> >> JNF was removed from the JDK if that's what you are asking. > > > > Indeed, that is why there is an issue. > > The JDK may not be using JNF, but library developers st

Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v3]

On Fri, 19 Nov 2021 10:42:23 GMT, kabutz wrote: > > I think the functionality in this PR is worth pursuing, but with the JDK 18 > > rampdown 1 date fast approaching, as a non-urgent issue, I think we > > shouldn't try to rush it into JDK 18. > > > I looked more closely and now understand a bit

Re: RFR: 8276141: XPathFactory set/getProperty method [v10]

On Thu, 18 Nov 2021 23:43:20 GMT, Joe Wang wrote: >> Add setProperty/getProperty methods to the XPath API so that properties can >> be supported in the future. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revision: > > update as commente

Re: jpackage - notarizing

> On Nov 22, 2021, at 10:12 AM, Kevin Rushforth > wrote: > > JNF was removed from the JDK if that's what you are asking. Indeed, that is why there is an issue. The JDK may not be using JNF, but library developers still use it. The JDK replacement for JNF is not supported for use outside t

Re: jpackage - notarizing

JNF was removed from the JDK if that's what you are asking. -- Kevin On 11/22/2021 10:11 AM, Alan Snyder wrote: Well, if you look at the JNF part of the tree, the only include I see that comes from the JDK is jni.h. Isn’t that what you were questioning? On Nov 22, 2021, at 10:06 AM, Mic

Re: jpackage - notarizing

Well, if you look at the JNF part of the tree, the only include I see that comes from the JDK is jni.h. Isn’t that what you were questioning? > On Nov 22, 2021, at 10:06 AM, Michael Hall wrote: > > > >> On Nov 22, 2021, at 11:59 AM, Alan Snyder > > wrote: >>

Integrated: 8277429: Conflicting jpackage static library name

On Sat, 20 Nov 2021 03:26:51 GMT, Alexey Semenyuk wrote: > 8277429: Conflicting jpackage static library name This pull request has now been integrated. Changeset: e3911a85 Author:Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/e3911a8532e9b93ba5e65c613bd79864485db5ce St

Re: jpackage - notarizing

> On Nov 22, 2021, at 11:59 AM, Alan Snyder wrote: > > I’m talking about the Xcode project for JNF. > I thought I was too. Unless it’s changed since I cloned or the one I’m looking at is somehow different. The URL I saved was https://github.com/apple/openjdk/

Re: jpackage - notarizing

I’m talking about the Xcode project for JNF. > On Nov 22, 2021, at 9:54 AM, Michael Hall wrote: > > > >> On Nov 22, 2021, at 11:44 AM, Alan Snyder wrote: >> >> JNF is just an Objective-C library that uses jni.h. Otherwise, it is not >> dependent on the JDK. >> >>> On Nov 22, 2021, at 9:23

Re: jpackage - notarizing

> On Nov 22, 2021, at 11:44 AM, Alan Snyder wrote: > > JNF is just an Objective-C library that uses jni.h. Otherwise, it is not > dependent on the JDK. > >> On Nov 22, 2021, at 9:23 AM, Michael Hall wrote: >> >> >> >>> On Nov 22, 2021, at 10:40 AM, Alan Snyder wrote: >>> >>> I’m still

Re: jpackage - notarizing

JNF is just an Objective-C library that uses jni.h. Otherwise, it is not dependent on the JDK. > On Nov 22, 2021, at 9:23 AM, Michael Hall wrote: > > > >> On Nov 22, 2021, at 10:40 AM, Alan Snyder wrote: >> >> I’m still hoping someone will step up to provide a home for the compiled >> Java

Re: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]

On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy wrote: >> The time to get JDK 19 underway draws nigh, please review this usual set of >> start-of-release updates, including CSRs for the javac and javax.lang.model >> updates: >> >> JDK-8277512: Add SourceVersion.RELEASE_19 >> https://bugs.openjdk.j

Re: jpackage - notarizing

> On Nov 22, 2021, at 10:40 AM, Alan Snyder wrote: > > I’m still hoping someone will step up to provide a home for the compiled > JavaNativeFoundation framework. > > In any case, the sources are available and you can build it yourself. > > https://github.com/apple/openjdk.git

Re: RFR: 8277429: Conflicting jpackage static library name

On Sat, 20 Nov 2021 03:26:51 GMT, Alexey Semenyuk wrote: > 8277429: Conflicting jpackage static library name The problem arises when running the "static-libs" build, where every library and executable is just linked into a static-lib for downstream consumers (Graal). - PR: https:

Re: jpackage - notarizing

I’m still hoping someone will step up to provide a home for the compiled JavaNativeFoundation framework. In any case, the sources are available and you can build it yourself. https://github.com/apple/openjdk.git > On Nov 22, 2021, at 7:15 AM, Michael Hall wrote: > > In order to use JavaNative

Integrated: JDK-8274685 - Documentation suggests there are ArbitrarilyJumpableGenerator when none

On Thu, 11 Nov 2021 13:34:21 GMT, Jim Laskey wrote: > "There is also an interface RandomGenerator.ArbitrarilyJumpableGenerator for > algorithms that allow jumping along the state cycle by any user-specified > distance. In this package, implementations of these interfaces include > "Xoroshiro12

Integrated: JDK-8273792 - JumpableGenerator.rngs() documentation refers to wrong method

On Thu, 11 Nov 2021 13:54:37 GMT, Jim Laskey wrote: > Documentation in `RandomGenerator.rngs()` refers to > `JumpableGenerator.jump()` when it should be `JumpableGenerator.jumps()` This pull request has now been integrated. Changeset: 6b4fbaed Author:Jim Laskey URL: https://git.ope

Re: RFR: 8261847: performace of java.lang.Record::toString should be improved [v4]

On Mon, 22 Nov 2021 16:03:16 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 314: >> >>> 312: ).getTarget(); >>> 313: mhs[splitIndex] = >>> MethodHandles.filterArguments(mhs[splitIndex], 0, currentSplitGette

Withdrawn: 8274544: Langtools command's usage were garbled on Japanese Windows

On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi wrote: > JEP-400 (UTF-8 by Default) was eabled on JDK18-b13. > After JDK18-b13, javac and some other langtool command's usage were garbled > on Japanese Windows. > These commands use PrintWriter instead of standard out/err with PrintStream. T

Re: RFR: 8274544: Langtools command's usage were garbled on Japanese Windows [v5]

On Fri, 19 Nov 2021 16:48:03 GMT, Naoto Sato wrote: >> Hello @naotoj . >> For PrintStream.getCharset(), following changes may be required. >> >> +++ src/java.base/share/classes/java/io/OutputStreamWriter.java >> +Charset getCharset() { >> +return se.getCharset(); >> +} >> >> +++

Re: RFR: 8261847: performace of java.lang.Record::toString should be improved [v4]

On Sun, 21 Nov 2021 00:29:46 GMT, Vicente Romero wrote: >> Please review this PR which aims to optimize the implementation of the >> `toString` method we provide for records. A benchmark comparing the >> implementation we are providing for records with lombok found out that >> lombok is much f

Re: RFR: 8261847: performace of java.lang.Record::toString should be improved [v4]

On Mon, 22 Nov 2021 15:56:46 GMT, Claes Redestad wrote: >> Vicente Romero has updated the pull request incrementally with one >> additional commit since the last revision: >> >> setting max split size to 20 > > src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 314: > >> 3

Re: RFR: 8261847: performace of java.lang.Record::toString should be improved [v4]

On Sun, 21 Nov 2021 00:29:46 GMT, Vicente Romero wrote: >> Please review this PR which aims to optimize the implementation of the >> `toString` method we provide for records. A benchmark comparing the >> implementation we are providing for records with lombok found out that >> lombok is much f

Re: RFR: 8261847: performace of java.lang.Record::toString should be improved [v4]

On Sun, 21 Nov 2021 00:29:46 GMT, Vicente Romero wrote: >> Please review this PR which aims to optimize the implementation of the >> `toString` method we provide for records. A benchmark comparing the >> implementation we are providing for records with lombok found out that >> lombok is much f

Re: RFR: 8261847: performace of java.lang.Record::toString should be improved [v4]

On Sun, 21 Nov 2021 00:29:46 GMT, Vicente Romero wrote: >> Please review this PR which aims to optimize the implementation of the >> `toString` method we provide for records. A benchmark comparing the >> implementation we are providing for records with lombok found out that >> lombok is much f

Re: RFR: 8277429: Conflicting jpackage static library name

On Sat, 20 Nov 2021 03:26:51 GMT, Alexey Semenyuk wrote: > 8277429: Conflicting jpackage static library name How come BUILD_JPACKAGE_APPLAUNCHEREXE results in a library? It sounds like an executable... That is, I realize this patch fixes the problem as described, I just don't understand why i

jpackage - notarizing

While I was looking at —mac-dmg-content I thought I would also look at notarization. I had downloaded my app on an older machine while my new was being serviced and got uninviting messages about Apple being unable to determine it was full of malware. Notarization I found out was supposed to be

Re: RFR: 8276764: Enable deterministic file content ordering for Jar and Jmod [v6]

On Fri, 19 Nov 2021 22:04:47 GMT, Andrew Leonard wrote: >> Both jar and jmod utilise java.io file operations whose methods define no >> ordering of the return file lists, and in fact rely on OS query file >> ordering, which can differ by underlying OS architecture. >> This PR adds sort processi

Re: jpackage --mac-dmg-content

Nit, if you open the dmg the additional content doesn’t quite fit in the bottom of the window. My thought had been smaller icons for the additional. This doesn’t seem possible?

Re: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time [v7]

> The commit here is a potential fix for the issue noted in > https://bugs.openjdk.java.net/browse/JDK-8258117. > > The change here repurposes an existing internal interface `ModuleInfoEntry` > to keep track of the last modified timestamp of a `module-info.class` > descriptor. > > This commit

jpackage --mac-dmg-content

[08:26:41.669] jdk.jpackage.internal.PackagerException: Error: Option [--mac-dmg-content] is not valid with type [default] dmg is the default type? Why should this be an error?

Re: RFR: 8277429: Conflicting jpackage static library name

On Sat, 20 Nov 2021 03:26:51 GMT, Alexey Semenyuk wrote: > 8277429: Conflicting jpackage static library name Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6485

Re: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]

On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy wrote: >> The time to get JDK 19 underway draws nigh, please review this usual set of >> start-of-release updates, including CSRs for the javac and javax.lang.model >> updates: >> >> JDK-8277512: Add SourceVersion.RELEASE_19 >> https://bugs.openjdk.j

Re: RFR: 8276764: Enable deterministic file content ordering for Jar and Jmod [v6]

On Fri, 19 Nov 2021 22:04:47 GMT, Andrew Leonard wrote: >> Both jar and jmod utilise java.io file operations whose methods define no >> ordering of the return file lists, and in fact rely on OS query file >> ordering, which can differ by underlying OS architecture. >> This PR adds sort processi

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v26]

> This PR contains the API and implementation changes for JEP-419 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v25]

> This PR contains the API and implementation changes for JEP-419 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request

Re: RFR: 8277535: Remove redundant Stream.distinct()/sorted() steps [v2]

> 1. Stream.distinct() is redundant before toSet() collector. Duplicates will > be collapsed by Collector. > 2. Stream.sorted() is redundant before toMap() collector. Keys will be > shuffled by Collector (it's a HashMap in current implementation) Andrey Turbanov has updated the pull request incr

Re: RFR: 8277535: Remove redundant Stream.distinct()/sorted() steps

On Mon, 27 Sep 2021 11:20:53 GMT, Andrey Turbanov wrote: > 1. Stream.distinct() is redundant before toSet() collector. Duplicates will > be collapsed by Collector. > 2. Stream.sorted() is redundant before toMap() collector. Keys will be > shuffled by Collector (it's a HashMap in current impleme

RFR: 8277535: Remove redundant Stream.distinct()/sorted() steps

1. Stream.distinct() is redundant before toSet() collector. Duplicates will be collapsed by Collector. 2. Stream.sorted() is redundant before toMap() collector. Keys will be shuffled by Collector (it's a HashMap in current implementation) - Commit messages: - [PATCH] Remove redunda

Re: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time [v5]

On Mon, 22 Nov 2021 09:09:37 GMT, Jaikiran Pai wrote: >> test/jdk/tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java >> line 60: >> >>> 58: private static final String UPDATED_MODULE_VERSION = "1.2.4"; >>> 59: private static final String MAIN_CLASS = "jdk.test.foo.Foo"

Re: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time [v5]

On Mon, 22 Nov 2021 08:25:38 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains seven additional >> commit

Re: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time [v6]

> The commit here is a potential fix for the issue noted in > https://bugs.openjdk.java.net/browse/JDK-8258117. > > The change here repurposes an existing internal interface `ModuleInfoEntry` > to keep track of the last modified timestamp of a `module-info.class` > descriptor. > > This commit

Re: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]

On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy wrote: >> The time to get JDK 19 underway draws nigh, please review this usual set of >> start-of-release updates, including CSRs for the javac and javax.lang.model >> updates: >> >> JDK-8277512: Add SourceVersion.RELEASE_19 >> https://bugs.openjdk.j

Re: RFR: 8258117: jar tool sets the time stamp of module-info.class entries to the current time [v5]

On Sat, 20 Nov 2021 01:58:54 GMT, Jaikiran Pai wrote: >> The commit here is a potential fix for the issue noted in >> https://bugs.openjdk.java.net/browse/JDK-8258117. >> >> The change here repurposes an existing internal interface `ModuleInfoEntry` >> to keep track of the last modified timest

Re: RFR: 8277507: Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures

On Sun, 21 Nov 2021 12:39:17 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to add more > diagnostics when a failure occurs in the jlink tool during the jpackage tests? > > As noted in https://bugs.openjdk.java.net/browse/JDK-8277507, so far 3 > failures hav