Re: RFR: 8346388: Cannot use DllMain in libawt for static builds

On Wed, 18 Dec 2024 19:53:10 GMT, Magnus Ihse Bursie wrote: > > DllMain is a default name, not a required name. You could just rename them > > and add /entry to the linker command line, eg /entry:AwtDllMain > > That was an interesting piece of information I did not know. That could be > used t

Re: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v2]

> For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method > of the `AccessBridge` class cuts the _Comma_ text to the first character and > hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a > shortcut _Ctrl + Comma_ in a menu item, screen readers announ

Re: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class

On Thu, 19 Dec 2024 05:17:07 GMT, Abhishek Kumar wrote: > For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method > of the `AccessBridge` class cuts the _Comma_ text to the first character and > hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a > sho

RFR: 8339728 : [Accessibility,Windows,JAWS] Bug in the getKeyChar method of the AccessBridge class

For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl

Re: RFR: 8346394: Bundled freetype library needs to have JNI_OnLoad for static builds [v3]

On Wed, 18 Dec 2024 10:14:45 GMT, Magnus Ihse Bursie wrote: > The solution chosen by the original implementors of static builds was to look > for a symbol JNI_OnLoad_someInternalLibrary, and if it was found, skip > loading the dynamic library. Is that necessary? Presumably if you try to dynam

Re: RFR: 8208377: Soft hyphens render if not using TextLayout

On Tue, 10 Dec 2024 20:09:09 GMT, Daniel Gredler wrote: > Soft hyphens should never render, regardless of the rendering path used > internally. > > This PR does not expand the categorization of "complex" characters in > `FontUtilities` in order to force the use of `TextLayout` rendering code

Re: RFR: 8208377: Soft hyphens render if not using TextLayout

On Wed, 18 Dec 2024 20:40:53 GMT, Alisen Chung wrote: > The automated checks seem to have all passed What automated checks ? If you mean github actions I can assure you it is not running the test you wrote. It runs a VERY limited set of tests which doesn't include ANY desktop/clientlibs relat

Re: RFR: 8345144: Robot does not specify all causes of IllegalThreadStateException [v3]

On Wed, 11 Dec 2024 19:40:51 GMT, Alisen Chung wrote: >> When robot.autoWaitForIdle is set to true, all mouse and key-related methods >> when invoked on the EDT will throw java.lang.IllegalThreadStateException >> which is not in the Robot specification. >> >> This PR updates the specification

Withdrawn: 8326027: [TEST_BUG]Comparing buffered images of white background frame fails in Mac

On Thu, 29 Aug 2024 04:38:29 GMT, Tejesh R wrote: > On analysis of captured image, it is observed that there are few pixels which > vary slightly w.r.t to expected color. Hence tolerance is included in color > comparison. > Tested in mach5 multiple time and its green. This pull request has be

Integrated: 8346570: SM cleanup of tests for Beans and Serialization

On Wed, 18 Dec 2024 14:58:26 GMT, Roger Riggs wrote: > Continuing SM removal cleanup of tests for test/jdk/java/beans and > test/jdk/java/io/Serializable. > Removing doPrivileged, Permissions, and SecurityException. This pull request has now been integrated. Changeset: 55906692 Author:Rog

Re: RFR: 8208377: Soft hyphens render if not using TextLayout

On Tue, 10 Dec 2024 20:09:09 GMT, Daniel Gredler wrote: > Soft hyphens should never render, regardless of the rendering path used > internally. > > This PR does not expand the categorization of "complex" characters in > `FontUtilities` in order to force the use of `TextLayout` rendering code

Re: RFR: 8208377: Soft hyphens render if not using TextLayout

On Tue, 10 Dec 2024 20:09:09 GMT, Daniel Gredler wrote: > Soft hyphens should never render, regardless of the rendering path used > internally. > > This PR does not expand the categorization of "complex" characters in > `FontUtilities` in order to force the use of `TextLayout` rendering code

Re: RFR: 8208377: Soft hyphens render if not using TextLayout

On Wed, 11 Dec 2024 20:48:51 GMT, Alisen Chung wrote: >> Soft hyphens should never render, regardless of the rendering path used >> internally. >> >> This PR does not expand the categorization of "complex" characters in >> `FontUtilities` in order to force the use of `TextLayout` rendering cod

