On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote:
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave con
On Thu, 8 May 2025 07:54:17 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Thu, 8 May 2025 07:54:17 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote:
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave con
On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote:
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave con
On Thu, 8 May 2025 07:40:44 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Thu, 8 May 2025 07:10:35 GMT, Alan Bateman wrote:
>> Changes for [JEP 505: Structured Concurrency (Fifth
>> Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview
>> the API with some changes, specifically:
>>
>> - A
>> [StructuredTaskScope](https://download.java.net/ja
On Mon, 28 Apr 2025 15:23:18 GMT, kabutz wrote:
> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
> a single bug report and PR.
>
> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
> put/take
>
> The LinkedBlockingDeque does not behave con
On Tue, 1 Apr 2025 14:59:37 GMT, Severin Gehwolf wrote:
>> Please review this fix for cgroups-based metrics reporting in the
>> `jdk.internal.platform` package. This fix is supposed to address wrong
>> reporting of certain limits if the limits aren't set at the leaf nodes.
>>
>> For example, o
On Thu, 8 May 2025 07:54:17 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Thu, 8 May 2025 09:21:35 GMT, Per Minborg wrote:
>> As we advance, converting older JDK code to use the relatively new FFM API
>> requires system calls that can provide `errno` and the likes to explicitly
>> allocate a MemorySegment to capture potential error states. This can lead to
>> neg
On Wed, 7 May 2025 18:32:50 GMT, fabioromano1 wrote:
>> 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"
>> squarin
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Thu, 8 May 2025 08:47:50 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove class
>
> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line
> 110:
>
>> 108:
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Thu, 8 May 2025 09:21:42 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address comments
>
> src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 15520:
>
>> 15518:
> Most of the JDK code base has been transitioned to UTF-8, but not all. This
> has recently become an acute problem, since our mixing of iso-8859-1 and
> utf-8 in properties files confused the version of `sed` that is shipped with
> the new macOS 15.4.
>
> The fix is basically simple, and incl
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
Can I please get a review of this change which addresses the issue noted in
https://bugs.openjdk.org/browse/JDK-8354799?
`java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero size
was missing a CRC check for that entry. The change in this PR addresses that
and introduces a n
On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman wrote:
>> The bug description seems like it is a fault in the JVM implementation - if
>> that is the case, a core library bypass is unreliable, as such faults might
>> happen to other classes and cause other consequences; and we might need to
>> f
On Wed, 30 Apr 2025 11:25:34 GMT, Alan Bateman wrote:
>> The bug description seems like it is a fault in the JVM implementation - if
>> that is the case, a core library bypass is unreliable, as such faults might
>> happen to other classes and cause other consequences; and we might need to
>> f
> Changes for [JEP 505: Structured Concurrency (Fifth
> Preview)](https://openjdk.org/jeps/8340343). The proposal is to re-preview
> the API with some changes, specifically:
>
> - A
> [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/
> This sketch shows how "Stable Updaters" can be used to create stable
> computations of `@Stable` fields. Only one updater is needed per class,
> similar to `AtomicIntegerFieldUpdater`.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
> This sketch shows how "Stable Updaters" can be used to create stable
> computations of `@Stable` fields. Only one updater is needed per class,
> similar to `AtomicIntegerFieldUpdater`.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
> As we advance, converting older JDK code to use the relatively new FFM API
> requires system calls that can provide `errno` and the likes to explicitly
> allocate a MemorySegment to capture potential error states. This can lead to
> negative performance implications if not designed carefully a
On Thu, 8 May 2025 13:01:38 GMT, Alan Bateman wrote:
> I'm just wondering if there are any wonky tools or plugins in the eco system,
> the output of which could be impacted by the more strict check.
I'll run some experiments and see what it shows up.
-
PR Comment: https://git.open
On Fri, 2 May 2025 16:42:04 GMT, Joe Darcy wrote:
>> test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:
>>
>>> 48: public class HelpOutputColumnWidthTest extends TestRunner {
>>> 49:
>>> 50: public static final int MAX_COLUMNS = 84;
>>
>> What is this for?
>
> It is
> This sketch shows how "Stable Updaters" can be used to create stable
> computations of `@Stable` fields. Only one updater is needed per class,
> similar to `AtomicIntegerFieldUpdater`.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
On Thu, 8 May 2025 12:08:09 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which addresses the issue noted in
> https://bugs.openjdk.org/browse/JDK-8354799?
>
> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero
> size was missing a CRC check for tha
> 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 Thu, 8 May 2025 15:33:17 GMT, fabioromano1 wrote:
>> 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"
>> squarin
Please review this small test fix. We need to make sure the two threads are
blocked on the expected locks before invoking findMonitorDeadlockedThreads. In
the failing cases, one of the threads is seen as blocked while waiting for a
class to be initialized by the other thread (I've added the stac
> Add `powExact()` and `unsignedPowExact()` methods that operate on integer
> values arguments.
> Further, add `unsignedMultiplyExact` methods as well.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Added tests.
On Thu, 8 May 2025 13:16:25 GMT, Per Minborg wrote:
>> This sketch shows how "Stable Updaters" can be used to create stable
>> computations of `@Stable` fields. Only one updater is needed per class,
>> similar to `AtomicIntegerFieldUpdater`.
>
> Per Minborg has updated the pull request incremen
On Fri, 2 May 2025 15:17:25 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 Fri, 2 May 2025 15:17:25 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, 8 May 2025 14:30:28 GMT, Per Minborg wrote:
> This PR proposed to let `ReverseOrderListView::reversed` return `base` so
> that nested reversed views are avoided.
src/java.base/share/classes/java/util/ReverseOrderListView.java line 398:
> 396: }
> 397:
> 398: @Override
I don't
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 15:48:30 GMT, Raffaello Giulietti
wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Suggested changes
>
> Please update the 2nd copyright year in `BigInteger`.
>
> Otherwise looks good.
> As soon
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 16:19:41 GMT, Jaikiran Pai wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update src/java.base/share/classes/java/lang/ClassValue.java
>>
>> Co-authored-by: Shaojin Wen
>
> src/java.base/sha
On Fri, 2 May 2025 15:17:25 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,
> 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 Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie wrote:
>> Most of the JDK code base has been transitioned to UTF-8, but not all. This
>> has recently become an acute problem, since our mixing of iso-8859-1 and
>> utf-8 in properties files confused the version of `sed` that is shipped with
On Thu, 8 May 2025 16:04:53 GMT, Stefan Karlsson 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
> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a
> null argument.
Andrew Haley has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains nine commits:
- Fix merge
- Merge from
> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a
> null argument.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
ScopedValue::orElse() does not accept null as an argum
On Wed, 30 Apr 2025 12:48:08 GMT, Alan Bateman wrote:
> @theRealAph Can you include the update to javax/security/auth/Subject.java as
> part of this?
Fixed now.
-
PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2863756144
> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a
> null argument.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Fix merge
-
Changes:
- all: https://gi
On Thu, 8 May 2025 13:10:57 GMT, Jaikiran Pai wrote:
> I'll run some experiments and see what it shows up.
Thanks as that will help inform as to whether this will need a compatibility
knob.
-
PR Comment: https://git.openjdk.org/jdk/pull/25116#issuecomment-2863078781
> This PR is defining a new internal annotation,
> `@jdk.internal.RequiresIdentity`, with target types PARAMETER and
> TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation
> that an argument to a given method or constructor parameter will be an object
> with a unique ident
On Thu, 8 May 2025 08:41:52 GMT, Viktor Klang wrote:
> We could likely check if there's any remaining capacity up front, and
> immediately return false?
We could if you like. I wanted to make as few changes as possible, to not
introduce unexpected changes. This particular bug was to stop a siz
On Thu, 8 May 2025 08:33:06 GMT, Viktor Klang wrote:
> I'm a bit uneasy about incrementing the `count` in `linkFirst` but not
> enforcing the invariant. What's the benefit to changing linkFirst and
> linkLast to return void instead of keeping the original returning a boolean?
I based the appro
On Wed, 7 May 2025 19:05:17 GMT, Alan Bateman wrote:
>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` was
>> called on the target library file before it was passed to the system library
>> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>> s
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 change (it will finally be changed to 1.0 in JDK-8260555). The n
On Wed, 7 May 2025 18:33:11 GMT, Volkan Yazici wrote:
>> Document preconditions on certain `JavaLangAccess` methods that use
>> operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional
> commit since the last revision
On Thu, 8 May 2025 12:08:09 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which addresses the issue noted in
> https://bugs.openjdk.org/browse/JDK-8354799?
>
> `java.util.zip.ZipInputStream` when dealing with a `STORED` entry of zero
> size was missing a CRC check for tha
> Get JDK 26 underway.
Nizar Benalla has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains seven commits:
- Update release date
- Update --release 25 symbol information for JDK 25 build 21
The macOS/AArch64 build 21 was taken from http
On Wed, 7 May 2025 18:33:11 GMT, Volkan Yazici wrote:
>> Document preconditions on certain `JavaLangAccess` methods that use
>> operations either unsafe and/or without range checks.
>
> Volkan Yazici has updated the pull request incrementally with one additional
> commit since the last revision
On Thu, 8 May 2025 13:29:36 GMT, Alan Bateman wrote:
> > I'll run some experiments and see what it shows up.
>
> Thanks as that will help inform as to whether this will need a compatibility
> knob.
The crc is calculated as part of the write of the entry and I have not seen any
cases, where th
This PR proposed to let `ReverseOrderListView::reversed` return `base` so that
nested reversed views are avoided.
-
Commit messages:
- Let ReverseOrderListView::reversed return base
Changes: https://git.openjdk.org/jdk/pull/25120/files
Webrev: https://webrevs.openjdk.org/?repo=jd
On Thu, 8 May 2025 08:59:59 GMT, Viktor Klang wrote:
>> We logged several bugs on the LinkedBlockingDeque. This aggregates them into
>> a single bug report and PR.
>>
>> 1. LinkedBlockingDeque does not immediately throw InterruptedException in
>> put/take
>>
>> The LinkedBlockingDeque does no
On Thu, 8 May 2025 14:30:28 GMT, Per Minborg wrote:
> This PR proposed to let `ReverseOrderListView::reversed` return `base` so
> that nested reversed views are avoided.
test/jdk/java/util/Collection/MOAT.java line 507:
> 505: private static void testImmutableSeqColl(final
> SequencedCol
On Thu, 8 May 2025 14:30:28 GMT, Per Minborg wrote:
> This PR proposed to let `ReverseOrderListView::reversed` return `base` so
> that nested reversed views are avoided.
I think there are already tests to ensure that list.reversed().reversed()
returns the original list. See also https://github
On Thu, 8 May 2025 16:01:51 GMT, Jaikiran Pai wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update src/java.base/share/classes/java/lang/ClassValue.java
>>
>> Co-authored-by: Shaojin Wen
>
> src/java.base/sha
On Thu, 8 May 2025 14:44:26 GMT, Chen Liang wrote:
>> This PR proposed to let `ReverseOrderListView::reversed` return `base` so
>> that nested reversed views are avoided.
>
> test/jdk/java/util/Collection/MOAT.java line 507:
>
>> 505: private static void testImmutableSeqColl(final
>> Sequ
On Fri, 2 May 2025 12:13:39 GMT, Per Minborg wrote:
> This PR proposes to address comments in the initial PR for Stable Values,
> which were deferred until after integration.
>
> Unfortunately, this PR shows the total commit history for stable values.
src/java.base/share/classes/java/util/Immu
On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley wrote:
>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a
>> null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional
> commit since the last revi
On Thu, 8 May 2025 13:58:54 GMT, Alan Bateman wrote:
> > You might be correct. We'll see what @AlanBateman and others have to say
> > about it.
>
> I'm still puzzled as to why the DLLs have been moved from the JDK bin
> directory to some other location, and renamed so they don't have the ".dll
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is
> called on the target library file before it is passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
> symlinks on Windows. This had unintended consequences for pass
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 17:23:48 GMT, Alexey Semenyuk wrote:
> Fix JPackageCommand.assertAppImageFile() method to make it pass the relative
> path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage().
@sashamatveev PTAL
-
PR Comment: https://git.openjdk.org/jdk/pull/25126#i
On Thu, 8 May 2025 17:47:12 GMT, Petr Portnov | PROgrm_JARvis
wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix merge
>
> src/java.base/share/classes/java/lang/ScopedValue.java line 613:
>
>> 611: */
>> 61
On Thu, 8 May 2025 17:43:31 GMT, Benjamin Peterson wrote:
>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is
>> called on the target library file before it is passed to the system library
>> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
> Please review this PR which clarifies the behavior for integer and fraction
> limits in NumberFormat and implementing classes. An associated CSR is filed.
>
> There have been a few bugs submitted which indicate a misconception that
> these limits impact parsing. The actual behavior is that the
On Thu, 8 May 2025 17:55:36 GMT, Benjamin Peterson wrote:
>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is
>> called on the target library file before it is passed to the system library
>> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Thu, 8 May 2025 13:33:45 GMT, Vicente Romero wrote:
>> This PR is defining a new internal annotation,
>> `@jdk.internal.RequiresIdentity`, with target types PARAMETER and
>> TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation
>> that an argument to a given method or c
On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie wrote:
>> Most of the JDK code base has been transitioned to UTF-8, but not all. This
>> has recently become an acute problem, since our mixing of iso-8859-1 and
>> utf-8 in properties files confused the version of `sed` that is shipped with
On Thu, 8 May 2025 17:18:12 GMT, Andrew Haley wrote:
>> @theRealAph Can you include the update to javax/security/auth/Subject.java
>> as part of this?
>
>> @theRealAph Can you include the update to javax/security/auth/Subject.java
>> as part of this?
>
> Fixed now.
@theRealAph One other test
On Thu, 8 May 2025 17:55:36 GMT, Benjamin Peterson wrote:
>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is
>> called on the target library file before it is passed to the system library
>> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley wrote:
>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a
>> null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional
> commit since the last revi
On Thu, 8 May 2025 17:33:09 GMT, Andrew Haley wrote:
>> Propose to finalize scoped values.
>> The only functional change is that the orElse() method no longer accepts a
>> null argument.
>
> Andrew Haley has updated the pull request incrementally with one additional
> commit since the last revi
On Thu, 8 May 2025 15:48:30 GMT, Raffaello Giulietti
wrote:
> Otherwise looks good. As soon as you feel comfortable with your changes, let
> me know so that I can approve.
@rgiulietti For me, now the code is ready.
-
PR Comment: https://git.openjdk.org/jdk/pull/24690#issuecomment
On Thu, 8 May 2025 16:48:40 GMT, fabioromano1 wrote:
>> 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"
>> squarin
Fix JPackageCommand.assertAppImageFile() method to make it pass the relative
path to ".jpackag.xml" file to JPackageCommand.assertFileInAppImage().
-
Commit messages:
- Fix a bug in JPackageCommand.assertFileInAppImage() uncovered by running
signing tests after JDK-8356219 fix. JDK
> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is
> called on the target library file before it is passed to the system library
> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
> symlinks on Windows. This had unintended consequences for pass
On Wed, 7 May 2025 16:56:47 GMT, Naoto Sato wrote:
> Simple clarification of the `Console.charset()` method description, making
> explicit how the charset is applied.
Thanks for the review, Brian
-
PR Comment: https://git.openjdk.org/jdk/pull/25103#issuecomment-2863826743
On Wed, 7 May 2025 16:56:47 GMT, Naoto Sato wrote:
> Simple clarification of the `Console.charset()` method description, making
> explicit how the charset is applied.
This pull request has now been integrated.
Changeset: e4ecda2b
Author:Naoto Sato
URL:
https://git.openjdk.org/jdk/c
On Thu, 8 May 2025 18:18:44 GMT, Chen Liang wrote:
> I noted that `ThreadFlock` is using scoped values but throwing
> `StructureViolationException` introduced by structured concurrency - is it
> considered an implementation artifact and part of structured concurrency
> instead?
ThreadFlock su
On Thu, 8 May 2025 19:00:26 GMT, Alan Bateman wrote:
>> Benjamin Peterson has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix spelling
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 124:
>
>> 122:
On Thu, 8 May 2025 13:46:02 GMT, Patricio Chilano Mateo
wrote:
> Please review this small test fix. We need to make sure the two threads are
> blocked on the expected locks before invoking findMonitorDeadlockedThreads.
> In the failing cases, one of the threads is seen as blocked while waiting
On Wed, 7 May 2025 02:07:03 GMT, Alexander Matveev wrote:
>> - Symbolic links will not be followed for `--app-content` on all platforms.
>> - 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
> - Symbolic links will not be followed for `--app-content` on all platforms.
> - 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 br
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 20:19:43 GMT, Alexey Semenyuk wrote:
> Add a check that jpackage doesn't modify files/directories supplied with
> "--app-image", "--resource-dir", "--runtime-image", "--app-content", and
> "--mac-dmg-content" options to every jpackage test.
Looks good.
-
Marked
On Thu, 8 May 2025 21:07:16 GMT, Joe Darcy wrote:
> Fix javadoc tags.
I think this looks good.
-
Marked as reviewed by nbenalla (Committer).
PR Review: https://git.openjdk.org/jdk/pull/25131#pullrequestreview-2826639744
On Wed, 7 May 2025 12:26:54 GMT, Alexey Semenyuk wrote:
>> Alexander Matveev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8352480: [macos] Don't follow symlinks in additional content for app
>> images [v5]
>
> test/jdk/tools/jpackage
On Thu, 8 May 2025 19:51:12 GMT, Chen Liang wrote:
> May I provide a quick patch to use an alternative mechanism to test preview
> class file versions for that class instead of changing that in this PR?
That would be good as it shouldn't depend on ScopedValue being a preview API
class.
--
On Thu, 8 May 2025 19:05:56 GMT, Benjamin Peterson wrote:
>> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line
>> 124:
>>
>>> 122: return null;
>>> 123: }
>>> 124: name = file.getCanonicalPath() +
>>> ClassLoaderHelper
On Thu, 8 May 2025 19:13:46 GMT, Alan Bateman wrote:
>> Conditional on what?
>
> The appending of the "." is specific to the case where there isn't a .dll
> suffix.
`LoadLibrary` appears to happily load files with a `.dll` extension even if a
trailing `.` is appended. So, special casing doesn'
1 - 100 of 144 matches
Mail list logo
