On Tue, 19 Aug 2025 06:04:49 GMT, David Holmes wrote:
>> DELETED - I confused the timeout with the timeout-factor. New comment below.
>
> 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
> *
On Tue, 8 Jul 2025 05:26:16 GMT, Sergey Bylokhov wrote:
> The ICC_Profile class has special logic to postpone actual data loading for
> as long as possible. To support this we use a lightweight object that stores
> commonly used metadata such as the number of components that can be accessed
>
Test compares specific pixels with expected color and needed color profile
setting in macOS26 is not available it seems.
Since the pixel color difference is slightly off, I have added a tolerance
which had been present in many other tests so it's not without precedent
-
Commit messa
On Mon, 18 Aug 2025 13:22:58 GMT, Khalid Boulanouare wrote:
>> Many Mixing tests failed because the work around click lands on the
>> minimizing area in the window control and causes the tests to fail.
>>
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khali
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 this PR, it will take `7200*10` seconds
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 Mon, 4 Aug 2025 15:14:30 GMT, Manukumar V S wrote:
> Issue:
> javax/swing/Popup/TaskbarPositionTest.java can fail subsequent tests on MacOS
> because of using 'Cntrl+Down Arrow' as this acts as a shortcut in MacOS to
> show all windows related to the focused one.
>
> Fix:
> Change the 'Cntr
On Mon, 4 Aug 2025 15:14:30 GMT, Manukumar V S wrote:
> Issue:
> javax/swing/Popup/TaskbarPositionTest.java can fail subsequent tests on MacOS
> because of using 'Cntrl+Down Arrow' as this acts as a shortcut in MacOS to
> show all windows related to the focused one.
>
> Fix:
> Change the 'Cntr
On Mon, 18 Aug 2025 09:15:29 GMT, Leo Korinth wrote:
>> It is unclear to me if the author meant this to be `2.5` more than normal or
>> `10` more than JTREG default, or a `multiplier that seems to work`. It does
>> not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a
>> val
On Mon, 18 Aug 2025 16:31:00 GMT, Alexey Ivanov wrote:
> **Problem:**
>
> The colors for the accelerators are cached in static fields:
> `disabledForeground`, `acceleratorSelectionForeground` and
> `acceleratorForeground`. As soon as this field is set to a non-`UIResource`
> value, the value
On Fri, 8 Aug 2025 16:37:36 GMT, Daniel Gredler wrote:
> Addresses recent slight performance regressions in some J2DBench benchmarks
> focused on text drawing.
>
> `CCharToGlyphMapper` and `CompositeGlyphMapper` cache glyph IDs, but after
> JDK-8353230 they weren't caching glyph IDs for chars
On Wed, 6 Aug 2025 22:34:30 GMT, Phil Race wrote:
>> This PR removes javax/imageio/stream/ImageInputStreamImpl.finalize()
>> As a result, sub-classes which over-ride it to be empty no longer need to do
>> so.
>> Also it means that the 2 remaining classes which used it no longer can.
>> FileCache
On Mon, 23 Jun 2025 17:40:42 GMT, Abhishek Kumar wrote:
> `AccessibleText.getBeforeIndex` method returns `null for last characte`r due
> to the **wrong boundary value condition check**.
> This method returns `null` when the `passed index parameter` is equal to
> `text's length` which is incorre
On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew wrote:
> When calling the `setLocationRelativeTo()` method, a null parameter means
> that it centers the window in the screen. However, any subsequent resizing
> operations will change only the size, not the location of the window.
> Understand
On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew wrote:
>> When calling the `setLocationRelativeTo()` method, a null parameter means
>> that it centers the window in the screen. However, any subsequent resizing
>> operations will change only the size, not the location of the window.
>> Unders
On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew wrote:
>> When calling the `setLocationRelativeTo()` method, a null parameter means
>> that it centers the window in the screen. However, any subsequent resizing
>> operations will change only the size, not the location of the window.
>> Unders
On Mon, 18 Aug 2025 19:12:30 GMT, David Alayachew wrote:
> Is there any outstanding tasks? Or are we just waiting the 24 hours before
> merging?
The 24-hour rule is usually to ensure all involved areas can have a reviewer to
take a look at the changes, given people live in different time zones
On Mon, 4 Aug 2025 15:14:30 GMT, Manukumar V S wrote:
> Issue:
> javax/swing/Popup/TaskbarPositionTest.java can fail subsequent tests on MacOS
> because of using 'Cntrl+Down Arrow' as this acts as a shortcut in MacOS to
> show all windows related to the focused one.
>
> Fix:
> Change the 'Cntr
On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew wrote:
>> When calling the `setLocationRelativeTo()` method, a null parameter means
>> that it centers the window in the screen. However, any subsequent resizing
>> operations will change only the size, not the location of the window.
>> Unders
On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew wrote:
>> When calling the `setLocationRelativeTo()` method, a null parameter means
>> that it centers the window in the screen. However, any subsequent resizing
>> operations will change only the size, not the location of the window.
>> Unders
On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew wrote:
>> When calling the `setLocationRelativeTo()` method, a null parameter means
>> that it centers the window in the screen. However, any subsequent resizing
>> operations will change only the size, not the location of the window.
>> Unders
On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew wrote:
>> When calling the `setLocationRelativeTo()` method, a null parameter means
>> that it centers the window in the screen. However, any subsequent resizing
>> operations will change only the size, not the location of the window.
>> Unders
On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew wrote:
>> When calling the `setLocationRelativeTo()` method, a null parameter means
>> that it centers the window in the screen. However, any subsequent resizing
>> operations will change only the size, not the location of the window.
>> Unders
On Mon, 18 Aug 2025 19:35:12 GMT, David Alayachew wrote:
> Ok, does that look better?
Yes, it looks good to me now, and you learnt some Git magic. (Thanks for not
force-pushing.)
> Thanks for approving. I see that the sponsor tag is gone. I will wait until
> the 24 hours to do the integrate
On Mon, 18 Aug 2025 19:40:06 GMT, David Alayachew wrote:
>> When calling the `setLocationRelativeTo()` method, a null parameter means
>> that it centers the window in the screen. However, any subsequent resizing
>> operations will change only the size, not the location of the window.
>> Unders
On Mon, 18 Aug 2025 19:30:42 GMT, David Alayachew wrote:
>> David Alayachew 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 two additional
>> co
> When calling the `setLocationRelativeTo()` method, a null parameter means
> that it centers the window in the screen. However, any subsequent resizing
> operations will change only the size, not the location of the window.
> Understandable, but now the window is no longer centered. So, changin
On Mon, 18 Aug 2025 19:17:38 GMT, David Alayachew wrote:
>> When calling the `setLocationRelativeTo()` method, a null parameter means
>> that it centers the window in the screen. However, any subsequent resizing
>> operations will change only the size, not the location of the window.
>> Unders
On Mon, 18 Aug 2025 19:34:14 GMT, David Alayachew wrote:
>> David Alayachew 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 two additional
>> co
On Mon, 18 Aug 2025 19:17:38 GMT, David Alayachew wrote:
>> When calling the `setLocationRelativeTo()` method, a null parameter means
>> that it centers the window in the screen. However, any subsequent resizing
>> operations will change only the size, not the location of the window.
>> Unders
On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew wrote:
> When calling the `setLocationRelativeTo()` method, a null parameter means
> that it centers the window in the screen. However, any subsequent resizing
> operations will change only the size, not the location of the window.
> Understand
On Mon, 18 Aug 2025 19:29:11 GMT, David Alayachew wrote:
> Man, I messed up the commit. It asked me if I wanted to grab upstream
> changes, now there's all this gunk. Let me try recreating the pull request.
@davidalayachew Why do you need to re-create the PR?
Just pull the changes from your pe
On Mon, 18 Aug 2025 19:12:30 GMT, David Alayachew wrote:
>> When calling the `setLocationRelativeTo()` method, a null parameter means
>> that it centers the window in the screen. However, any subsequent resizing
>> operations will change only the size, not the location of the window.
>> Unders
On Fri, 15 Aug 2025 22:09:15 GMT, Phil Race wrote:
>>> > There are still static fields to store colors in `WindowsMenuItemUI`, do
>>> > you want to get rid of those too? My bug report implied removing them,
>>> > yet currently the static fields with colors remain intact in
>>> > `WindowsMenuIt
On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew wrote:
> When calling the `setLocationRelativeTo()` method, a null parameter means
> that it centers the window in the screen. However, any subsequent resizing
> operations will change only the size, not the location of the window.
> Understand
On Mon, 18 Aug 2025 13:42:45 GMT, Chen Liang wrote:
> Hi @davidalayachew, can you update the copyright year at top from `2015,
> 2016,` to `2015, 2025,`?
>
> In addition, according to https://openjdk.org/guide, we usually leave 24
> hours for sufficient review. This applies so you should type
> This refactors some Swing code to pass args instead of using statics
> The bug report suggests some further refactoring which could be considered
> later, but the most
> important thing to do is to eliminate using statics to pass args.
> I've added one other suggestion from the bug report to hav
> When calling the `setLocationRelativeTo()` method, a null parameter means
> that it centers the window in the screen. However, any subsequent resizing
> operations will change only the size, not the location of the window.
> Understandable, but now the window is no longer centered. So, changin
On Wed, 6 Aug 2025 02:58:01 GMT, Prasanta Sadhukhan
wrote:
>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of
>> ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates
>> `MediaTracker` to associate
Hi Naoto,
TextLayout currently is not allowed to represent the layout of an empty
string, and I'm looking to change that (see JDK-4138921).
One of the three TextLayout constructors which needs to change takes
an AttributedCharacterIterator, which is usually obtained from an
AttributedString. Howe
On Mon, 18 Aug 2025 17:05:26 GMT, Alexey Ivanov wrote:
> Since `WindowsMenuUI` is a final class after PR #24170 for
> [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638)), it cannot be
> extended, therefore the `protected` modifier doesn't make sense.
>
> Mark both `menuBarHeight` and `
On Mon, 18 Aug 2025 17:05:26 GMT, Alexey Ivanov wrote:
> Since `WindowsMenuUI` is a final class after PR #24170 for
> [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638)), it cannot be
> extended, therefore the `protected` modifier doesn't make sense.
>
> Mark both `menuBarHeight` and `
On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew wrote:
> When calling the `setLocationRelativeTo()` method, a null parameter means
> that it centers the window in the screen. However, any subsequent resizing
> operations will change only the size, not the location of the window.
> Understand
On Mon, 18 Aug 2025 17:15:47 GMT, Sergey Bylokhov wrote:
>> Add the missing `@Override` annotations to anonymous classes implementing
>> `WindowsMenuItemUIAccessor`.
>>
>> PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638)
>> added the `@Override` annotations to `getMenuI
On Mon, 18 Aug 2025 16:49:48 GMT, Alexey Ivanov wrote:
> Add the missing `@Override` annotations to anonymous classes implementing
> `WindowsMenuItemUIAccessor`.
>
> PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638)
> added the `@Override` annotations to `getMenuItem` an
Since `WindowsMenuUI` is a final class after PR #24170 for
[JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638)), it cannot be
extended, therefore the `protected` modifier doesn't make sense.
Mark both `menuBarHeight` and `hotTrackingOn` as `private` fields.
-
Commit messages
On Mon, 18 Aug 2025 16:49:48 GMT, Alexey Ivanov wrote:
> Add the missing `@Override` annotations to anonymous classes implementing
> `WindowsMenuItemUIAccessor`.
>
> PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638)
> added the `@Override` annotations to `getMenuItem` an
Add the missing `@Override` annotations to anonymous classes implementing
`WindowsMenuItemUIAccessor`.
PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638) added
the `@Override` annotations to `getMenuItem` and `getPart` but left `getState`
without the annotation.
For consi
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
**Problem:**
The colors for the accelerators are cached in static fields:
`disabledForeground`, `acceleratorSelectionForeground` and
`acceleratorForeground`. As soon as this field is set to a non-`UIResource`
value, the value cannot change.
**Fix:**
Remove the static fields for accelerator fr
On Mon, 18 Aug 2025 11:34:39 GMT, Daniel Fuchs wrote:
> Hi Leo, I played a bit with your changes and I observed intermittent timeout
> failures for the following tests:
>
> ```
> java/net/httpclient/CancelledResponse.java
> java/net/httpclient/whitebox/FlowTestDriver.java
> ```
>
>
> 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 changing the timeout factor, I am also using a library call to
On Tue, 15 Jul 2025 19:52:15 GMT, Alisen Chung wrote:
>> **Analysis:**
>> The getFocusableWindowState() method is not intended to modify the
>> configuration; doing so can cause recursive re-entry on Linux.
>>
>> **Proposed Fix:**
>> We are intentionally overriding getFocusableWindowState() to
This test was recently automated and is failing intermittently in the CI due to
timing issues.
This enhancement aims to stabilize the test and also adds the missing null
pointer check.
-
Commit messages:
- Test stabilization
Changes: https://git.openjdk.org/jdk/pull/26824/files
On Fri, 15 Aug 2025 22:09:15 GMT, Phil Race wrote:
> > > > There are still static fields to store colors in `WindowsMenuItemUI`,
> > > > do you want to get rid of those too? My bug report implied removing
> > > > them, yet currently the static fields with colors remain intact in
> > > > `Windo
### TL;DR
This is a fix for what I think is a regression since the introduction of
HarfBuzz in JDK 9. The problem is that the algorithm which converts the glyph
vector produced by the layout engine into a corresponding character vector (in
`ExtendedTextSourceLabel::createCharinfo()`) still assu
> The ICC_Profile class has special logic to postpone actual data loading for
> as long as possible. To support this we use a lightweight object that stores
> commonly used metadata such as the number of components that can be accessed
> without triggering full profile loading. But we currently
On Mon, 18 Aug 2025 13:51:07 GMT, Christian Stein wrote:
> > Do we need a update to EditPadTest to ensure all parts of that JFrame is
> > rendered on the screen?
>
> I think such a test, if deemed necessary, should be added to the "core" Swing
> tests instead. Here, it would be an implementati
On Fri, 15 Aug 2025 11:43:33 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 Mon, 18 Aug 2025 13:12:41 GMT, Roger Riggs wrote:
> Generally, changes with this many changed files are broken down into smaller
> PRs to make the review easier and more conclusive. In this case, hotspot,
> jdk, and langtools might have been good groupings. The reviews could be done
> in pa
On Mon, 18 Aug 2025 13:04:47 GMT, Chen Liang wrote:
> Do we need a update to EditPadTest to ensure all parts of that JFrame is
> rendered on the screen?
I think such a test, if deemed necessary, should be added to the "core" Swing
tests instead. Here, it would be an implementation detail that
On Wed, 6 Aug 2025 07:04:52 GMT, Prasanta Sadhukhan
wrote:
>>> In Windows machines, the click lands on the reduce control of the window,
>>> and this causes the windows to be iconified and the test fails.
>>
>> WHich test in particular? or is it all tests have this behavior?
>>
>>> The test n
> Many Mixing tests failed because the work around click lands on the
> minimizing area in the window control and causes the tests to fail.
>
> This fix changes the width of base frames which allows most of tests to pass.
Khalid Boulanouare has updated the pull request incrementally with one
ad
On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew wrote:
> When calling the `setLocationRelativeTo()` method, a null parameter means
> that it centers the window in the screen. However, any subsequent resizing
> operations will change only the size, not the location of the window.
> Understand
On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew wrote:
> When calling the `setLocationRelativeTo()` method, a null parameter means
> that it centers the window in the screen. However, any subsequent resizing
> operations will change only the size, not the location of the window.
> Understand
On Fri, 15 Aug 2025 11:43:33 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
> Many Mixing tests failed because the work around click lands on the
> minimizing area in the window control and causes the tests to fail.
>
> This fix changes the width of base frames which allows most of tests to pass.
Khalid Boulanouare has updated the pull request with a new target base due
On Fri, 15 Aug 2025 11:43:33 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, 12 Aug 2025 15:06:16 GMT, Alexey Ivanov wrote:
>> Khalid Boulanouare has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updates CountDownLatch waiting time to one second
>
> Strangely enough, these changes make no difference for me
On Fri, 15 Aug 2025 11:43:33 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 Thu, 14 Aug 2025 19:30:30 GMT, Doug Simon wrote:
> > I have run testing tier1-8. The last time with a timeout factor of 1
> > instead of 0.7.
>
> Would you mind also running tier9 to avoid surprises there.
I had problems doing this, and I just want to say that I have not run tier9 (I
have
On Mon, 18 Aug 2025 09:07:54 GMT, Leo Korinth wrote:
>> make/RunTests.gmk line 940:
>>
>>> 938: JTREG_AUTO_PROBLEM_LISTS :=
>>> 939: # Please reach consensus before changing this. It was not easy
>>> changing it to a `1`.
>>> 940: JTREG_AUTO_TIMEOUT_FACTOR := 1
>>
>> Since the default va
On Fri, 15 Aug 2025 14:05:49 GMT, SendaoYan wrote:
>> Leo Korinth has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> added extra timeout for:
>> jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD
>
> make/Ru
> This PR will consolidate fixes of the following bugs:
>
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://
On Fri, 15 Aug 2025 17:29:16 GMT, Khalid Boulanouare wrote:
>> This PR will consolidate fixes of the following bugs:
>>
>> https://bugs.openjdk.org/browse/JDK-8361188
>> https://bugs.openjdk.org/browse/JDK-8361189
>> https://bugs.openjdk.org/browse/JDK-8361190
>> https://bugs.openjdk.org/browse/
On Tue, 12 Aug 2025 15:06:16 GMT, Alexey Ivanov wrote:
>> Khalid Boulanouare has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updates CountDownLatch waiting time to one second
>
> Strangely enough, these changes make no difference for me
77 matches
Mail list logo