JDK-8165863 Retest

mserb made this comment for JDK-8342782: https://github.com/openjdk/jdk/pull/21962#issuecomment-2463540556 I couldn’t reproduce JDK-8165863 in OpenJDK before the resolution to JDK-8342782; I think it will be even harder to reproduce now. I don’t have permission to comment in the bug database;

Re: RFR: 8346388: Cannot use DllMain in libawt for static builds

On Wed, 18 Dec 2024 19:35:09 GMT, Phil Race wrote: > I'm not sure it seems right to have every static destructor need to know what > needs to be done to exit the DLL. That is an over-generalization of the problem at hand that is not really true. What we have is an unfortunate coupling between

Re: RFR: 8346388: Cannot use DllMain in libawt for static builds

On Wed, 18 Dec 2024 19:35:09 GMT, Phil Race wrote: > DllMain is a default name, not a required name. You could just rename them > and add /entry to the linker command line, eg /entry:AwtDllMain That was an interesting piece of information I did not know. That could be used to resolve issue 2.

Re: RFR: 8346388: Cannot use DllMain in libawt for static builds

On Tue, 17 Dec 2024 11:51:51 GMT, Magnus Ihse Bursie wrote: > There are multiple DllMain definitions throughout the JDK native libraries, > causing name collisions. DllMain is a default name, not a required name. You could just rename them and add /entry to the linker command line, eg /entry:

JDK-8344697 Heavy Performance Cost For Obsolete Aqua Button Repaints

Bug 8344697 points out that the Aqua L&F (in Swing) has logic to constantly repaint the JRootPane’s default button. I’m pretty sure that feature is now obsolete. Back with Mac OS Mavericks (Mac OS 10.9) the default button continu

Re: RFR: 8346570: SM cleanup of tests for Beans and Serialization

On Wed, 18 Dec 2024 14:58:26 GMT, Roger Riggs wrote: > Continuing SM removal cleanup of tests for test/jdk/java/beans and > test/jdk/java/io/Serializable. > Removing doPrivileged, Permissions, and SecurityException. Beans changes look fine - Marked as reviewed by prr (Reviewer).

Re: RFR: 8344191: Build code should not have classpath exception [v2]

On Wed, 18 Dec 2024 17:06:02 GMT, Magnus Ihse Bursie wrote: >> In several (most? all?) of the build system files, the copyright header >> includes the classpath exception. This makes no sense, and should be >> removed. >> >> I have removed the classpath exception from makefiles, autoconf, she

Re: RFR: 8346570: SM cleanup of tests for Beans and Serialization

On Wed, 18 Dec 2024 14:58:26 GMT, Roger Riggs wrote: > Continuing SM removal cleanup of tests for test/jdk/java/beans and > test/jdk/java/io/Serializable. > Removing doPrivileged, Permissions, and SecurityException. Marked as reviewed by lancea (Reviewer). - PR Review: https://gi

Re: RFR: 8344191: Build code should not have classpath exception [v2]

> In several (most? all?) of the build system files, the copyright header > includes the classpath exception. This makes no sense, and should be removed. > > I have removed the classpath exception from makefiles, autoconf, shell > scripts, properties files, configuration files, IDE support file

RFR: 8346570: SM cleanup of tests for Beans and Serialization

Continuing SM removal cleanup of tests for test/jdk/java/beans and test/jdk/java/io/Serializable. Removing doPrivileged, Permissions, and SecurityException. - Commit messages: - 8346570: SM cleanup of tests for Beans and Serialization Changes: https://git.openjdk.org/jdk/pull/2281

Integrated: 8346324: javax/swing/JScrollBar/4865918/bug4865918.java fails in CI

On Tue, 17 Dec 2024 07:44:11 GMT, Prasanta Sadhukhan wrote: > javax/swing/JScrollBar/4865918/bug4865918.java fails in CI citing > > java.lang.RuntimeException: The scrollbar block increment is incorrect > at bug4865918.main(bug4865918.java:60) > > Seems like scrollbar is not in focus when mou

Re: RFR: 8346324: javax/swing/JScrollBar/4865918/bug4865918.java fails in CI [v4]

