On Tue, 30 Apr 2024 11:23:01 GMT, Christian Stein wrote:
> Please pre-review this draft pull request adding a default for response for
> the `/favicon.ico` path to the Simple Web Server introduced by [JEP
> 408](https://openjdk.org/jeps/408). The image in this PR is a copy of
On Tue, 7 May 2024 07:45:35 GMT, Daniel Jeliński wrote:
>> Using Java's birthday `"Mon, 23 May 1995 11:11:11 GMT"` for the time being.
>
> [java.version.date](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/System.html#java.version.date)
> could be a reasonable
On Mon, 6 May 2024 14:55:31 GMT, Christian Stein wrote:
>> Please pre-review this draft pull request adding a default for response for
>> the `/favicon.ico` path to the Simple Web Server introduced by [JEP
>> 408](https://openjdk.org/jeps/408). The image in this PR is a
On Tue, 30 Apr 2024 11:23:01 GMT, Christian Stein wrote:
> Please pre-review this draft pull request adding a default for response for
> the `/favicon.ico` path to the Simple Web Server introduced by [JEP
> 408](https://openjdk.org/jeps/408). The image in this PR is a copy of
Please pre-review this draft pull request adding a default for response for the
`/favicon.ico` path to the Simple Web Server introduced by [JEP
408](https://openjdk.org/jeps/408). The image in this PR is a copy of
https://inside.java/images/favicon.ico
Before this change, an initial request
On Tue, 9 Apr 2024 13:38:29 GMT, Jan Lahoda wrote:
>> This is an implementation of JEP JDK-8315129: Module Import Declarations
>> (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>>
>> It is mostly straightforward - the module imports are parsed, and
On Mon, 8 Apr 2024 09:20:44 GMT, Daniel Jeliński wrote:
> The RejectedExecutionException was thrown when the thread executing
> `Server.start` managed to shut down the `compilerThreadPool` before the
> thread executing `Server.handleRequest` submitted the compilation task.
>
> This patch
I use the "resolve" goal like this:
mvn --batch-mode --no-transfer-progress -DoutputFile=resolved.txt
org.apache.maven.plugins:maven-dependency-plugin:3.6.1:resolve
...and parse the output for Java module names and whether they are
"automatic".
I use the "resolve" goal like this:
mvn --batch-mode --no-transfer-progress -DoutputFile=resolved.txt
org.apache.maven.plugins:maven-dependency-plugin:3.6.1:resolve
...and parse the output for Java module names and whether they are
"automatic".
On 2024/03/06 07:15:11 Sam Gammon wrote:
> I hadn't noticed that test, thank you. That's very helpful, maybe, then,
> Guava's string HEAD-jar-SNAPSHOT can simply be a change to
> 1.0-HEAD-jar-SNAPSHOT.
That feels like the best solution to me: you opt-in to be a Java module, you
also
The commit you linked contains a test for "1.0-SNAPSHOT", a valid version
string according to Java's module descriptor version schema as defined here:
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html
"HEAD-SNAPSHOT" fails due to it
+1
On Wed, Feb 28, 2024 at 8:31 AM Benjamin Marwell
wrote:
> Hi Maven Devs/Users/Committers and PMC members!
>
> After several discussions on the mailing lists, I would like to
> start a vote in favour of setting the minimal Java bytecode target
> of Maven-Core 4 to 17 and hence require Java 17
+1
On Wed, Feb 28, 2024 at 8:31 AM Benjamin Marwell
wrote:
> Hi Maven Devs/Users/Committers and PMC members!
>
> After several discussions on the mailing lists, I would like to
> start a vote in favour of setting the minimal Java bytecode target
> of Maven-Core 4 to 17 and hence require Java 17
On Mon, 19 Feb 2024 15:42:05 GMT, Christian Stein wrote:
>> Please review this PR that makes the launcher helper keep a reference to the
>> executable JAR file active after extracting the name of the main class and
>> returning it as Class instance. Now, when loading classes
On Wed, 14 Feb 2024 11:03:07 GMT, Christian Stein wrote:
> Please review this PR that makes the launcher helper keep a reference to the
> executable JAR file active after extracting the name of the main class and
> returning it as Class instance. Now, when loading classes from the
On Thu, 15 Feb 2024 08:53:12 GMT, Alan Bateman wrote:
>> `String jarname` is filled by the caller with the value of `String what`,
>> and therefore contains the entire path to the executable JAR file. Using
>> only `jarFile.getName()` will prevent any parent directories from being
>> noted in
> Please review this PR that makes the launcher helper keep a reference to the
> executable JAR file active after extracting the name of the main class and
> returning it as Class instance. Now, when loading classes from the JAR file,
> it hasn't to be re-opened.
Christian Stein
On Mon, 19 Feb 2024 07:32:31 GMT, Jaikiran Pai wrote:
> Both the files will need a copyright year update.
Right. Updating both files.
> The JBS issue would need an appropriate noreg label too
> https://openjdk.org/guide/#noreg
Added `noreg-cleanup` to the issue.
-
PR Comment:
On Mon, 19 Feb 2024 10:41:03 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 821:
>>
>>> 819: // In LM_JAR mode, put the underlying file in the
>>> JarFile/ZipFile cache.
>>> 820: // This will avoid needing to re-parse the manifest
On Mon, 19 Feb 2024 07:04:07 GMT, David Holmes wrote:
> Please reviews these manpage updates in relation to "JEP 458: Launch
> Multi-File Source-Code Programs". The manpage sources had previously been
> updated internally at Oracle under JDK-8322478, but the open troff file was
> not
> Please review this PR that makes the launcher helper keep a reference to the
> executable JAR file active after extracting the name of the main class and
> returning it as Class instance. Now, when loading classes from the JAR file,
> it hasn't to be re-opened.
Christian Stein
On Wed, 14 Feb 2024 11:41:43 GMT, Alan Bateman wrote:
>> Please review this PR that makes the launcher helper keep a reference to the
>> executable JAR file active after extracting the name of the main class and
>> returning it as Class instance. Now, when loading classes from the JAR file,
On Wed, 14 Feb 2024 11:40:16 GMT, Alan Bateman wrote:
>> Please review this PR that makes the launcher helper keep a reference to the
>> executable JAR file active after extracting the name of the main class and
>> returning it as Class instance. Now, when loading classes from the JAR file,
Please review this PR that makes the launcher helper keep a reference to the
executable JAR file active after extracting the name of the main class and
returning it as Class instance. Now, when loading classes from the JAR file, it
hasn't to be re-opened.
-
Commit messages:
-
An exemplary use of module layers is documented and implemented here:
https://github.com/moditect/layrry
Copied from its "Why Layrry?" section:
This is where Layrry comes in: utilizing the notion of module layers, it
> provides a declarative approach as well as an API for assembling
>
On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung wrote:
> Translation drop for JDK22 RDP1
Marked as reviewed by cstein (Committer).
German translations read OK.
Nit: some layouts get lost in translated files - it would be great to have
similar usage of `\n` and `` in the translated files.
For
On Wed, 13 Dec 2023 22:12:48 GMT, Alisen Chung wrote:
> Translation drop for JDK22 RDP1
Marked as reviewed by cstein (Committer).
German translations read OK.
Nit: some layouts get lost in translated files - it would be great to have
similar usage of `\n` and `` in the translated files.
For
On Thu, 30 Nov 2023 16:08:54 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList java/util/stream/GatherersTest.java.
Seems to be a different issue with "linux-x86" (32-bit host) and
`GathererTest::testMassivelyComposedGatherers`.
On Thu, 30 Nov 2023 16:08:54 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList java/util/stream/GatherersTest.java.
Off by one "s"?
Or does `java/util/stream/GathererTest` (without "s") fail in addition?
On Mon, 20 Nov 2023 13:50:45 GMT, Alan Bateman wrote:
> [...] it does make the java launcher code much simpler.
Yes. That's a very nice effect of surfacing the launch protocol directyl in
`java.lang.Class`
> So I'm not sure about the naming, it feels more like a `findMainMethod` to
>
On Mon, 20 Nov 2023 13:50:45 GMT, Alan Bateman wrote:
> [...] it does make the java launcher code much simpler.
Yes. That's a very nice effect of surfacing the launch protocol directyl in
`java.lang.Class`
> So I'm not sure about the naming, it feels more like a `findMainMethod` to
>
On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey wrote:
>> Address changes from JEP 445 to JEP 463.
>>
>> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class.
>>
>> - Don't mark class on read.
>>
>> - Remove reflection and annotation processing related to unnamed classes.
>>
>> -
On Fri, 3 Nov 2023 12:40:48 GMT, Jim Laskey wrote:
>> Address changes from JEP 445 to JEP 463.
>>
>> - Move from a SYNTHETIC unnamed class to a MANDATED implicit class.
>>
>> - Don't mark class on read.
>>
>> - Remove reflection and annotation processing related to unnamed classes.
>>
>> -
On Tue, 26 Sep 2023 12:20:55 GMT, Matthias Baesken wrote:
>> AIX currently does not have the jdk.jpackage system module. We have to take
>> this into account for these jpackage tests.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last
On Tue, 26 Sep 2023 09:40:11 GMT, Matthias Baesken wrote:
> AIX currently does not have the jdk.jpackage system module. We have to take
> this into account for these jpackage tests.
Instead of adding those directives to all 11 files, can you please try adding
`modules = ...` line to the
dk/test/lib/format/ArrayDiffTest.java
>
>Co-authored-by: Christian Stein
Looks good to me.
Tested with `--test test/lib-test/jdk/test/lib`.
-
Marked as reviewed by cstein (Committer).
PR Review: https://git.openjdk.org/jdk/pull/15131#pullrequestreview-1635286817
On Thu, 7 Sep 2023 07:15:06 GMT, Qing Xiao wrote:
>> Modified all tests under lib-test/jdk to use JUnit
>
> Qing Xiao has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Change test static method to instance method
On Tue, 15 Aug 2023 08:07:09 GMT, Christian Stein wrote:
>> test/lib-test/jdk/test/lib/format/ArrayDiffTest.java line 2:
>>
>>> 1: /*
>>> 2: * Copyright (c) 2020, 2021, 2023, Oracle and/or its affiliates. All
>>> rights reserved.
>>
>> S
On Thu, 7 Sep 2023 16:16:36 GMT, Aleksey Shipilev wrote:
> Please wait for GHA to complete before integrating GHA patches!
Yes, sure. Next time, I'll wait for completion - this time, I checked that
`actions/checkout@v4` steps were successfully run in
On Thu, 7 Sep 2023 14:47:41 GMT, Christian Stein wrote:
> Please review this change to update all workflows to use
> `actions/checkout@v4`.
>
> Find the associated release notes here:
> https://github.com/actions/checkout/releases/tag/v4.0.0
This pull request has now
On Thu, 7 Sep 2023 14:47:41 GMT, Christian Stein wrote:
> Please review this change to update all workflows to use
> `actions/checkout@v4`.
>
> Find the associated release notes here:
> https://github.com/actions/checkout/releases/tag/v4.0.0
Mainly because the underlying No
Please review this change to update all workflows to use `actions/checkout@v4`.
Find the associated release notes here:
https://github.com/actions/checkout/releases/tag/v4.0.0
-
Commit messages:
- 8315863: [GHA] Update checkout action to use v4
Changes:
On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.3,1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.3,1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
Please review the change to update to using jtreg 7.3,1.
The primary change is to the `jib-profiles.js` file, which specifies the
version of jtreg to use, for those systems that rely on this file. In addition,
the `requiredVersion` has been updated in the various `TEST.ROOT` files.
This change
Please review the change to update to using jtreg 7.3,1.
The primary change is to the `jib-profiles.js` file, which specifies the
version of jtreg to use, for those systems that rely on this file. In addition,
the `requiredVersion` has been updated in the various `TEST.ROOT` files.
This change
On Wed, 2 Aug 2023 23:25:13 GMT, Qing Xiao wrote:
> Modified all tests under lib-test/jdk to use JUnit
Please only keep first and last/latest year of changes.
test/lib-test/jdk/test/lib/hexdump/HexPrinterTest.java line 2:
> 1: /*
> 2: * Copyright (c) 2019, 2020, 2023, Oracle and/or its
On Tue, 15 Aug 2023 08:03:59 GMT, John Jiang wrote:
>> Modified all tests under lib-test/jdk to use JUnit
>
> test/lib-test/jdk/test/lib/format/ArrayDiffTest.java line 2:
>
>> 1: /*
>> 2: * Copyright (c) 2020, 2021, 2023, Oracle and/or its affiliates. All
>> rights reserved.
>
> Should it
On Wed, 2 Aug 2023 23:25:13 GMT, Qing Xiao wrote:
> Modified all tests under lib-test/jdk to use JUnit
Marked as reviewed by cstein (Committer).
-
PR Review: https://git.openjdk.org/jdk/pull/15131#pullrequestreview-1578082673
On Wed, 9 Aug 2023 10:45:56 GMT, Christian Stein wrote:
> Please review this change to remove Unit-based tests in `java/lang/invoke`
> from `jdk`'s problem list. The underlying race condition in jtreg was fixed
> in release 7.3; which is now the default version used in JDK
Please review this change to remove Unit-based tests in `java/lang/invoke` from
`jdk`'s problem list. The underlying race condition in jtreg was fixed in
release 7.3; which is now the default version used in JDK mainline development.
-
Commit messages:
- Update ProblemList.txt
On Wed, 26 Jul 2023 09:06:19 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.3.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
On Wed, 26 Jul 2023 07:25:20 GMT, Christian Stein wrote:
> Problem list some JUnit-based tests in
> `test/jdk/java/lang/invoke/MethodHandleProxies/` for the time being - until
> `jtreg` 7.3 with a fix for the underlying race condition is released. That
> fix is track
Problem list some JUnit-based tests in
`test/jdk/java/lang/invoke/MethodHandleProxies/` for the time being - until
`jtreg` 7.3 with a fix for the underlying race condition is released. That fix
is tracked via https://bugs.openjdk.org/browse/CODETOOLS-7903507
-
Commit messages:
-
On Fri, 23 Jun 2023 11:32:04 GMT, Christian Stein wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [4bf78162](https://github.com/openjdk/jdk/commit/4bf78162c52564645af79b8324b69d89102dc024)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
Hi all,
This pull request contains a backport of commit
[4bf78162](https://github.com/openjdk/jdk/commit/4bf78162c52564645af79b8324b69d89102dc024)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Christian Stein on 23 Jun 2023
On Tue, 20 Jun 2023 13:54:15 GMT, Christian Stein wrote:
> Please review this update to `java`'s help output for `--module-path`/`-p`.
>
> This PR also updates the output for the closely related
> `--upgrade-module-path` option.
>
> Thanks in advance!
This pull re
> Please review this update to `java`'s help output for `--module-path`/`-p`.
>
> This PR also updates the output for the closely related
> `--upgrade-module-path` option.
>
> Thanks in advance!
Christian Stein has updated the pull request incrementally with one additi
Please review this update to `java`'s help output for `--module-path`/`-p`.
This PR also updates the output for the closely related `--upgrade-module-path`
option.
Thanks in advance!
-
Commit messages:
- Update `--upgrade-module-path` description
- 8309670: java -help output for
On Mon, 19 Jun 2023 11:39:21 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which backports the fixes for
> https://bugs.openjdk.org/browse/JDK-8310259?
>
> This wasn't a clean backport because this also brings in
> https://bugs.openjdk.org/browse/JDK-8309934 which in
On Fri, 16 Jun 2023 11:08:41 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address the recent
> github actions failures?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8310259 the commit in this PR
> pins the `msys2/setup-msys2` to a previous
On Fri, 16 Jun 2023 11:14:10 GMT, Jaikiran Pai wrote:
>> Please review this change to use the boot JDK for building jtreg when
>> running on GitHub Actions.
>>
>> This is a best-effort follow-up change to
>> - #14448
>> which didn't have the desired results - the `Bad address` error does still
On Fri, 16 Jun 2023 06:05:16 GMT, Christian Stein wrote:
> Please review this change to use the boot JDK for building jtreg when running
> on GitHub Actions.
>
> This is a best-effort follow-up change to
> - #14448
> which didn't have the desired results - the `Bad address
On Fri, 16 Jun 2023 11:14:10 GMT, Jaikiran Pai wrote:
>> Please review this change to use the boot JDK for building jtreg when
>> running on GitHub Actions.
>>
>> This is a best-effort follow-up change to
>> - #14448
>> which didn't have the desired results - the `Bad address` error does still
On Fri, 16 Jun 2023 06:05:16 GMT, Christian Stein wrote:
> Please review this change to use the boot JDK for building jtreg when running
> on GitHub Actions.
>
> This is a best-effort follow-up change to
> - #14448
> which didn't have the desired results - the `Bad address
On Fri, 16 Jun 2023 08:45:01 GMT, Aleksey Shipilev wrote:
> Wait, so why does it fix the bug? Is it a MSYS path conversion bug?
It does not fix the bug, it works around it. Something (in MSYS) failes to work
(calling `javac`) that used to work without problem until some week ago (new
version
Please review this change to use the boot JDK for building jtreg when running
on GitHub Actions.
This is a best-effort follow-up change to
- #14448
which didn't have the desired results - the `Bad address` error does still
appear with using the pre-installed JDKs 11 and 17.
Tests using the
On Wed, 14 Jun 2023 10:07:01 GMT, Christian Stein wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [8aad881e](https://github.com/openjdk/jdk/commit/8aad881e803fddc26f45270f779ff0c0e5a095d8)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
On Wed, 14 Jun 2023 18:45:04 GMT, Christian Stein wrote:
>> Hi all,
>>
>> This pull request contains a backport of commit
>> [8aad881e](https://github.com/openjdk/jdk/commit/8aad881e803fddc26f45270f779ff0c0e5a095d8)
>> from the [openjdk/jdk](https://g
> Hi all,
>
> This pull request contains a backport of commit
> [8aad881e](https://github.com/openjdk/jdk/commit/8aad881e803fddc26f45270f779ff0c0e5a095d8)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit being backported was authored by Chri
On Wed, 14 Jun 2023 12:39:00 GMT, Martin Doerr wrote:
> Could you enable GitHub Actions and run the tests, please?
I enabled workflows on the fork the bot created for me - how do I trigger a run
now? Manually via
https://github.com/openjdk-bots/jdk21/actions/workflows/main.yml and use the
Hi all,
This pull request contains a backport of commit
[8aad881e](https://github.com/openjdk/jdk/commit/8aad881e803fddc26f45270f779ff0c0e5a095d8)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Christian Stein on 13 Jun 2023
On Wed, 14 Jun 2023 09:49:33 GMT, Thomas Stuefe wrote:
> Do you know why this helped?
No, unfortunately not: _"Switching from 11 to 17 seems to mend the (unknown
underlying) issue for the time being."_
A test build using the same JDK as pre-installed on GitHub-hosted runners on my
local
On Tue, 13 Jun 2023 13:38:16 GMT, Christian Stein wrote:
> Please review this change to use the pre-installed JDK 17 for building jtreg
> when running on GitHub Actions.
This pull request has now been integrated.
Changeset: 8aad881e
Author:Christian Stein
URL:
> Please review this change to use the pre-installed JDK 17 for building jtreg
> when running on GitHub Actions.
Christian Stein has updated the pull request incrementally with one additional
commit since the last revision:
Update action.yml
-
Changes:
- all:
Please review this change to use the pre-installed JDK 17 for building jtreg
when running on GitHub Actions.
-
Commit messages:
- Use JDK 17 to build jtreg
Changes: https://git.openjdk.org/jdk/pull/14448/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=14448=00
Issue:
On Mon, 13 Mar 2023 08:16:54 GMT, Christian Stein wrote:
> This pull request addresses the open ends left by
> [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
>
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt`
On Mon, 13 Mar 2023 08:16:54 GMT, Christian Stein wrote:
> This pull request addresses the open ends left by
> [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
>
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt`
shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module
Christian Stein has updated the pull request incrementally with one additional
commit since the last revision:
Up
shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module
Christian Stein has updated the pull request incrementally with one additional
commit since the last revision:
Up
On Mon, 17 Apr 2023 14:56:16 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.2.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
On Sat, 22 Apr 2023 12:15:38 GMT, Christian Stein wrote:
>> This pull request addresses the open ends left by
>> [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
>> - #11272
>>
>> Changes:
>> - [x] Extend list of targeted exports o
On Mon, 17 Apr 2023 14:56:16 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.2.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module
Christian Stein has updated the pull request incrementally with five additional
commits since the last revision:
- F
On Sat, 22 Apr 2023 12:15:38 GMT, Christian Stein wrote:
>> This pull request addresses the open ends left by
>> [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
>> - #11272
>>
>> Changes:
>> - [x] Extend list of targeted exports o
shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module
Christian Stein has updated the pull request incrementally with five additional
commits since the last revision:
- F
shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module
Christian Stein has updated the pull request incrementally with one additional
commit since the last revisio
shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module
Christian Stein has updated the pull request incrementally with one additional
commit since the last revisio
shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module
Christian Stein has updated the pull request incrementally with one additional
commit since the last revision:
Upda
shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module
Christian Stein has updated the pull request incrementally with one additional
commit since the last revision:
Upda
shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module
Christian Stein has updated the pull request incrementally with one additional
commit since the last r
On Fri, 21 Apr 2023 21:42:58 GMT, Mandy Chung wrote:
>> Christian Stein 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 contain
On Fri, 21 Apr 2023 21:42:58 GMT, Mandy Chung wrote:
>> Christian Stein 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 contain
shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module
Christian Stein has updated the pull request incrementally with one additional
commit since the last r
shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module
Christian Stein has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev
shared `CommandLine.java` in `jdk.compiler` module
> - [x] Use shared `CommandLine.java` in `jdk.javadoc` module
> - [x] Remove `CommandLine.java` from `jdk.compiler` module
Christian Stein has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev
On Mon, 13 Mar 2023 08:16:54 GMT, Christian Stein wrote:
> This pull request addresses the open ends left by
> [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
>
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt`
On Mon, 13 Mar 2023 08:16:54 GMT, Christian Stein wrote:
> This pull request addresses the open ends left by
> [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
> - #11272
>
> Changes:
> - [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt`
On Fri, 21 Apr 2023 16:44:13 GMT, Roger Riggs wrote:
> Create an internal Version record to hold and compare versions of the form
> (major, minor, micro).
> Add `OperatingSystem.version()` to return the version of the running OS.
> Replace uses of os.version in java.base.
> Subsequent PRs will
On Fri, 21 Apr 2023 16:44:13 GMT, Roger Riggs wrote:
> Create an internal Version record to hold and compare versions of the form
> (major, minor, micro).
> Add `OperatingSystem.version()` to return the version of the running OS.
> Replace uses of os.version in java.base.
> Subsequent PRs will
1 - 100 of 507 matches
Mail list logo
