[jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC

Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: The Java manpage was missing updates from: - [JDK-8282018](https://bugs

Re: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC

On Mon, 18 Jul 2022 15:26:23 GMT, Jonathan Gibbons wrote: >> Please review these changes to the nroff manpage files so that they match >> their markdown sources that Oracle maintains. >> >> All pages at a minimum have 19-ea replaced with 19, and copyright set to >> 2022 if needed. Additionall

[jdk19] Integrated: 8278274: Update nroff pages in JDK 19 before RC

On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes wrote: > Please review these changes to the nroff manpage files so that they match > their markdown sources that Oracle maintains. > > All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 > if needed

Re: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC

On Mon, 18 Jul 2022 23:27:58 GMT, David Holmes wrote: >> src/java.base/share/man/keytool.1 line 456: >> >>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the >>> 455: keystore. >>> 456: This option is used to sign the certificate

RFR: 8290489: Initial nroff manpage generation for JDK 20

The version will be 20-ea and the copyright year 2023 (for March 2023 release date). Thanks. - Commit messages: - 8290489: Initial nroff manpage generation for JDK 20 Changes: https://git.openjdk.org/jdk/pull/9581/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9581&range=

Re: RFR: 8290489: Initial nroff manpage generation for JDK 20

On Thu, 21 Jul 2022 01:03:46 GMT, Daniel D. Daugherty wrote: >> The version will be 20-ea and the copyright year 2023 (for March 2023 >> release date). >> >> Thanks. > > Thumbs up. This is a trivial change. Thanks @dcubed-ojdk ! - PR: https://git.openjdk.org/jdk/pull/9581

Integrated: 8290489: Initial nroff manpage generation for JDK 20

On Thu, 21 Jul 2022 00:34:53 GMT, David Holmes wrote: > The version will be 20-ea and the copyright year 2023 (for March 2023 release > date). > > Thanks. This pull request has now been integrated. Changeset: e9f97b2e Author:David Holmes URL: https://git.openjdk.or

Re: suggest improvement for java doc for getting address of local host

On 5/08/2022 8:24 am, mark.yagnatin...@barclays.com wrote: I suspect that this is the wrong list; please redirect me if so. Redirected to net-dev Cheers, David The docs for this method: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/net/InetAddress.html#getLocalHost()

Re: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC

Hi Patrick, On 6/08/2022 7:05 pm, Patrick Pfeifer wrote: On Mon, 18 Jul 2022 15:22:01 GMT, Jonathan Gibbons wrote: Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. Not a problem with this PR as such, but we still have a

Re: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java

On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons wrote: > Please review an update for the troff man pages, following the recent update > to upgrade to use pandoc 2.19.2 > (See https://bugs.openjdk.org/browse/JDK-8297165) > > In conjunction with this, one javadoc test also needs to be updated,

Re: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java

On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons wrote: > Please review an update for the troff man pages, following the recent update > to upgrade to use pandoc 2.19.2 > (See https://bugs.openjdk.org/browse/JDK-8297165) > > In conjunction with this, one javadoc test also needs to be updated,

Re: RFR: 8015831: Add lint check for calling overridable methods from a constructor

On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs wrote: > This PR adds a new lint warning category `this-escape`. > > It also adds `@SuppressWarnings` annotations as needed to the JDK itself to > allow the JDK to continue to compile with `-Xlint:all`. > > A 'this' escape warning is generated f

Re: RFR: 8015831: Add lint check for calling overridable methods from a constructor [v5]

On Sat, 7 Jan 2023 21:08:07 GMT, Archie L. Cobbs wrote: >> This PR adds a new lint warning category `this-escape`. >> >> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to >> allow the JDK to continue to compile with `-Xlint:all`. >> >> A 'this' escape warning is gener

[jdk20] RFR: 8290919: Update nroff pages in JDK 20 before RC

There was one missing update in javac.1 from: [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate -profile option in javac otherwise the change is limited to dropping the "-ea". Thanks. - Commit messages: - Merge branch 'master' into 8290919-manpages - 8290919:

Re: [jdk20] RFR: 8290919: Update nroff pages in JDK 20 before RC

On Mon, 23 Jan 2023 07:15:08 GMT, Iris Clark wrote: >> There was one missing update in javac.1 from: >> >> [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate >> -profile option in javac >> >> otherwise the change is limited to dropping the "-ea". >> >> Thanks. > > Marked as

[jdk20] Integrated: 8290919: Update nroff pages in JDK 20 before RC

On Mon, 23 Jan 2023 02:59:42 GMT, David Holmes wrote: > There was one missing update in javac.1 from: > > [JDK-8245246](https://bugs.openjdk.org/browse/JDK-8245246): Deprecate > -profile option in javac > > otherwise the change is limited to dropping the "-ea". >

RFR: 8290918: Initial nroff manpage generation for JDK 21

Please review this simple update to the manpage to set the version to 21-ea. This change also corrects a typo in javac.1 that was manually introduced by JDK-8300591 Thanks. - Commit messages: - 8290918: Initial nroff manpage generation for JDK 21 Changes: https://git.openjdk.org/

Re: RFR: 8290918: Initial nroff manpage generation for JDK 21

On Mon, 23 Jan 2023 23:24:06 GMT, Lance Andersen wrote: >> Please review this simple update to the manpage to set the version to 21-ea. >> >> This change also corrects a typo in javac.1 that was manually introduced by >> JDK-8300591 >> >> Thanks. > > Marked as reviewed by lancea (Reviewer). T

Re: RFR: 8290918: Initial nroff manpage generation for JDK 21

On Tue, 24 Jan 2023 01:28:53 GMT, Iris Clark wrote: >> Please review this simple update to the manpage to set the version to 21-ea. >> >> This change also corrects a typo in javac.1 that was manually introduced by >> JDK-8300591 >> >> Thanks. > > Marked as reviewed by iris (Reviewer). Thanks

Re: RFR: 8290918: Initial nroff manpage generation for JDK 21

On Tue, 24 Jan 2023 05:54:44 GMT, Joe Darcy wrote: >> Please review this simple update to the manpage to set the version to 21-ea. >> >> This change also corrects a typo in javac.1 that was manually introduced by >> JDK-8300591 >> >> Thanks. > > Marked as reviewed by darcy (Reviewer). Thanks

Integrated: 8290918: Initial nroff manpage generation for JDK 21

On Mon, 23 Jan 2023 22:59:22 GMT, David Holmes wrote: > Please review this simple update to the manpage to set the version to 21-ea. > > This change also corrects a typo in javac.1 that was manually introduced by > JDK-8300591 > > Thanks. This pull request has now been inte

Re: RFR: 8303485: Replacing os.name for operating system customization

On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote: > Improvements to support OS specific customization for JDK internal use: > - To select values and code; allowing elimination of unused code and values > - Optionally evaluated by build processes, compilation, or archiving (i.e. > CDS) > - S

Re: RFR: 8303485: Replacing os.name for operating system customization

On Thu, 9 Mar 2023 16:01:21 GMT, Roger Riggs wrote: >> src/java.base/share/classes/jdk/internal/misc/OperatingSystem.java line 74: >> >>> 72: * The Mac OS X Operating system. >>> 73: */ >>> 74: Mac("Mac OS X"), >> >> The current spelling used by Apple is "macOS", probably to align

Re: RFR: 8303485: Replacing os.name for operating system customization

The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. -- On Thu, 9 Mar 2023 16:12:26 GMT, Roger Riggs wrote:

Re: RFR: 8303485: Replacing os.name for operating system customization

On Thu, 9 Mar 2023 17:12:53 GMT, Roger Riggs wrote: >>> I would argue that we should keep the replacement string matching the make >>> variable its getting the value from. It makes it easier to trace the origin >>> of the value. >> >> Then we can define a new make variable that will also allow

Re: RFR: 8303485: Replacing os.name for operating system customization

On Thu, 9 Mar 2023 17:18:35 GMT, Roger Riggs wrote: >> That would not yield a compile time constant. >> The TARGET_IS_XXX values must evaluate to compile time constants as >> evaluated by javac. > > Using the naming from the build makes it clearer that there is a dependency > between the build

Re: RFR: 8303485: Replacing os.name for operating system customization

On Fri, 10 Mar 2023 05:09:49 GMT, Mandy Chung wrote: >> Don't we have a conditional compilation ability with these template files >> such that we can just generate true or false depending on the OS? > > Good point. `OperatingSystemProps.java` can be a OS-specific class like: > > src/java.base

Re: RFR: 8303485: Replacing os.name for operating system customization [v6]

On 25/03/2023 3:06 am, Roger Riggs wrote: On Fri, 24 Mar 2023 16:53:05 GMT, Michael Osipov wrote: If you are referring to "Red Hat Enterprise Linux", it'd be correct (AFAIK) to say that Red Hat identifies "Red Hat Enterprise Linux" as an operating system, but I wouldn't go so far as to say th

RFR: 8304478: Initial nroff manpage generation for JDK 22

Updated the version to 22-ea and year to 2024. The following unpublished changes will also be included in this update: - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update ja

Re: RFR: 8304478: Initial nroff manpage generation for JDK 22

On Wed, 14 Jun 2023 06:08:59 GMT, Alan Bateman wrote: >> Updated the version to 22-ea and year to 2024. >> >> The following unpublished changes will also be included in this update: >> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool >> manpage contains a special character

Re: RFR: 8304478: Initial nroff manpage generation for JDK 22

On Wed, 14 Jun 2023 19:21:01 GMT, Archie Cobbs wrote: > Just curious, since you have access to the secret closed sources, can you not > backport these changes yourself? Instead of just deleting them and expecting > someone else to rescue them from oblivion? @archiecobbs we (Oracle) will take

Re: RFR: 8304478: Initial nroff manpage generation for JDK 22

On Wed, 14 Jun 2023 09:25:14 GMT, Serguei Spitsyn wrote: >> Updated the version to 22-ea and year to 2024. >> >> The following unpublished changes will also be included in this update: >> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool >> manpage contains a special charact

Re: RFR: 8304478: Initial nroff manpage generation for JDK 22

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage > contains a sp

Re: RFR: 8304478: Initial nroff manpage generation for JDK 22 [v2]

code > - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check > for calling overridable methods from a constructor > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Pick up javac and jshell chan

Re: RFR: 8304478: Initial nroff manpage generation for JDK 22

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage > contains a sp

Integrated: 8304478: Initial nroff manpage generation for JDK 22

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage > contains a sp

Re: RFR: 8304478: Initial nroff manpage generation for JDK 22

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > Updated the version to 22-ea and year to 2024. > > The following unpublished changes will also be included in this update: > - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage > contains a sp

Re: RFR: 8311043: Remove trailing blank lines in source files

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the > files are "dirty" to begin with. This fix will make more files "clean". I > also considered adding a check for t

Re: RFR: 8311043: Remove trailing blank lines in source files

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote: > Remove trailing "blank" lines in source files. > > I like to use global-whitespace-cleanup-mode, but I can not use it if the > files are "dirty" to begin with. This fix will make more files "clean". I > also considered adding a check for t

Re: RFR: 8311043: Remove trailing blank lines in source files

On Thu, 29 Jun 2023 13:05:58 GMT, Leo Korinth wrote: > My changes look like this in the diff output > ``` > } > - > ``` Thanks for showing this and other output. To me this looked like the final newline had been removed. I would have expected to see something that more obviously showed more

[jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC

Main changes are to use 21 instead of 21-ea. In addition the following files contain additional updates from the closed sources: - src/java.base/share/man/java.1 [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion [JDK

Re: [jdk21] RFR: 8300937: Update nroff pages in JDK 21 before RC

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes wrote: > Main changes are to use 21 instead of 21-ea. In addition the following files > contain additional updates from the closed sources: > > - src/java.base/share/man/java.1 > > [JDK-8273131](https://bugs.openjdk.org/

[jdk21] Integrated: 8300937: Update nroff pages in JDK 21 before RC

On Mon, 31 Jul 2023 08:33:07 GMT, David Holmes wrote: > Main changes are to use 21 instead of 21-ea. In addition the following files > contain additional updates from the closed sources: > > - src/java.base/share/man/java.1 > > [JDK-8273131](https://bugs.openjdk.org/

Re: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase [v2]

On Wed, 23 Aug 2023 15:18:03 GMT, Matthias Baesken wrote: >> Currently there is a number of functionality that would be interesting to >> have for shared lib load operations in the JDK C code. >> Some examples : >> Events::log_dll_message for hs-err files reporting >> JFR event NativeLibraryLoad

Re: RFR: 8267174: Many test files have the wrong Copyright header

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote: > There are a number of files in the `test` directory that have an incorrect > copyright header, which includes the "classpath" exception text. This patch > removes that text from all test files that I could find it in. I did this > using a

Re: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase [v2]

On Mon, 16 Oct 2023 15:04:51 GMT, Matthias Baesken wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> windows aarch64 build issues > > Hello, any comments about the idea of calling into 'os::dll_load' instead ? >

RFR: 8322065: Initial nroff manpage generation for JDK 23

Updated the version to 23-ea and year to 2024. This initial generation also picks up the unpublished changes from: - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner) - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport) - [JDK-8

Re: RFR: 8322065: Initial nroff manpage generation for JDK 23

On Thu, 14 Dec 2023 09:17:05 GMT, Pavel Rappo wrote: > Thanks for doing this, David. I only note that the changes for JDK-8321384 > were published in [JDK-8308715](https://bugs.openjdk.org/browse/JDK-8308715), > which was integrated in the mainline before JDK 22 RDP 1. So they are already > pr

Re: RFR: 8322065: Initial nroff manpage generation for JDK 23

On Thu, 14 Dec 2023 09:01:17 GMT, Alan Bateman wrote: > Initially I wondered if JDK-8309981 should be separated but include keeps > things in sync so I think okay. Thanks for the review @AlanBateman . Yeah I was in two minds there myself. I started fixing [JDK-8309981](https://bugs.openjdk.or

Re: RFR: 8322065: Initial nroff manpage generation for JDK 23 [v2]

702) (javadoc) (JDK > 23 backport) > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Revert "8309981: Remove expired flags in JDK 23" This reverts commit 0324a90e936ae01e42ae099e7235156326cc3

Integrated: 8322065: Initial nroff manpage generation for JDK 23

On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes wrote: > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & > jarsigner) &

[jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC

This update drops the "ea" from the version string. We also propagate the following fixes from the markdown sources to the troff manpage file: JDK-8322478: Update java manpage for multi-file source-code launcher JDK-8302233: HSS/LMS: keytool and jarsigner changes JDK-8318971: Better Error Handli

Re: RFR: 8325163: Enable -Wpedantic on clang

On Mon, 5 Feb 2024 03:07:43 GMT, Kim Barrett wrote: > I consider the "format '%p' expects argument of type 'void*" warnings to be > not at all helpful. Fortunately we don't use '%p' in HotSpot, We do use it in hotspot. Not a huge amount as we have the legacy format specifiers for PTR_FORMAT et

Re: [jdk22] RFR: 8322066: Update troff manpages in JDK 22 before RC

On Mon, 5 Feb 2024 21:58:23 GMT, Joe Darcy wrote: >> This update drops the "ea" from the version string. >> >> We also propagate the following fixes from the markdown sources to the troff >> manpage file: >> >> JDK-8322478: Update java manpage for multi-file source-code launcher >> JDK-8302233

[jdk22] Integrated: 8322066: Update troff manpages in JDK 22 before RC

On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote: > This update drops the "ea" from the version string. > > We also propagate the following fixes from the markdown sources to the troff > manpage file: > > JDK-8322478: Update java manpage for multi-file source

Re: RFR: 8325163: Enable -Wpedantic on clang

On Mon, 5 Feb 2024 15:42:40 GMT, Kim Barrett wrote: > I thought we didn't, because we were instead supposed to use INTPTR_FORMAT and the (currently?) equivalent PTR_FORMAT. Those macros aren't legacy, they are to provide consistent output across platforms. "%p" provides implementation defined out

Re: RFR: 8325163: Enable -Wpedantic on clang [v2]

On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote: >> Inspired by (the later backed-out) >> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to >> enable `-Wpedantic` for clang. This has already found some irregularities in >> the code, like mistakenly using `#impo

Re: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v3]

On Thu, 7 Mar 2024 03:00:11 GMT, Guoxiong Li wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Introduce windows jni_util_md.h > > src/java.base/aix/native/libnio/ch/Pollset.c line 3: > >> 1: /* >> 2: * Copyrig

Re: RFR: JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase [v4]

On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken wrote: >> We define the RESTARTABLE macro again and again at a lot of places in the >> JDK native codebase. This could be centralized to avoid repeating it again >> and again ! > > Matthias Baesken has updated the pull request incrementally with

Re: RFR: 8330205: Initial troff manpage generation for JDK 24

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote: > Please review this mechanical change to man pages. This PR should be > integrated after https://github.com/openjdk/jdk/pull/18787. I think we may have to restore this to a standalone start-of-release change done after the other start-of-rel

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v4]

On Tue, 14 May 2024 18:10:28 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loa

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v3]

On Mon, 13 May 2024 15:32:27 GMT, Alan Bateman wrote: >> Maurizio Cimadamore has updated the pull request incrementally with three >> additional commits since the last revision: >> >> - Fix another typo >> - Fix typo >> - Add more comments > > src/hotspot/share/runtime/arguments.cpp line 227

RFR: 8330205: Initial troff manpage generation for JDK 24

Sets the version to 24/24-ea and the copyright year to 2025. Content changes related to the start of release (e.g. for removed options in java.1) are handled separately. This initial generation also picks up the unpublished changes from: - JDK-8330807: Update Manpage for obsoletion of Scavenge

Re: RFR: 8330205: Initial troff manpage generation for JDK 24

On Mon, 10 Jun 2024 07:15:51 GMT, Alan Bateman wrote: >> Sets the version to 24/24-ea and the copyright year to 2025. >> >> Content changes related to the start of release (e.g. for removed options in >> java.1) are handled separately. >> >> This initial generation also picks up the unpublishe

Re: RFR: 8330205: Initial troff manpage generation for JDK 24 [v2]

0807: Update Manpage for obsoletion of ScavengeBeforeFullGC > - JDK-8284500: Typo in Supported Named Extensions - BasicContraints > - JDK-8324342: Doclet should default `@since` for a nested class to that of > its enclosing class > > Thanks David Holmes has updated the pull request with

Re: RFR: 8330205: Initial troff manpage generation for JDK 24 [v3]

0807: Update Manpage for obsoletion of ScavengeBeforeFullGC > - JDK-8284500: Typo in Supported Named Extensions - BasicContraints > - JDK-8324342: Doclet should default `@since` for a nested class to that of > its enclosing class > > Thanks David Holmes has updated the pull request in

Re: RFR: 8330205: Initial troff manpage generation for JDK 24 [v3]

On Mon, 10 Jun 2024 17:27:18 GMT, Iris Clark wrote: >> David Holmes has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Regenerated after merge > > Marked as reviewed by iris (Reviewer). Thanks for the revie

Integrated: 8330205: Initial troff manpage generation for JDK 24

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes wrote: > Sets the version to 24/24-ea and the copyright year to 2025. > > Content changes related to the start of release (e.g. for removed options in > java.1) are handled separately. > > This initial generation also picks

[jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC

Before RC we need to update the man pages in the repo from their Markdown sources. All pages at a minimum have 23-ea replaced with 23, and publication year set to 2024 if needed. This also picks up the unpublished changes to java.1 from: - [JDK-8324836](https://bugs.openjdk.org/browse/JDK-83248

Re: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC

On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote: > Before RC we need to update the man pages in the repo from their Markdown > sources. All pages at a minimum have 23-ea replaced with 23, and publication > year set to 2024 if needed. > > This also picks up the unpublished

[jdk23] Integrated: 8325280: Update troff manpages in JDK 23 before RC

On Fri, 19 Jul 2024 05:47:15 GMT, David Holmes wrote: > Before RC we need to update the man pages in the repo from their Markdown > sources. All pages at a minimum have 23-ea replaced with 23, and publication > year set to 2024 if needed. > > This also picks up the unpublished

Re: [jdk23] RFR: 8325280: Update troff manpages in JDK 23 before RC

On Fri, 19 Jul 2024 08:26:51 GMT, Alan Bateman wrote: >> Before RC we need to update the man pages in the repo from their Markdown >> sources. All pages at a minimum have 23-ea replaced with 23, and publication >> year set to 2024 if needed. >> >> This also picks up the unpublished changes to

Re: RFR: 8342682: Errors related to unused code on Windows after 8339120

On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote: > and whatever team is responsible for HotSpot debugging. I don't see anything hotspot related here. I think you would be better off splitting this up into distinct issues and PRs for different areas. I expect the client team in particular

Re: RFR: 8342682: Errors related to unused code on Windows after 8339120

On Tue, 22 Oct 2024 01:43:50 GMT, Julian Waters wrote: > Aren't the dt_shmem and jdwp changes related to HotSpot? Nope. That's core-svc - the non-hotspot side of serviceability. :) - PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2428793636

Re: RFR: 8342868: Errors related to unused code on Windows after 8339120 in core libs

On Wed, 23 Oct 2024 04:40:50 GMT, Julian Waters wrote: > After 8339120, gcc began catching many different instances of unused code in > the Windows specific codebase. Some of these seem to be bugs. I've taken the > effort to mark out all the relevant globals and locals that trigger the > unuse

Re: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage

On Thu, 24 Oct 2024 03:33:51 GMT, Julian Waters wrote: > the way I did it I'd have to force push That should not be the case. You can just anti-delta changes. - PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2434475849

Re: RFR: 8344056: Use markdown format for man pages [v2]

On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open >> repo, and a content-wise identical copy is stored as markdown (another text >> format) in the closed repo. >> >> Since markdown is preferred to troff in te

Re: RFR: 8344056: Use markdown format for man pages [v2]

On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open >> repo, and a content-wise identical copy is stored as markdown (another text >> format) in the closed repo. >> >> Since markdown is preferred to troff in te

Re: RFR: 8344056: Use markdown format for man pages

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open > repo, and a content-wise identical copy is stored as markdown (another text > format) in the closed repo. > > Since markdown is preferred to troff in terms o

Re: RFR: 8344191: Build code should not have classpath exception

On Fri, 15 Nov 2024 00:07:07 GMT, Magnus Ihse Bursie wrote: > The policy has long been to use Classpath Exception in the `src` and `make` > directories, but not in the `test` directories. If you're changing the > policy, you might want to check and update any documentation where the policy > m

Integrated: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes wrote: > This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. > > JDK-8348190: Framework for tracing makefile inclusion and parsing > > The above issue caused problems in the Oracle closed builds and so needs to > be bac

Re: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

On Thu, 6 Feb 2025 02:01:47 GMT, Joe Darcy wrote: >> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. >> >> JDK-8348190: Framework for tracing makefile inclusion and parsing >> >> The above issue caused problems in the Oracle closed builds and so needs to >> be backed out until th

Re: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

On Thu, 6 Feb 2025 02:48:21 GMT, Mikael Vidstedt wrote: >> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. >> >> JDK-8348190: Framework for tracing makefile inclusion and parsing >> >> The above issue caused problems in the Oracle closed builds and so needs to >> be backed out un

RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4. JDK-8348190: Framework for tracing makefile inclusion and parsing The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed. Thanks. - Commit messages: - Revert "

Re: RFR: 8345805: Update copyright year to 2024 for other files where it was missed [v2]

On Mon, 9 Dec 2024 21:02:03 GMT, Magnus Ihse Bursie wrote: >> Some files have been modified in 2024, but the copyright year has not been >> properly updated. This should be fixed. >> >> I have located these modified files using: >> >> git log --since="Jan 1" --name-only --pretty=format: | sor

Re: RFR: 8347840: Fix testlibrary compilation warnings

On Wed, 15 Jan 2025 23:48:33 GMT, Leonid Mesnik wrote: > There few compiler warning disabled in the testlibary build. > They should be fixed or localized and removed from build to prevent new > possible issues. > > The main goal is to avoid new such issues in the testlibrary. > Tested with tie

Re: RFR: 8347840: Fix testlibrary compilation warnings [v3]

On Thu, 16 Jan 2025 17:53:48 GMT, Leonid Mesnik wrote: >> test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java line 46: >> >>> 44: public int getInt(long pos) throws IOException; >>> 45: public long getLong(long pos) throws IOException; >>> 46: public void close() throws IOExceptio

Re: RFR: 8347840: Fix testlibrary compilation warnings [v3]

On Thu, 16 Jan 2025 18:18:15 GMT, Leonid Mesnik wrote: >> There few compiler warning disabled in the testlibary build. >> They should be fixed or localized and removed from build to prevent new >> possible issues. >> >> The main goal is to avoid new such issues in the testlibrary. >> Tested wi

Re: RFR: 8351322: Parameterize link option for pthreads [v2]

On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes wrote: >>> What is the intended way of using this? Do you run make with >>> LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the >>> specific way of linking to pthread? >> >> This is in prep

Re: RFR: 8351322: Parameterize link option for pthreads [v2]

On Thu, 20 Mar 2025 12:38:37 GMT, Magnus Ihse Bursie wrote: > Is there any gain then in changing away from -lpthread? That is clearly > defined, link with libpthread, with no side effects. "If it ain't broke..." True - what we have works and using `-pthread` might subtly change things. ---

Re: RFR: 8351322: Parameterize link option for pthreads

On Thu, 6 Mar 2025 15:47:58 GMT, Magnus Ihse Bursie wrote: >> What is the intended way of using this? Do you run make with >> `LIBPTHREAD=-pthread` or do you apply a patch on `libraries.m4` for the >> specific way of linking to pthread? > >> What is the intended way of using this? Do you run ma

Re: RFR: 8351322: Parameterize link option for pthreads

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 wrote: > Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's > possible to parameterize this for platforms that use different flags for > enabling posix threads. > > This work is a continuation of the work done by Greg Lewis in

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to > run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests > and test the

Re: RFR: 8342868: Errors related to unused code on Windows after 8339120 in core libs [v2]

On Tue, 8 Jul 2025 01:28:04 GMT, Julian Waters wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove the got local > > Sorry for waiting so long. It's become clear that I won't be able to get awt > and accessibi