On Wed, 18 Dec 2024 12:55:50 GMT, Prasanta Sadhukhan wrote: >> javax/swing/JScrollBar/4865918/bug4865918.java fails in CI citing >> >> java.lang.RuntimeException: The scrollbar block increment is incorrect >> at bug4865918.main(bug4865918.java:60) >> >> Seems like scrollbar is not in focus wh

Re: RFR: 8346324: javax/swing/JScrollBar/4865918/bug4865918.java fails in CI [v3]

On Wed, 18 Dec 2024 12:45:45 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one >> additional commit since the last revision: >> >> import > > test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java line 59: > >> 57: >> 58: SwingU

Re: RFR: 8346324: javax/swing/JScrollBar/4865918/bug4865918.java fails in CI [v4]

> javax/swing/JScrollBar/4865918/bug4865918.java fails in CI citing > > java.lang.RuntimeException: The scrollbar block increment is incorrect > at bug4865918.main(bug4865918.java:60) > > Seems like scrollbar is not in focus when mouse is pressed..Used > CountDownLatch to mage focus gain more d

Re: RFR: 8346324: javax/swing/JScrollBar/4865918/bug4865918.java fails in CI [v3]

On Wed, 18 Dec 2024 06:55:12 GMT, Prasanta Sadhukhan wrote: >> javax/swing/JScrollBar/4865918/bug4865918.java fails in CI citing >> >> java.lang.RuntimeException: The scrollbar block increment is incorrect >> at bug4865918.main(bug4865918.java:60) >> >> Seems like scrollbar is not in focus wh

Re: RFR: 8346324: javax/swing/JScrollBar/4865918/bug4865918.java fails in CI [v3]

On Wed, 18 Dec 2024 06:55:12 GMT, Prasanta Sadhukhan wrote: >> javax/swing/JScrollBar/4865918/bug4865918.java fails in CI citing >> >> java.lang.RuntimeException: The scrollbar block increment is incorrect >> at bug4865918.main(bug4865918.java:60) >> >> Seems like scrollbar is not in focus wh

Re: RFR: 8346394: Bundled freetype library needs to have JNI_OnLoad for static builds [v3]

On Wed, 18 Dec 2024 04:48:53 GMT, David Holmes wrote: > A bit late but why do we presume that just because this library is bundled > that it has to be part of the static image? No? The library can be bundled as a dynamic library as well, that has always been and still is the case. > This stat

awt_LoadLibrary.c & co.

Hello, I can see on the list that updates to this file are debated based on an ASAN report. I'd like to bring this PR in review to your attention as it touches the very same file: https://github.com/openjdk/jdk/pull/20169 Thx Cheers K. -- Sent from my Hosaka Ono-Sendai Cyberspace 7 -- Karm M

Re: RFR: 8346059: [ASAN] awt_LoadLibrary.c reported compile warning ignoring return value of function by clang17

On Tue, 17 Dec 2024 15:27:30 GMT, Phil Race wrote: >> Sorry for the confuse. I mean this PR change nothing except it will print a >> message to stderr when realpath return NULL. Thanks magicus. > > Why did you integrate this ? > It did not yet have my approval even though I was clearly reviewing

Re: RFR: 8346059: [ASAN] awt_LoadLibrary.c reported compile warning ignoring return value of function by clang17

On Thu, 12 Dec 2024 04:32:14 GMT, SendaoYan wrote: > Hi all, > This PR fix file src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c > reported compile warning "ignoring return value of function" by clang17, > which add check the return value of `realpath` function. Risk is low. Drive-By

Integrated: 8342782: AWTEventMulticaster throws StackOverflowError using AquaButtonUI

On Thu, 7 Nov 2024 17:49:29 GMT, Jeremy wrote: > The AWTEventMulticaster is a tree node with 2 children. This PR proposes > rebalancing that tree after ~~500~~ 100 additions to avoid potential > StackOverflowErrors when trying to interact with a large AWTEventMulticaster. > > In the original h

Re: RFR: 8346059: [ASAN] awt_LoadLibrary.c reported compile warning ignoring return value of function by clang17

On Tue, 17 Dec 2024 15:27:30 GMT, Phil Race wrote: >> Sorry for the confuse. I mean this PR change nothing except it will print a >> message to stderr when realpath return NULL. Thanks magicus. > > Why did you integrate this ? > It did not yet have my approval even though I was clearly reviewing