On Wed, 11 Jun 2025 05:08:29 GMT, Harshitha Onkar wrote:
>> test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 52:
>>
>>> 50: pass the test. This test fails if the cursor updates
>>> 51: when pointing over the different components before
>>> 52:
On Tue, 10 Jun 2025 00:42:21 GMT, Harshitha Onkar wrote:
>> Damon Nguyen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update PL num. Clarify instructions.
>
> test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 52:
>
>>
On Tue, 10 Jun 2025 22:23:32 GMT, Alexey Ivanov wrote:
>> I have been looking at it and fiddling with the standalone
>> (non-PassFailJFrame) test to see if I can re-create the behavior without
>> `PassFailJFrame`. I suspected AWT components being the issue but I can't see
>> why.
>>
>> I trie
It seems to me like a candidate based on being a recent 'regression' and
the use case and potential impact.
I just have not looked at or tested the code myself, and clipboard tests
are at least in some part manual,
so I don't know how well it has been tested.
Did anyone run at least the automat
On Tue, 10 Jun 2025 13:12:20 GMT, Alexey Ivanov wrote:
> I think a better solution is to create a new `MediaTracker`, and start anew
> with id of zero.
>
> The `TRACKER_KEY` is used only by `ImageIcon`, so it shouldn't break any apps.
If we create a new MediaTracker in ImageIcon and start anew
On Tue, 10 Jun 2025 16:09:13 GMT, Renjith Kannath Pariyangad
wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [2103dc15](https://github.com/openjdk/jdk/commit/2103dc15cb662fd8795b1b51d9cb61c389bed7a0)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
On Wed, 11 Jun 2025 02:34:04 GMT, Anass Baya wrote:
>> I still suggest this order.
>>
>> Also, please add the new bug ID to the GetGraphicsStressTest.
>> btw I'm still looking into the new test - it always passes for me. Can we
>> tweak it to reproduce the bug more reliably?
>
> I cant reproduc
On Wed, 11 Jun 2025 02:05:33 GMT, Sergey Bylokhov wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2507:
>>
>>> 2505: // before our java peer - if we're dispose()d, for instance.
>>> 2506: // Return the default screen.
>>> 2507: JNI_CHECK_PEER_GOTO(self, r
> **Analysis:**
>
> We are encountering a race condition in the native code. While retrieving the
> screen number by calling _getScreenImOn(), the window is disposed. As a
> result, the AWT-Windows event loop processes the Dispose() call, which
> triggers UnlinkObjects().
> The race condition b
On Tue, 10 Jun 2025 23:51:09 GMT, Sergey Bylokhov wrote:
>> Anass Baya has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove global lock
>
> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2507:
>
>> 2505: // bef
On Tue, 10 Jun 2025 23:53:04 GMT, Sergey Bylokhov wrote:
>> Anass Baya has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove global lock
>
> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2505:
>
>> 2503:
>> 2504:
> **Analysis:**
>
> We are encountering a race condition in the native code. While retrieving the
> screen number by calling _getScreenImOn(), the window is disposed. As a
> result, the AWT-Windows event loop processes the Dispose() call, which
> triggers UnlinkObjects().
> The race condition b
On Tue, 10 Jun 2025 22:17:13 GMT, Anass Baya wrote:
>> **Analysis:**
>>
>> We are encountering a race condition in the native code. While retrieving
>> the screen number by calling _getScreenImOn(), the window is disposed. As a
>> result, the AWT-Windows event loop processes the Dispose() call
On Tue, 10 Jun 2025 21:33:22 GMT, Kevin Rushforth wrote:
> The following files still reference the now-removed applet classes and will
> fail to compile. Are they not included in any tier testing?
>
> ```
> test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphApplet.java
> test/hotspot/jtre
On Tue, 10 Jun 2025 22:44:16 GMT, Phil Race wrote:
>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring
> This is the implementation of JEP 504 - Remove the Applet API.
> API changes are
> - Remove the entire java.applet package
> - Remove the javax/swing/JApplet class
> - Remove applet related APIs in java.beans
> - Update javadoc referring to applets, including one gif image - now changed
> to an
On Tue, 10 Jun 2025 21:23:42 GMT, Damon Nguyen wrote:
>> I guess it's not the first time that we've encountered such an issue where
>> using `PassFailJFrame` changes the behaviour of the test. Was it
>> @TejeshR13's test?
>>
>> I'm confused because `PassFailJFrame` does nothing more than provi
> **Analysis:**
>
> We are encountering a race condition in the native code. While retrieving the
> screen number by calling _getScreenImOn(), the window is disposed. As a
> result, the AWT-Windows event loop processes the Dispose() call, which
> triggers UnlinkObjects().
> The race condition b
On Tue, 10 Jun 2025 21:28:56 GMT, Phil Race wrote:
>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring
> Some useful methods in ExtendedRobot should be migrated into Robot itself so
> that ExtendedRobot can be removed in the future. The tests using
> ExtendedRobot for these migrated methods are changed to use only Robot
> (removing unnecessary building of ExtendedRobot).
Alisen Chung has updated
On Mon, 24 Feb 2025 21:22:48 GMT, Alexander Zvegintsev
wrote:
>> Alisen Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> migrate type(char) method
>
> test/jdk/lib/client/ExtendedRobot.java line 368:
>
>> 366: * @see java
On Tue, 10 Jun 2025 21:28:56 GMT, Phil Race wrote:
>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring
> Some useful methods in ExtendedRobot should be migrated into Robot itself so
> that ExtendedRobot can be removed in the future. The tests using
> ExtendedRobot for these migrated methods are changed to use only Robot
> (removing unnecessary building of ExtendedRobot).
Alisen Chung has updated
On Tue, 10 Jun 2025 11:32:58 GMT, Anass Baya wrote:
>> check how the _SetFocusableWindow is implemented below.
>
> Hello @mrserb,
>
>> I think the only thing you should do is to replace the usage of
>> JNI_GET_PDATA by the JNI_CHECK_PEER_GOTO and add a label "ret" at the end so
>> default valu
On Tue, 10 Jun 2025 20:50:07 GMT, Alisen Chung wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8359053
>
> src/java.desktop/share/classes/java/awt/Polygon.java line 163:
>
>> 161: throw new NegativeArrayS
> This is the implementation of JEP 504 - Remove the Applet API.
> API changes are
> - Remove the entire java.applet package
> - Remove the javax/swing/JApplet class
> - Remove applet related APIs in java.beans
> - Update javadoc referring to applets, including one gif image - now changed
> to an
On Tue, 10 Jun 2025 21:14:38 GMT, Alexey Ivanov wrote:
>> I have attached the standalone test to the issue. I tried altering how
>> `ListDragCursor.java` creates the UI but it seems that no matter what I do,
>> the cursor still updates after 1 second. I'm looking into what
>> `PassFailJFrame`
On Tue, 10 Jun 2025 21:17:46 GMT, Alexey Ivanov wrote:
>> Currently, you problem-listing the test referencing the bug JDK-8359061,
>> which is being fixed by this PR. Once you integrate it, JDK-8359061 will be
>> resolved. Thus, the problem-list entry refers to the bug that's already
>> resolv
On Tue, 10 Jun 2025 21:10:09 GMT, Alexey Ivanov wrote:
>> Should I update the issue number here to
>> [7177297](https://bugs.openjdk.org/browse/JDK-7177297)? I'm not fully
>> grasping the Skara bot's error message.
>
> Currently, you problem-listing the test referencing the bug JDK-8359061,
>
> This change is to restore the original intent of the test by updating the
> instructions to check that the type of Cursor is preserved when clicked and
> dragged. Now the test correctly has instructions to check that an I-beam
> cursor stays an I-beam until released over a List with its cursor
> Some useful methods in ExtendedRobot should be migrated into Robot itself so
> that ExtendedRobot can be removed in the future. The tests using
> ExtendedRobot for these migrated methods are changed to use only Robot
> (removing unnecessary building of ExtendedRobot).
Alisen Chung has updated
On Tue, 10 Jun 2025 19:56:13 GMT, Damon Nguyen wrote:
>> It seems like there's a bug with this test when using it in a
>> `PassFailJFrame`. When I move the `createUI` logic into a standalone java
>> class's main method and add `setVisible(true)`, the test works as expected
>> for all OS's exce
On Mon, 9 Jun 2025 21:48:59 GMT, Phil Race wrote:
>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring t
On Tue, 10 Jun 2025 19:35:45 GMT, Damon Nguyen wrote:
>> Doesn't seem right either. There's a warning about this from the Skara bot.
>
> Should I update the issue number here to
> [7177297](https://bugs.openjdk.org/browse/JDK-7177297)? I'm not fully
> grasping the Skara bot's error message.
Cu
On Mon, 9 Jun 2025 21:48:59 GMT, Phil Race wrote:
>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring t
On Tue, 10 Jun 2025 19:32:51 GMT, Damon Nguyen wrote:
>> Perhaps, the instructions need to be adjusted for each OS, or the test
>> should be limited to a specific OS only.
>
> It seems like there's a bug with this test when using it in a
> `PassFailJFrame`. When I move the `createUI` logic into
Hello,
I'd like to ask whether a backport of:
https://github.com/openjdk/jdk/pull/24614
to the stabilisation branch of JDK-25 would have a chance to be
accepted. The PR fixes two issues:
JDK-8332271: Reading data from the clipboard from multiple threads crashes the
JVM (P3)
JDK-8353950: Clipbo
On Tue, 10 Jun 2025 13:21:58 GMT, Alexey Ivanov wrote:
>> test/jdk/ProblemList.txt line 837:
>>
>>> 835: java/awt/Menu/MenuVisibilityTest.java 8161110 macosx-all
>>> 836: java/awt/Modal/NativeDialogToFrontBackTest.java 7188049
>>> windows-all,linux-all
>>> 837: java/awt/Cursor/CursorDragTest/Li
On Tue, 10 Jun 2025 13:19:40 GMT, Alexey Ivanov wrote:
>> test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 52:
>>
>>> 50: pass the test. This test fails if the cursor updates
>>> 51: when pointing over the different components before
>>> 52:
On Tue, 10 Jun 2025 13:21:14 GMT, Alexey Ivanov wrote:
>> This change is to restore the original intent of the test by updating the
>> instructions to check that the type of Cursor is preserved when clicked and
>> dragged. Now the test correctly has instructions to check that an I-beam
>> curs
On Tue, 10 Jun 2025 16:22:52 GMT, Jeremy Wood wrote:
>> Make sure AquaTextPasswordFieldUI can't use selectWordAction.
>>
>> The core problem here was we could call selectWordAction in the Aqua LAF on
>> a JPasswordField. This problem was already solved in the
>> BasicPasswordFieldUI . The same
On Tue, 10 Jun 2025 11:41:15 GMT, Alexey Ivanov wrote:
>> Since the code isn't conditionalised on applets, I don't think it should be
>> changed as part of this PR
>
> Shall I submit a bug to consider removing this code?
>
> Without the comment and an issue to track it, no one will ever remembe
On Tue, 10 Jun 2025 16:09:13 GMT, Renjith Kannath Pariyangad
wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [2103dc15](https://github.com/openjdk/jdk/commit/2103dc15cb662fd8795b1b51d9cb61c389bed7a0)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
On Tue, 10 Jun 2025 16:22:52 GMT, Jeremy Wood wrote:
>> Make sure AquaTextPasswordFieldUI can't use selectWordAction.
>>
>> The core problem here was we could call selectWordAction in the Aqua LAF on
>> a JPasswordField. This problem was already solved in the
>> BasicPasswordFieldUI . The same
On Tue, 10 Jun 2025 16:09:13 GMT, Renjith Kannath Pariyangad
wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [2103dc15](https://github.com/openjdk/jdk/commit/2103dc15cb662fd8795b1b51d9cb61c389bed7a0)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
On Tue, 10 Jun 2025 16:20:58 GMT, Alexander Zvegintsev
wrote:
>> Hi all,
>>
>> This pull request contains a backport of commit
>> [2103dc15](https://github.com/openjdk/jdk/commit/2103dc15cb662fd8795b1b51d9cb61c389bed7a0)
>> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>>
On Tue, 10 Jun 2025 16:09:13 GMT, Renjith Kannath Pariyangad
wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [2103dc15](https://github.com/openjdk/jdk/commit/2103dc15cb662fd8795b1b51d9cb61c389bed7a0)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
On Tue, 10 Jun 2025 13:25:20 GMT, Alexey Ivanov wrote:
>> Jeremy Wood has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8354646: moving test file back to basic package
>>
>> This is in response to:
>> https://github.com/openjdk/jdk/
> Make sure AquaTextPasswordFieldUI can't use selectWordAction.
>
> The core problem here was we could call selectWordAction in the Aqua LAF on a
> JPasswordField. This problem was already solved in the BasicPasswordFieldUI .
> The same solution was copied and pasted into the SynthPasswordFieldU
Hi all,
This pull request contains a backport of commit
[2103dc15](https://github.com/openjdk/jdk/commit/2103dc15cb662fd8795b1b51d9cb61c389bed7a0)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Alexander Zvegintsev on 9 Jun
2025
On Tue, 10 Jun 2025 15:48:17 GMT, Matthias Bläsing
wrote:
>> Matthias Bläsing has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Limit running test only on windows
>
> Thank you all for helping to get this in!
Thank you @matthiasblaesing
On Wed, 4 Jun 2025 17:14:15 GMT, Matthias Bläsing wrote:
>> - Introduce a lock into WClipboard that protects the code between
>> openClipboard/closeClipboard invocations.
>> The native side does not allow to open the clipboard multiple
>> times or share the opened clipboard between multiple
On Mon, 9 Jun 2025 21:48:59 GMT, Phil Race wrote:
>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring t
On Mon, 9 Jun 2025 21:41:12 GMT, Jeremy Wood wrote:
>> Make sure AquaTextPasswordFieldUI can't use selectWordAction.
>>
>> The core problem here was we could call selectWordAction in the Aqua LAF on
>> a JPasswordField. This problem was already solved in the
>> BasicPasswordFieldUI . The same
On Mon, 9 Jun 2025 21:17:22 GMT, Damon Nguyen wrote:
> This change is to restore the original intent of the test by updating the
> instructions to check that the type of Cursor is preserved when clicked and
> dragged. Now the test correctly has instructions to check that an I-beam
> cursor sta
On Tue, 10 Jun 2025 00:36:24 GMT, Harshitha Onkar wrote:
>> This change is to restore the original intent of the test by updating the
>> instructions to check that the type of Cursor is preserved when clicked and
>> dragged. Now the test correctly has instructions to check that an I-beam
>> cu
On Tue, 10 Jun 2025 07:27:41 GMT, Prasanta Sadhukhan
wrote:
>>> What condition?
>>
>> I just meant the int overflow condition. That test is not meant to
>> demonstrate an OOM.
>>
>> I understand why an OOM feels related to this ticket (and maybe that really
>> is the compelling concern here
On Fri, 6 Jun 2025 03:29:47 GMT, Prasanta Sadhukhan
wrote:
> ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow.
>
> Theoretically there is a possibility that there can be overflow in the long
> time run or for large number of created "imageIcon"
>
> Made sure there is no
On Mon, 9 Jun 2025 21:48:59 GMT, Phil Race wrote:
>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring t
On Tue, 3 Jun 2025 17:11:12 GMT, Alexey Ivanov wrote:
>> The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test
>> are still not as clear.
>>
>> The file name in the instructions is rendered as HTML, which, I believe, is
>> unexpected. It should be displayed as the plain te
On Tue, 10 Jun 2025 04:41:54 GMT, Tejesh R wrote:
> Test for the fix : test/jdk/javax/swing/JFileChooser/HTMLFileName.java
I add 8358532 to the `@bug` tag of `HTMLFileName.java`.
-
Changes requested by aivanov (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/25707#pullreque
On Mon, 9 Jun 2025 20:50:24 GMT, Phil Race wrote:
>> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line
>> 108:
>>
>>> 106: * Checks if vsync painting is requested for {@code rootContainer}
>>> 107: *
>>> 108: * @param rootContainer topmost container. Sho
On Mon, 9 Jun 2025 20:48:47 GMT, Phil Race wrote:
>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line
>> 437:
>>
>>> 435: styleBits = SET(styleBits, TEXTURED, false);
>>> 436: styleBits = SET(styleBits, NONACTIVATING, true);
>>> 437:
On Tue, 10 Jun 2025 07:40:07 GMT, Sergey Bylokhov wrote:
>>> Yes, we can do that. I had the idea to use it so that UnlinkObjects() would
>>> be invoked by the EDT, which would eliminate the race condition.
>>
>> Looks like the UnlinkObjects and _GetScreenImOn is already executed under
>> the
On Tue, 10 Jun 2025 03:18:25 GMT, Anass Baya wrote:
> Yes, we can do that. I had the idea to use it so that UnlinkObjects() would
> be invoked by the EDT, which would eliminate the race condition.
Looks like the UnlinkObjects and _GetScreenImOn is already executed under the
same lock:
- WCom
On Tue, 10 Jun 2025 07:14:06 GMT, Sergey Bylokhov wrote:
>> Hello @mrserb,
>> Yes, we can do that. I had the idea to use it so that UnlinkObjects() would
>> be invoked by the EDT, which would eliminate the race condition.
>> I didn’t proceed with it initially because I saw in that file that this
On Tue, 10 Jun 2025 05:59:07 GMT, Jeremy Wood wrote:
> OK. This feels too theoretical for me to invest strongly in a recommendation.
That's why I mentioned in the description itself
> Theoretically there is a possibility that there can be overflow in the long
> time run or for large number of
67 matches
Mail list logo
