Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]

On Fri, 22 Aug 2025 15:41:21 GMT, Albert Mingkun Yang wrote: >> Leo Korinth has updated the pull request incrementally with one additional >> commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/hotspot/jtreg/compiler/tiered/Level2RecompilationT

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race wrote: >> Leo Korinth has updated the pull request incrementally with one additional >> commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie wrote: > I realize that this is highly hardware dependent, but test times tend to be > Pareto distributed, so a very quick test maybe takes 1 second on fast > machines and 10 on slow, @magicus unfortunately that is often not the case in pra

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan wrote: >> No change should be made to any explicit setting of the timeoutFactor in >> general as that could cause mass timeouts to occur (old default timeout = >> 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). >> >> However I see the concern o

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]

On Tue, 19 Aug 2025 05:23:15 GMT, David Holmes wrote: >> Take test >> test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as >> example. >> If there is a bug in jvm with -Xcomp option which will cause this test run >> time outed. Before

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add >> timeouts to individual test cases so that I am able to run them with a >> timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to cha

Re: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]

On Tue, 19 Aug 2025 03:31:55 GMT, SendaoYan wrote: >> It is also something that can be changed later, in a follow up fix. > > Take test > test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as > example. > If there is a bug in jvm with -Xcomp option which will cause this test

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

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: 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 [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

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

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 "

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: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

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: 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: 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

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: 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: 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

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: 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: 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: 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: [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

[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 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] 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

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

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

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 [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

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

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: 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

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: 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: 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: 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: 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: 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

[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: [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

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

[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

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) &

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

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

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

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: 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 ? >

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

[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: [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] 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: 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

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: 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: 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

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

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: 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

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

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

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

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

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: 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

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

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/

[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". >

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] 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: 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

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: 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: [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: 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()

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: 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

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: [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

[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

  1   2   >