On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang wrote:
>> Provide a general facility for our null check APIs like
>> Objects::requireNonNull or future Checks::nullCheck (void), converting the
>> existing infrastructure to start tracking from a given stack site (depth
>> offset) and a given stack s
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
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
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
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
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
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
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
On Tue, 5 Aug 2025 10:16:32 GMT, Johan Sjölen wrote:
>> src/hotspot/share/interpreter/bytecodeUtils.cpp line 1483:
>>
>>> 1481: // Is an explicit slot given?
>>> 1482: bool explicit_search = slot >= 0;
>>> 1483: if (explicit_search) {
>>
>> Suggestion:
>>
>> if (slot >= 0) {
>>
>> No
On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang wrote:
> Provide a general facility for our null check APIs like
> Objects::requireNonNull or future Checks::nullCheck (void), converting the
> existing infrastructure to start tracking from a given stack site (depth
> offset) and a given stack slot
On Fri, 1 Aug 2025 15:49:57 GMT, Chen Liang wrote:
> Provide a general facility for our null check APIs like
> Objects::requireNonNull or future Checks::nullCheck (void), converting the
> existing infrastructure to start tracking from a given stack site (depth
> offset) and a given stack slot
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
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
On Wed, 19 Mar 2025 01:54:19 GMT, Weijun Wang wrote:
> A certificate created in the test will expire on 2026-03-20. This change adds
> another 2000 days to it.
Okay lets fix this as-is for now. Making it future-proof would be nice as a
future RFE.
Thanks for the quick fix.
-
Mar
On Wed, 19 Mar 2025 01:54:19 GMT, Weijun Wang wrote:
> A certificate created in the test will expire on 2026-03-20. This change adds
> another 2000 days to it.
To future-proof this couldn't we set the expiration date based on the current
date minus X days?
I meant the start date sorry
--
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
On Mon, 9 Dec 2024 21:09:41 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
On Mon, 18 Nov 2024 12:39:32 GMT, Coleen Phillimore wrote:
>> I don't see any difference in the callers in relation to this PR and the
>> function is not presently declared `extern`. ??
>
> There was an extern trace_class_resolution() function that called this _impl
> function that I removed, s
On Fri, 15 Nov 2024 12:04:37 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvm.cpp line 154:
>>
>>> 152: */
>>> 153:
>>> 154: extern void trace_class_resolution(Klass* to_class) {
>>
>> why `extern` ?
>
> jni.cpp functions call this.
I don't see any difference in the callers in rel
On Sat, 16 Nov 2024 14:25:30 GMT, Coleen Phillimore wrote:
>> Remove Hotspot code that passes protection_domain around class loading so
>> that checkPackageAccess can be called and the result stored. With the
>> removal of the Security Manager in JEP 486, this code no longer does
>> anything.
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
On Thu, 14 Nov 2024 16:02:56 GMT, Coleen Phillimore wrote:
>> Remove Hotspot code that passes protection_domain around class loading so
>> that checkPackageAccess can be called and the result stored. With the
>> removal of the Security Manager in JEP 486, this code no longer does
>> anything.
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
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
On Thu, 14 Nov 2024 07:01:54 GMT, Alan Bateman wrote:
> > To be fair I'm unclear what role PD still plays on the JDK side and would
> > not be surprised if it is destined for removal at some point.
>
> PD is not deprecated as PD::getCodeSource is widely used. It may be that an
> alternative me
On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote:
> Remove Hotspot code that passes protection_domain around class loading so
> that checkPackageAccess can be called and the result stored. With the
> removal of the Security Manager in JEP 486, this code no longer does anything.
>
> T
On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote:
> Remove Hotspot code that passes protection_domain around class loading so
> that checkPackageAccess can be called and the result stored. With the
> removal of the Security Manager in JEP 486, this code no longer does anything.
>
> T
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
On Tue, 12 Nov 2024 01:25:16 GMT, Shaojin Wen wrote:
> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
> offset overflow issue has been fixed.
>
> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
> reduce duplication
>
> HexDigits and OctalDi
On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer wrote:
> I do wonder if mutex support can be implemented for Windows with
> Acquire/ReleaseSRWLockExclusive.
A `CriticalSection` is a mutex. A RWLock is not a "mutex".
-
PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecommen
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
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
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
On Tue, 10 Sep 2024 11:10:38 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this trivial change which replaces the usages
>> of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are
>> o
On Tue, 10 Sep 2024 11:07:30 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this trivial change which replaces the usages
>> of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are
>> o
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start when compiling using
>>
On Mon, 22 Jul 2024 21:40:15 GMT, Weijun Wang wrote:
> The test sets system properties. Should run in `othervm`.
Seems reasonable. I assume the actual conf file being written will be in the
test's scratch directory so no interference possible with other tests?
-
Marked as reviewed
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
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
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
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
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start when compiling using
>>
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
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
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
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
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
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
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
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
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
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
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
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
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)
&
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
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
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
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
On Tue, 7 Nov 2023 11:11:31 GMT, Erik Gahlin wrote:
>> Could I have a review of a PR that removes the bytecode instrumentation for
>> the exception events.
>>
>> Testing: jdk/jdk/jfr + tier1 + tier2
>
> Erik Gahlin has updated the pull request incrementally with one additional
> commit since t
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 ?
>
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
On Wed, 30 Aug 2023 11:31:20 GMT, Mark Sheppard wrote:
> So you could create a single createJavaProcessBuilder with add an additional
> parameter boolean addTestOpts e.g.
createJavaProcessBuilder(List command, boolean addTestOpts) { ... }
@msheppar that is actually where we started, and it was
On Tue, 29 Aug 2023 16:45:12 GMT, Roger Riggs wrote:
>> I don't think this is the best change across so many files.
>> It gives a very ugly name to a common test function and affects a very large
>> number of tests.
>
>> @RogerRiggs If it is only the name you want changed, maybe you can offer a
On Mon, 28 Aug 2023 15:54:08 GMT, Leo Korinth wrote:
> Rename createJavaProcessBuilder so that it is not used by mistake instead of
> createTestJvm.
>
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed
> -i -e
> "s/createJavaProcessBuilder(/createJavaProcessBuilderI
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
On Tue, 8 Aug 2023 19:52:08 GMT, Thomas Stuefe wrote:
>> I just checked and the value of the sentinel is ultimately the prvalue 88. I
>> don't know if we'd want to replace all the weird char usages here with
>> explicit values of 0 (and 88 for the sentinel). Maybe future reviews can
>> help wi
On Tue, 1 Aug 2023 08:16:41 GMT, Julian Waters wrote:
>> src/hotspot/share/memory/allocation.cpp line 114:
>>
>>> 112: //
>>> 113:
>>> 114: void* AnyObj::operator new(size_t size, Arena *arena) {
>>
>> Please remind us what the issue is with `throw()` as this is a change to
>> shared code and
On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done
>> with some effort, given that the signific
On Mon, 7 Aug 2023 06:37:21 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done
>> with some effort, given that the signific
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/
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/
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
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
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
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
On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote:
> Build failure after JDK- 8305341
Our tier 1 builds have passed.
Thanks
-
Marked as reviewed by dholmes (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/14645#pullrequestreview-1497595990
On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote:
> Build failure after JDK- 8305341
Okay I have it running through our tier1 builds at the moment. If that passes I
will approve the PR. Thanks
-
PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606580347
On Mon, 26 Jun 2023 04:23:58 GMT, Julian Waters wrote:
> as is evident in the tests for this PR
You mean the GHA builds? They don't seem to be building the failing
`jdk.jdwp.agent-static-libs` target.
-
PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606573575
On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote:
> Build failure after JDK- 8305341
How was the original change tested? How was this change tested?
-
PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606571300
On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters wrote:
> Microsoft, your C "conformance" is garbage
https://learn.microsoft.com/en-us/cpp/standard-library/cstdalign?view=msvc-170
-
PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606567568
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
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
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
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
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
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
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
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
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
On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona wrote:
> Most of the manpages were updated a few years ago but some references remain.
> This patch renames remaining references to "macOS".
>
> Please review.
>
> Thanks,
> Adam
Looks good.
-
Marked as reviewed by dholmes (Reviewer).
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
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
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
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
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/
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".
>
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
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:
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
1 - 100 of 123 matches
Mail list logo
