Document preconditions on certain `JavaLangAccess` methods that use operations
either unsafe and/or without range checks.
-
Commit messages:
- Improve `JavaLangAccess` documentation
Changes: https://git.openjdk.org/jdk/pull/24982/files
Webrev: https://webrevs.openjdk.org/?repo=jd
On Wed, 30 Apr 2025 21:49:12 GMT, Chen Liang wrote:
>> This is a general fix for all the "points to a static field that may hold a
>> different value" failures related to `java/lang/invoke/MethodHandleImpl`.
>> E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840),
>> [JDK-8353330](
On Thu, 1 May 2025 02:01:36 GMT, ExE Boss wrote:
>> Ioi Lam has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - @AlanBateman comments
>> - @xmas92 comments
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 314:
>
>> 312:
On Wed, 30 Apr 2025 17:45:04 GMT, Ioi Lam wrote:
>> This PR contains 2 parts
>>
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the
>> Leyden
>> repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjS
On Wed, 30 Apr 2025 19:18:57 GMT, Lance Andersen wrote:
> I think throwing the SkippedException is the right way to go long term but I
> assume this shows as a reported failure in Mach5 and in the case of
> assumeTrue it does not result in a failure being reported?
That is correct, use of ass
As another step toward the removal of the old generics infrastructure, I
propose to remove the usages of generic parsing utilities and use the
facilities provided by BytecodeDescriptor, already used by
MethodType.fromDescriptorString. This also prevents extra validation cost in
use sites to def
On Wed, 30 Apr 2025 15:01:08 GMT, Roger Riggs wrote:
>> Replace manual bitwise operations in `hashCode` implementations of
>> `java.time` with `Long::hashCode`.
>
> lgtm
> @RogerRiggs, @minborg, @naotoj, thanks for the reviews. I've attached
> successful `tier1,2` results to the ticket. I'd ap
Similar to #24959, java.util.Locale.hashCode can also make the same improvement.
Replace manual bitwise operations in hashCode implementations of
java.util.Locale with Double::hashCode.
-
Commit messages:
- Update src/java.base/share/classes/java/util/Locale.java
- Use Long::hashC
> Finalize the KDF API.
Weijun Wang has updated the pull request incrementally with two additional
commits since the last revision:
- add a positive debug log and update exception message
- enhancing exception messages and debug outputs
-
Changes:
- all: https://git.openjdk.org
On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen wrote:
> Similar to #24959, java.util.Locale.hashCode can also make the same
> improvement.
>
> Replace manual bitwise operations in hashCode implementations of
> java.util.Locale with Double::hashCode.
src/java.base/share/classes/java/util/Locale
This change proposes to modify `java.io.File.delete()` so that regular files on
Windows will not be deleted by default if their read-only attribute is set. A
boolean-valued system compatibility property `jdk.io.File.deleteReadOnly` is
defined to reinstate legacy behavior if desired.
---
> Use a thread-safe ReferencedKeySet instead of a WeakHashMap key set.
Chen Liang has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brought in
by the merge/rebase. The pull request contains three additional commi
On Wed, 26 Mar 2025 16:54:39 GMT, Jaikiran Pai wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>> commits
On Wed, 23 Apr 2025 14:12:29 GMT, Chen Liang wrote:
>> In offline discussion, we noted that the documentation on this annotation
>> does not recommend minimizing the intrinsified section and moving whatever
>> can be done in Java to Java; thus I prepared this documentation update, to
>> shrink
> Take the class file version to reject flags not yet defined, redefined, or
> obsoleted. This is useful for clients like javap to report the correct
> undefined flags for different class file versions.
>
> A preparatory patch for javap to pass around the ClassFileFormatVersion to
> parse flags
> In offline discussion, we noted that the documentation on this annotation
> does not recommend minimizing the intrinsified section and moving whatever
> can be done in Java to Java; thus I prepared this documentation update, to
> shrink a "TLDR" essay to something concise for readers, such as
This is a general fix for all the "points to a static field that may hold a
different value" failures related to `java/lang/invoke/MethodHandleImpl`. E.g.,
[JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840),
[JDK-8353330](https://bugs.openjdk.org/browse/JDK-8353330).
AOT-cached method h
On Wed, 30 Apr 2025 18:17:27 GMT, Chen Liang wrote:
>> Take the class file version to reject flags not yet defined, redefined, or
>> obsoleted. This is useful for clients like javap to report the correct
>> undefined flags for different class file versions.
>>
>> A preparatory patch for javap
On Wed, 23 Apr 2025 22:39:40 GMT, Chen Liang wrote:
> When LambdaForms are interpreted, so are field lambda forms. When this
> happens, we may get into an infinite recursion due to field lambda forms
> using `MethodHandleStatics.UNSAFE` via field lambda form.
>
> I think the best solution here
On Wed, 30 Apr 2025 18:03:29 GMT, Chen Liang wrote:
>> A prerequisite to #24760; this was part of it, but was split out to simplify
>> the review of the addition of `maskToAccessFlags(int, Location, CFFV)` by
>> minimizing the changes in javap. That patch will only need to update
>> `BasicWrit
On Tue, 29 Apr 2025 20:43:31 GMT, Chen Liang wrote:
> A prerequisite to #24760; this was part of it, but was split out to simplify
> the review of the addition of `maskToAccessFlags(int, Location, CFFV)` by
> minimizing the changes in javap. That patch will only need to update
> `BasicWriter`
On Tue, 29 Apr 2025 22:59:29 GMT, Ioi Lam wrote:
> This is a general fix for all the "points to a static field that may hold a
> different value" failures related to `java/lang/invoke/MethodHandleImpl`.
> E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840),
> [JDK-8353330](https:/
On Wed, 30 Apr 2025 17:59:55 GMT, Markus KARG wrote:
>> Could this be a Javadoc bug? What does a simple `{@inheritDoc}` do?
>
> Unfortunately the same happens. 🙁
The following javadoc for String's getChars method has, I believe, the desired
effect:
/**
* {@inheritDoc CharSequence}
On Wed, 23 Apr 2025 22:39:40 GMT, Chen Liang wrote:
> When LambdaForms are interpreted, so are field lambda forms. When this
> happens, we may get into an infinite recursion due to field lambda forms
> using `MethodHandleStatics.UNSAFE` via field lambda form.
>
> I think the best solution here
On Tue, 29 Apr 2025 22:59:29 GMT, Ioi Lam wrote:
> This is a general fix for all the "points to a static field that may hold a
> different value" failures related to `java/lang/invoke/MethodHandleImpl`.
> E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840),
> [JDK-8353330](https:/
On Wed, 30 Apr 2025 18:03:29 GMT, Chen Liang wrote:
>> A prerequisite to #24760; this was part of it, but was split out to simplify
>> the review of the addition of `maskToAccessFlags(int, Location, CFFV)` by
>> minimizing the changes in javap. That patch will only need to update
>> `BasicWrit
On Wed, 30 Apr 2025 20:38:59 GMT, Gautham Krishnan wrote:
>> In the following classes, month and day values are stored in fields of type
>> 'int' or 'short'. The range of allowed values is small enough that the type
>> can be 'byte' instead.
>>
>> java.time.YearMonth
>> java.time.MonthDay
>> j
Thanks, haven't seen unsigned right shift before. You're right, it should be
fine to use the unsigned one and hence Long.hashCode for that.
However, the docs should match the expression used in the implementation when
explicitly naming the returned expression. Should we update both to
Long.hash
Hi Steffen,
One other oddity about the shift operators in Java, they only use the
lower 5 bits of the shift distance argument.
So,
int x = 1024;
x >>4 == 64; and
x >> 36 == 64;
It is unusual to specify the algorithm used for hashcodes, though in
some cases backward compatibility has forced
On Wed, 30 Apr 2025 21:11:51 GMT, Roger Riggs wrote:
>> Gautham Krishnan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updating copyright header
>
> Its recommended to set the assignee of a issue before starting working and to
> mark
On Wed, 30 Apr 2025 20:38:59 GMT, Gautham Krishnan wrote:
>> In the following classes, month and day values are stored in fields of type
>> 'int' or 'short'. The range of allowed values is small enough that the type
>> can be 'byte' instead.
>>
>> java.time.YearMonth
>> java.time.MonthDay
>> j
Indeed, Archie is right. There are different levels of strictness in the
specification.
In this particular site, we have "the hash code is the value of the expression"
which only requires the return value to be equivalent. The implementation is
free to be anything.
In specifications, we usuall
On Wed, 30 Apr 2025 20:57:23 GMT, Gautham Krishnan wrote:
> But when I checked these classes use a custom Externalizable encoding (see
> 'readExternal'/'writeExternal'), which already stores these values as bytes.
Sorry, that is correct. Jumped the gun too soon
-
PR Comment: https
On Wed, 30 Apr 2025 20:50:34 GMT, Naoto Sato wrote:
>> Gautham Krishnan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updating copyright header
>
> Since they are serialized fields (except Hijrah ones), I don't think this is
> doable.
On Wed, 30 Apr 2025 20:17:57 GMT, Alexander Matveev
wrote:
> - Symbolic links will not be followed for `--app-content` on macOS.
> - Added test to cover this case.
> - `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG,
> since "cp -r" on macOS is not documented option and
On Wed, 30 Apr 2025 20:38:59 GMT, Gautham Krishnan wrote:
>> In the following classes, month and day values are stored in fields of type
>> 'int' or 'short'. The range of allowed values is small enough that the type
>> can be 'byte' instead.
>>
>> java.time.YearMonth
>> java.time.MonthDay
>> j
> The recent patch #23866 makes calling `ClassValue::remove()` from
> `ClassValue::computeValue()` end up in infinite loops while fixing the stale
> value risk from the method.
>
> The proposed fix is to preserve the stale value risk fix, and update the
> remove-from-compute behavior from the o
On Wed, Apr 30, 2025 at 3:38 PM Steffen Nießing
wrote:
> However, the docs should match the expression used in the implementation
> when explicitly naming the returned expression. Should we update both to
> Long.hashCode(this.getTime())?
>
I think that's a little too strong of a statement. Rathe
> In the following classes, month and day values are stored in fields of type
> 'int' or 'short'. The range of allowed values is small enough that the type
> can be 'byte' instead.
>
> java.time.YearMonth
> java.time.MonthDay
> java.time.LocalDate
> java.time.chono.HijrahDate
>
> Refactoring th
In the following classes, month and day values are stored in fields of type
'int' or 'short'. The range of allowed values is small enough that the type can
be 'byte' instead.
java.time.YearMonth
java.time.MonthDay
java.time.LocalDate
java.time.chono.HijrahDate
Refactoring the type will give the
Well, the sign has no impact here - the most significant 32 bits duplicated
from the original sign bit are immediately discarded in the subsequent int cast
truncation to the least significant 32 bits. However, how there is such a
difference from before OpenJDK was published is still intriguing.
On Tue, 29 Apr 2025 23:16:05 GMT, Kim Barrett wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> convert test to use WhiteBox
>
> test/jdk/java/lang/ref/FinalizerHistogramTest.java line 77:
>
>> 75: wb
> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear
> up the intermittent failures:
>
> * run with `othervm`: this test blocks the (global) finalizer thread, and
> also requires the (global) finalizer thread to enter the test's `finalize()`
> method
> * The test uses `
- Symbolic links will not be followed for `--app-content` on macOS.
- Added test to cover this case.
- `MacHelper` updated to use "cp -R" instead of "cp -r" when unpacking DMG,
since "cp -r" on macOS is not documented option and when used `cp` will follow
symbolic links which breaks test. "cp -R"
Interestingly, the implementation of Date.hashCode() does use the signed
right shift ">>".
Naoto
On 4/30/25 1:06 PM, Chen Liang wrote:
Indeed, Joe is right. Unsigned right shift does not appear often and is
equivalent to signed right shift if the sign bit is 0.
However, this piece of quote c
Indeed, Joe is right. Unsigned right shift does not appear often and is
equivalent to signed right shift if the sign bit is 0.
However, this piece of quote can get an upgrade - it can become
`Long.hashCode(this.getTime())`.
*
Chen
From: core-libs-dev on beh
Hello,
I'm new to the OpenJDK community and plan to make my first change.
I've found a small mistake in the documentation of java.util.Date#hashCode().
The documentation provides a Java expression of the returned value, which uses
a non-existent operator '>>>'.
Now I'm searching for a sponsor
Unsigned right shift is non-existent?
"The operators << (left shift), >> (signed right shift), and >>>
(unsigned right shift) are called the shift operators. The left-hand
operand of a shift operator is the value to be shifted; the right-hand
operand specifies the shift distance. "
https://d
On Tue, 29 Apr 2025 22:22:19 GMT, Vladimir Ivanov wrote:
> Can you point me, please, to the relevant parts of the discussions? I wasn't
> part of them.
Sorry, I can not find out this specific answer for you, as there were too long
discussion there, the whole process took several months.
> Bot
On Wed, 30 Apr 2025 11:00:04 GMT, Hamlin Li wrote:
> It's arguable if missing entries is a bug, please check
> [JDK-8355656](https://bugs.openjdk.org/browse/JDK-8355656) for example
Personally, I'm surprised SVML is affected in a similar way because stubs are
provided in assembly form, so they
On Tue, 29 Apr 2025 02:40:01 GMT, SendaoYan wrote:
>> Hi,
>> Can you help to review this patch?
>>
>> Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a
>> released jdk not supportting sleef (for any reason, e.g. low gcc version,
>> intrinsic not supported, rvv not suppo
On Tue, 29 Apr 2025 09:16:39 GMT, Hamlin Li wrote:
> This behavour was decided in previous PRs
> https://github.com/openjdk/jdk/pull/20781,
> https://github.com/openjdk/jdk/pull/21083,
> https://github.com/openjdk/jdk/pull/21502, and some other uncommited PRs
> prior to these ones.
Can you p
On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review this patch?
>
> Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a
> released jdk not supportting sleef (for any reason, e.g. low gcc version,
> intrinsic not supported, rvv not supported,
On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review this patch?
>
> Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a
> released jdk not supportting sleef (for any reason, e.g. low gcc version,
> intrinsic not supported, rvv not supported,
Hi,
Can you help to review this patch?
Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a
released jdk not supportting sleef (for any reason, e.g. low gcc version,
intrinsic not supported, rvv not supported, and so on) runs on machine support
vector operation (e.g. on ris
On Wed, 30 Apr 2025 14:20:37 GMT, Jaikiran Pai wrote:
>> test/jdk/java/util/zip/ZipFile/ZipFileCharsetTest.java line 68:
>>
>>> 66: // ISO-8859-15 is not a standard charset in Java. We skip this
>>> test
>>> 67: // when it is unavailable
>>> 68:
>>> assumeTrue(Charset.a
On Wed, 30 Apr 2025 18:17:27 GMT, Chen Liang wrote:
>> Take the class file version to reject flags not yet defined, redefined, or
>> obsoleted. This is useful for clients like javap to report the correct
>> undefined flags for different class file versions.
>>
>> A preparatory patch for javap
On Wed, 30 Apr 2025 17:45:04 GMT, Ioi Lam wrote:
>> This PR contains 2 parts
>>
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the
>> Leyden
>> repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjS
> Take the class file version to reject flags not yet defined, redefined, or
> obsoleted. This is useful for clients like javap to report the correct
> undefined flags for different class file versions.
>
> A preparatory patch for javap to pass around the ClassFileFormatVersion to
> parse flags
On Tue, 29 Apr 2025 19:48:01 GMT, Chen Liang wrote:
>> Take the class file version to reject flags not yet defined, redefined, or
>> obsoleted. This is useful for clients like javap to report the correct
>> undefined flags for different class file versions.
>>
>> A preparatory patch for javap
On Fri, 18 Apr 2025 18:31:05 GMT, Ioi Lam wrote:
> This PR contains 2 parts
>
> - Upstream of Soft/Weak Reference support authored by @macarte from [the
> Leyden
> repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
> - New C++ class `AOTReferenceObjSupport
> A prerequisite to #24760; this was part of it, but was split out to simplify
> the review of the addition of `maskToAccessFlags(int, Location, CFFV)` by
> minimizing the changes in javap. That patch will only need to update
> `BasicWriter` as a result.
>
> Testing: langtools/tools/javap, tier
On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg wrote:
>> This PR is based on the work of @mernst-github and aims to implement an
>> _internal_ thread-local 'stack' allocator, which works like a dynamically
>> sized arena, but with reset functionality to reset the allocated size back
>> to a cer
On Wed, 30 Apr 2025 15:47:32 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/String.java line 1739:
>>
>>> 1737:
>>> 1738: /**
>>> 1739: * {@inheritDoc CharSequence}
>>
>> @jaikiran @jddarcy Sorry for bothering, but I do need your kind help here to
>> get the code to
On Wed, 30 Apr 2025 06:46:07 GMT, Volkan Yazici wrote:
> Replace manual bitwise operations in `hashCode` implementations of
> `java.time` with `Long::hashCode`.
This pull request has now been integrated.
Changeset: 18983b63
Author:Volkan Yazici
Committer: Naoto Sato
URL:
https://g
On Wed, 30 Apr 2025 17:45:04 GMT, Ioi Lam wrote:
>> This PR contains 2 parts
>>
>> - Upstream of Soft/Weak Reference support authored by @macarte from [the
>> Leyden
>> repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
>> - New C++ class `AOTReferenceObjS
On Wed, 30 Apr 2025 15:01:08 GMT, Roger Riggs wrote:
>> Replace manual bitwise operations in `hashCode` implementations of
>> `java.time` with `Long::hashCode`.
>
> lgtm
@RogerRiggs, @minborg, @naotoj, thanks for the reviews. I've attached
successful `tier1,2` results to the ticket. I'd apprec
On Wed, 30 Apr 2025 06:46:07 GMT, Volkan Yazici wrote:
> Replace manual bitwise operations in `hashCode` implementations of
> `java.time` with `Long::hashCode`.
@vy
Your change (at version 891d9ada7ce6860ea8e1253021f04053cc27090a) is now ready
to be sponsored by a Committer.
-
P
On Wed, 30 Apr 2025 15:40:35 GMT, Ioi Lam wrote:
>> src/java.base/share/classes/java/lang/ref/Reference.java line 313:
>>
>>> 311: }
>>> 312:
>>> 313: private static void runtimeSetup() {
>>
>> I don't know if you are planning an annotation or something to mark these
>> "runtimeSetup"
On Wed, 30 Apr 2025 08:47:59 GMT, Axel Boldt-Christmas
wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Renamed the internal field ReferenceQueue.NULL to NULL_QUEUE to avoid
>> failing hotspot/jtreg/sources/TestNoNULL.
> This PR contains 2 parts
>
> - Upstream of Soft/Weak Reference support authored by @macarte from [the
> Leyden
> repo](https://github.com/openjdk/leyden/commit/4ca75d156519596e23abc8a312496b7c2f0e0ca5)
> - New C++ class `AOTReferenceObjSupport` and new Java method
> `ReferencedKeyMap::prepare
On Wed, 30 Apr 2025 06:46:07 GMT, Volkan Yazici wrote:
> Replace manual bitwise operations in `hashCode` implementations of
> `java.time` with `Long::hashCode`.
There is a place in java.util.Locale::hashCode that can also be changed
Current version
long bitsWeight = Double.doubleToLongBits(wei
On Wed, 30 Apr 2025 16:11:14 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOException`. So, if the
>> ap
On Wed, 30 Apr 2025 16:11:14 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOException`. So, if the
>> ap
> Use the `@requires` tag instead of obtaining the operating system name from
> the `os.name` property and then exiting if the test is not run on that
> operating system.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8355444:
On Tue, 29 Apr 2025 18:31:37 GMT, Brian Burkhalter wrote:
>> Use the `@requires` tag instead of obtaining the operating system name from
>> the `os.name` property and then exiting if the test is not run on that
>> operating system.
>
> Brian Burkhalter has updated the pull request incrementally
On Wed, 30 Apr 2025 09:15:49 GMT, Viktor Klang wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 17 additional
>> commits sin
On Wed, 30 Apr 2025 14:12:36 GMT, Roger Riggs wrote:
> Refactor AbstractStringBuilder to maintain consistency among count, coder,
> and value buffers while the buffer capacity is being expanded and/or inflated
> from Latin1 to UTF16 representations.
> The refactoring pattern is to read and wri
On Tue, 29 Apr 2025 19:03:08 GMT, Chen Liang wrote:
>> The recent patch #23866 makes calling `ClassValue::remove()` from
>> `ClassValue::computeValue()` end up in infinite loops while fixing the stale
>> value risk from the method.
>>
>> The proposed fix is to preserve the stale value risk fix
On Thu, 24 Apr 2025 10:37:59 GMT, Per Minborg wrote:
>> Implement JEP 502.
>>
>> The PR passes tier1-tier3 tests.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Make public constuctor private
Congratulations! With the int
On Wed, 30 Apr 2025 14:12:36 GMT, Roger Riggs wrote:
> Refactor AbstractStringBuilder to maintain consistency among count, coder,
> and value buffers while the buffer capacity is being expanded and/or inflated
> from Latin1 to UTF16 representations.
> The refactoring pattern is to read and wri
On Wed, 30 Apr 2025 16:07:56 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOException`. So, if the
>> ap
On Wed, 30 Apr 2025 14:50:03 GMT, Roger Riggs wrote:
> Please add the test number 8352533 to the @bug tag in Basic.java.
Thanks, added!
-
PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2842494196
> When jspawnhelper fails for whatever reason, but more prominently due to
> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
> the errors into stdout, but not to the relevant `IOException`. So, if the
> application is configured to only capture the exception logs (e.g.
On Fri, 25 Apr 2025 09:57:38 GMT, Gautham Krishnan wrote:
> MET timezone entry in TimeZoneNames.java and TimeZoneNames_*.java needs to be
> updated as MET is alias to Europe/Brussels as per 2024b tzdata changes.
>
> Also Bug4848242.java needs to be removed as the test expects all euro locale
>
On Wed, 30 Apr 2025 06:46:07 GMT, Volkan Yazici wrote:
> Replace manual bitwise operations in `hashCode` implementations of
> `java.time` with `Long::hashCode`.
LGTM. Thanks for the refactoring
-
Marked as reviewed by naoto (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/
On Mon, 10 Mar 2025 18:11:23 GMT, Per Minborg wrote:
> Implement JEP 502.
>
> The PR passes tier1-tier3 tests.
This pull request has now been integrated.
Changeset: fbc4691b
Author:Per Minborg
URL:
https://git.openjdk.org/jdk/commit/fbc4691bfa11f31601fd89d05da63e689343e214
Stats:
> This PR optimizes `BigInteger.pow(int)` method. The primary enhancement in
> `pow()` is not concerned most on execution time, but rather in memory
> optimization, because the PR implementation does the "shift of the exponent"
> squaring the result rather than the base, so the base is not squar
On Wed, 30 Apr 2025 15:33:52 GMT, Per Minborg wrote:
>> This PR is based on the work of @mernst-github and aims to implement an
>> _internal_ thread-local 'stack' allocator, which works like a dynamically
>> sized arena, but with reset functionality to reset the allocated size back
>> to a cer
On Wed, 23 Apr 2025 14:12:29 GMT, Chen Liang wrote:
>> In offline discussion, we noted that the documentation on this annotation
>> does not recommend minimizing the intrinsified section and moving whatever
>> can be done in Java to Java; thus I prepared this documentation update, to
>> shrink
The private key encoding formats of ML-KEM and ML-DSA are updated to match the
latest IERTF drafts at:
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-08
and
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-kyber-certificates-10.
New security/system properti
On Wed, 30 Apr 2025 15:34:33 GMT, Markus KARG wrote:
>> Markus KARG has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get
>> JavaDocs without @since.
>
> src/java.base/sha
On Wed, 30 Apr 2025 06:08:30 GMT, Alan Bateman wrote:
>> Comment simplified in 4cee3c2.
>
> Okay, just a bit puzzled as to why it doesn't run on Linux. The VM uses
> setrlimit(RLIMIT_NOFILE) to set the limit to the hard limit (rlim_max). So is
> the issue here that the hard limit less than 2050
On Wed, 30 Apr 2025 13:43:28 GMT, Alan Bateman wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Renamed the internal field ReferenceQueue.NULL to NULL_QUEUE to avoid
>> failing hotspot/jtreg/sources/TestNoNULL.java
>
>
On Wed, 30 Apr 2025 15:33:37 GMT, Markus KARG wrote:
>> This Pull Request proposes an implementation for
>> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
>> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
>> dstBegin)` to the `CharSequence` i
> This PR is based on the work of @mernst-github and aims to implement an
> _internal_ thread-local 'stack' allocator, which works like a dynamically
> sized arena, but with reset functionality to reset the allocated size back to
> a certain level. The underlying memory could stay around between
> This Pull Request proposes an implementation for
> [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new
> method `public void getChars(int srcBegin, int srcEnd, char[] dst, int
> dstBegin)` to the `CharSequence` interface, providing a **bulk-read**
> facility including a
> This PR is based on the work of @mernst-github and aims to implement an
> _internal_ thread-local 'stack' allocator, which works like a dynamically
> sized arena, but with reset functionality to reset the allocated size back to
> a certain level. The underlying memory could stay around between
On Wed, 30 Apr 2025 06:46:07 GMT, Volkan Yazici wrote:
> Replace manual bitwise operations in `hashCode` implementations of
> `java.time` with `Long::hashCode`.
Looks fine! Thanks for this cleanup.
-
Marked as reviewed by pminborg (Reviewer).
PR Review: https://git.openjdk.org/jd
On Wed, 30 Apr 2025 10:55:41 GMT, Per Minborg wrote:
>> This PR is based on the work of @mernst-github and aims to implement an
>> _internal_ thread-local 'stack' allocator, which works like a dynamically
>> sized arena, but with reset functionality to reset the allocated size back
>> to a cer
1 - 100 of 160 matches
Mail list logo
