From javalists at cbfiddle.com Mon May 1 01:43:49 2023 From: javalists at cbfiddle.com (Alan Snyder) Date: Sun, 30 Apr 2023 18:43:49 -0700 Subject: RFR: 6176679: Application freezes when copying an animated gif image to the system clipboard [v10] In-Reply-To: References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> Message-ID: <56A54768-297E-42F3-A250-0A4AB24F3BA2@cbfiddle.com> Your changes look reasonable. I have a suggestion. Unless IDEA is lying to me, all uses of reconstruct() pass ALLBITS as the parameter. The net effect is to wait for any of the three terminating conditions, ALLBITS, FRAMEBITS, and ERROR. My suggestion would be to eliminate the parameter, add ALLBITS to the test in the loop, and rename the method waitForTermination() or something like that. (The existing method can hang if ALLBITS is not true in the parameter, which makes the method unnecessarily fragile.) > I am not sure what you mean by native image. Could you please clarify ? I think I was mistaken. I tried again and was able to run your test. > On Apr 30, 2023, at 2:36 PM, Rajat Mahajan wrote: > > On Thu, 20 Apr 2023 19:26:52 GMT, Rajat Mahajan > wrote: > >>> **Problem:** >>> >>> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time. >>> Due to this infinite wait the application freezes. >>> >>> **Proposed Fix:** >>> >>> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. >>> After this change I see the GIF image being correctly copied and animated. >>> >>> >>> **Testing:** >>> >>> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5. >> >> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update CopyAnimatedGIFTest.java > >> _Mailing list message from [Alan Snyder](mailto:javalists at cbfiddle.com) on [client-libs-dev](mailto:client-libs-dev at mail.openjdk.org):_ >> >> I was hoping to be able to run your test program, but I cannot because on macOS there is no support for transferring a native image. >> >> It also appears that I cannot simulate the transfer code because that code depends upon the reconstruct method, which is not public. >> >> Just looking at the code, I think it is not correct. >> >> It looks to me that the ImageRepresentation.drawToBufImage method is called only once, and it will do nothing unless ALLBITS or FRAMEBITS is true. I do not see any loop that would call it multiple times. (If I am correct about this, then only the first frame is drawn into the buffered image, which makes much more sense than drawing every frame into the buffered image. One might ask, however, what a user is trying to accomplish by copying an animated image to the system clipboard?) >> >> So, it works if reconstruct() waits until ALLBITS or FRAMEBITS is true. But your change does not test for FRAMEBITS in the loop, so it will only work if FRAMEBITS is already true when reconstruct() is called. >> >> How can that happen? >> >> I think it works because you are displaying the image on the screen, and the animation code is reading frames. >> >> I suggest trying the test without displaying the image. > > Thanks for your suggestions. I have modified the code so it works for both cases where image is and is not displayed on screen. > I have modified the test so it tests for both these cases. > >> Also, your test would better if it retrieved the native image from the system clipboard to verify that it was successfully transferred. You would need to clear the system clipboard before running the test to be sure you are not retrieving something from a previous test run. > > I am not sure what you mean by native image. Could you please clarify ? > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/13414#issuecomment-1529141085 -------------- next part -------------- An HTML attachment was scrubbed... URL: From psadhukhan at openjdk.org Mon May 1 04:58:27 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 1 May 2023 04:58:27 GMT Subject: Integrated: 8305780: javax/swing/JTable/7068740/bug7068740.java fails on Ubunutu 20.04 In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 03:47:04 GMT, Prasanta Sadhukhan wrote: > Although not able to reproduce this locally or in mach5, it can happen when robot key movements start happening before frame is visible, > so added stability fixes like delay of 1s after frame is visible and key movements are done, added waitForIdle, increase autodelay time, added frame dispose also at end. > > Several iterations of the test pass in all platforms. Link in JBS This pull request has now been integrated. Changeset: e1b06eac Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/e1b06eac722ea19ed33fbd15e763ca983aab34f2 Stats: 87 lines in 1 file changed: 28 ins; 30 del; 29 mod 8305780: javax/swing/JTable/7068740/bug7068740.java fails on Ubunutu 20.04 Reviewed-by: serb, tr ------------- PR: https://git.openjdk.org/jdk/pull/13416 From psadhukhan at openjdk.org Mon May 1 04:58:26 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 1 May 2023 04:58:26 GMT Subject: Integrated: 8299713: Test javax/swing/JTableHeader/6889007/bug6889007.java failed: Wrong type of cursor In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 08:32:33 GMT, Prasanta Sadhukhan wrote: > Issue seems to be very old, very intermittent bug which is not reproducible in repeated test run, > so added some stability fixes like accessing swing components in EDT, delay, frame dispose and take a screenshot during fail. > Multiple runs on CI platforms is ok. This pull request has now been integrated. Changeset: b54c4a33 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/b54c4a33c69e16adf5b85b80b8deb4ded2ed074d Stats: 64 lines in 1 file changed: 40 ins; 5 del; 19 mod 8299713: Test javax/swing/JTableHeader/6889007/bug6889007.java failed: Wrong type of cursor Reviewed-by: serb, tr ------------- PR: https://git.openjdk.org/jdk/pull/12181 From psadhukhan at openjdk.org Mon May 1 05:09:26 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 1 May 2023 05:09:26 GMT Subject: Integrated: 8305778: javax/swing/JTableHeader/6884066/bug6884066.java: Unexpected header's value; index = 4 value = E In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 05:04:02 GMT, Prasanta Sadhukhan wrote: > Although not reproducible locally or in mach5, some stability fixes have been added in the test like > induce 1s delay after frame is made visible, increase autodelay time, move frame to center of screen and also dispose frame at end. > > Modified test pass for several iterations in all platforms. Link in JBS This pull request has now been integrated. Changeset: 2d7c5079 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/2d7c50791bd79d9a140df12e38050c851423992c Stats: 61 lines in 1 file changed: 26 ins; 8 del; 27 mod 8305778: javax/swing/JTableHeader/6884066/bug6884066.java: Unexpected header's value; index = 4 value = E Reviewed-by: serb, jdv ------------- PR: https://git.openjdk.org/jdk/pull/13417 From alanb at openjdk.org Mon May 1 05:52:22 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 May 2023 05:52:22 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image In-Reply-To: <-LR0qy8lzfy0N6sksIJNnVxAIesh0yQmRNYrG5pvG2I=.52637aed-bbc2-4ea8-a134-d148c91f2953@github.com> References: <-LR0qy8lzfy0N6sksIJNnVxAIesh0yQmRNYrG5pvG2I=.52637aed-bbc2-4ea8-a134-d148c91f2953@github.com> Message-ID: On Sun, 30 Apr 2023 18:53:40 GMT, Jorn Vernee wrote: > It seems that letting jlink do the linking is also a requirement for user provided modules (.jmods) that contain native libraries (as is the case for instance with jextract). We don't know about those libraries when building the JDK. For now yes, but if there are further steps to have it create a single executable then the classes/resources will also be included. So I think pure Java modules will also be in this picture, eventually. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1529373589 From erikj at openjdk.org Mon May 1 14:21:23 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 1 May 2023 14:21:23 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image In-Reply-To: References: <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com> Message-ID: On Fri, 28 Apr 2023 23:25:17 GMT, Erik Joelsson wrote: >>> I pulled this PR and had a go at building it. For me it failed with errors like this: >>> >>> ``` >>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_clock_init(): error: undefined reference to 'clock_getres' >>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_cpu_time(int): error: undefined reference to 'clock_gettime' >>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(): error: undefined reference to 'clock_gettime' >>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::thread_cpu_time(Thread*): error: undefined reference to 'clock_gettime' >>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(bool): error: undefined reference to 'clock_gettime' >>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::init_2(): error: undefined reference to 'clock_getres' >>> ``` >>> >>> I haven't dug any deeper to try to figure this out. Is this something you recognize? >> >> Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build: >> >> >> /usr/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o /.../build/linux-x86_64-server-slowdebug/jdk/bin/javastatic /.../linux-x86_64-server-slowdebug/support/native/java.base/java/main.o -Wl,--whole-archive /.../linux-x86_64-server-slowdebug/images/static-libs/lib/libattach.a ... /.../linux-x86_64-server-slowdebug/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a >> >> >> `clock_getres` and the other related symbols are provided by `libc`. For `libc`, we don't static link with. We still use `libc.so`. >> >> >> $ ldd jdk/bin/javastatic >> linux-vdso.so.1 (0x00007fff8b17a000) >> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0845321000) >> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0845140000) >> /lib64/ld-linux-x86-64.so.2 (0x00007f084888d000) >> >> >> >> $ objdump -Tw /lib/x86_64-linux-gnu/libc.so.6 | grep clock_getres >> 00000000000cf260 g DF .text 0000000000000069 GLIBC_2.17 clock_getres >> 00000000000cf260 g DF .text 0000000000000069 (GLIBC_2.2.5) clock_getres >> >> $ nm jdk/bin/javastatic | grep clock_gettime >> U clock_gettime at GLIBC_2.17 >> $ nm jdk/bin/javastatic | grep clock_getres >> U clock_getres at GLIBC_2.17 > >> Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build: > > I can't see any significant difference. I'm using a devkit created using the devkit makefiles. > > > .../devkit-linux_x64-gcc11.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o .../build/linux-x64/jdk/bin/javastatic /home/erik/git/jdk/build/linux-x64/support/native/java.base/java/main.o -Wl,--whole-archive .../build/linux-x64/images/static-libs/lib/libattach.a ... .../build/linux-x64/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a > Based on the above finding, I pushed a change to use $(JVM_LIBS) for the linking command. @erikj79 could you please see if that resolves the clock_* symbol issues in your environment? Yes, it built cleanly with that change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1529742147 From rriggs at openjdk.org Mon May 1 15:41:24 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 1 May 2023 15:41:24 GMT Subject: Integrated: 8304915: Create jdk.internal.util.Architecture enum and apply In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 5 Apr 2023 15:58:08 GMT, Roger Riggs wrote: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The value of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. This pull request has now been integrated. Changeset: f00a748b Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/f00a748bc5b708d4f8f277d075859b058f9d575c Stats: 411 lines in 7 files changed: 343 ins; 57 del; 11 mod 8304915: Create jdk.internal.util.Architecture enum and apply Reviewed-by: erikj, mdoerr, amitkumar ------------- PR: https://git.openjdk.org/jdk/pull/13357 From rmahajan at openjdk.org Mon May 1 20:10:28 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Mon, 1 May 2023 20:10:28 GMT Subject: RFR: 6176679: Application freezes when copying an animated gif image to the system clipboard [v11] In-Reply-To: References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> Message-ID: On Sun, 30 Apr 2023 21:34:53 GMT, Rajat Mahajan wrote: >> **Problem:** >> >> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time. >> Due to this infinite wait the application freezes. >> >> **Proposed Fix:** >> >> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. >> After this change I see the GIF image being correctly copied and animated. >> >> >> **Testing:** >> >> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5. > > Rajat Mahajan has updated the pull request incrementally with three additional commits since the last revision: > > - Update ImageRepresentation.java > > code cleanup > - Update ImageRepresentation.java > > code cleanup > - update fix to work for both cases where image is displayed and not displayed > _Mailing list message from [Alan Snyder](mailto:javalists at cbfiddle.com) on [client-libs-dev](mailto:client-libs-dev at mail.openjdk.org):_ > > Your changes look reasonable. > > I have a suggestion. Unless IDEA is lying to me, all uses of reconstruct() pass ALLBITS as the parameter. > > The net effect is to wait for any of the three terminating conditions, ALLBITS, FRAMEBITS, and ERROR. > > My suggestion would be to eliminate the parameter, add ALLBITS to the test in the loop, and rename the method waitForTermination() or something like that. > > (The existing method can hang if ALLBITS is not true in the parameter, which makes the method unnecessarily fragile.) > > > I am not sure what you mean by native image. Could you please clarify ? > > I think I was mistaken. I tried again and was able to run your test. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: Thanks Alan for this suggestion. I have created a new JBS bug [JDK-8307183](https://bugs.openjdk.org/browse/JDK-8307183) for refactoring this code as I thought it is not in scope of this bug and would do it as a follow up change to this one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13414#issuecomment-1530148379 From prr at openjdk.org Mon May 1 21:17:48 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 1 May 2023 21:17:48 GMT Subject: RFR: 8307133: Open source some JTable jtreg tests Message-ID: Open source some Swing JTable tests ------------- Commit messages: - 8307133 Changes: https://git.openjdk.org/jdk/pull/13745/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13745&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307133 Stats: 489 lines in 9 files changed: 489 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13745/head:pull/13745 PR: https://git.openjdk.org/jdk/pull/13745 From jiangli at openjdk.org Mon May 1 21:57:20 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 1 May 2023 21:57:20 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image In-Reply-To: References: Message-ID: <7jnvkVtSNboXfFD3ij19fWwDACENTUbFfBYf4_RCoP8=.21fc70f5-0470-4f4a-8770-b8aee9744e09@github.com> On Sun, 30 Apr 2023 18:34:12 GMT, Alan Bateman wrote: > > The build is already capable of producing .a files and this patch is building on top of that build feature. The current .a file creation is used by the downstream graal build which needs it for nativeimage. > > Also builds on recent changes to remove duplicate symbol names. It's good that the PR demonstrates that these can be linked to create "javastatic" but having it copy into the run-time image created by jlink is probably not the eventual outcome. > > A possible direction on this is for the build to create a set of packaged modules with the .a files, then have an alternative image builder in jlink that integrates with the native linker. Combined with other parts in Jiangli's slides/proposal, it would mean that jlink could produce a single executable that would work for both the JDK or any set of modules. The comment from @AlanBateman helped me realize that I should be more specific (in my earlier comment regarding "withdraw the current PR first and extract the .a part into a new PR") about the needed fixes/enhancements related to .a part: - Create libjvm.a as well when building static-libs-image target, include it in 'images/static-libs/lib' - Filter out "external" .o files (those are the .o files included from different JDK libraries and needed when creating the .so shared library only) from .a libraries - For libjvm.a specifically, exclude operator_new.o - Handle long arguments case for static build in make/common/NativeCompilation.gmk - Ensure zlib and freetype are bundled when building the static-libs-image target, i.e. libzlib.a and libfreetype.a are included in 'images/static-libs/lib' It's probably best to create a separate enhancement/bug for those (will create shortly) and continue using JDK-8303796 for the broader discussion/effort. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1530368068 From jiangli at openjdk.org Mon May 1 21:57:21 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 1 May 2023 21:57:21 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image In-Reply-To: References: <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com> Message-ID: On Mon, 1 May 2023 14:03:10 GMT, Erik Joelsson wrote: > > Based on the above finding, I pushed a change to use $(JVM_LIBS) for the linking command. @erikj79 could you please see if that resolves the clock_* symbol issues in your environment? > > Yes, it built cleanly with that change. Thanks for confirm. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1530369506 From jiangli at openjdk.org Mon May 1 22:50:27 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 1 May 2023 22:50:27 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image [v2] In-Reply-To: References: Message-ID: On Sat, 29 Apr 2023 03:57:53 GMT, Jiangli Zhou wrote: >> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'. >> >> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later. >> >> To build the statically linked executable: >> >> 1. Configure the JDK build with --with-static-java=yes >> 2. Build static-java-image, e.g. 'make jdk-image static-java-image' >> >> The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately. >> >> Following is a summary of the changes in this PR: >> >> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac. >> >> - Changes in make/Main.gmk >> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library. >> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory. >> >> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary. >> >> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4. >> >> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed. >> >> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk. >> >> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well. >> >> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk. >> >> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Use $(JVM_LIBS), which includes -lrt on Linux currently. > Created https://bugs.openjdk.org/browse/JDK-8307194 for the need static library (.a handling) enhancements. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1530481290 From duke at openjdk.org Tue May 2 00:07:26 2023 From: duke at openjdk.org (duke) Date: Tue, 2 May 2023 00:07:26 GMT Subject: Withdrawn: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5 only on linux-aarch64 In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 11:49:27 GMT, Jayathirth D V wrote: > Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably. > > Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task. > > We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846. > > With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12761 From duke at openjdk.org Tue May 2 00:55:18 2023 From: duke at openjdk.org (duke) Date: Tue, 2 May 2023 00:55:18 GMT Subject: Withdrawn: JDK-8266245: AWT Test FullScreenInsets.java fails due to incorrect pixel color and wrong window bounds In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 18:03:42 GMT, Harshitha Onkar wrote: > The above test was failing due to incorrect pixel color and wrong window bounds on Mac-ARM, Windows and Linux platforms. > > The following changes have been made: > - Correct window bounds are obtained using the current ScreenDevice's DefaultConfig bounds (this test checks FullScreen functionality on multiple screen devices). > - Color tolerance has been added for color check > - Instead of scanning the full screen to check pixel color, vertical and horizontal scans are done at the far right and bottom end to ensure that window is in full screen mode w.r.t to screen device and the window bounds are as expected. > > CI testing passes on all platforms (tested 50 times per platform). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11462 From serb at openjdk.org Tue May 2 02:14:11 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 May 2023 02:14:11 GMT Subject: RFR: 8307132: Cleanup the code of sun.java2d.cmm.lcms package Message-ID: <_LRz2K4G7ZNjIO9C_5z2N9xWTfz25uUtRmefY2FRfkA=.d111a3fc-4264-43fb-a238-dc7129c61506@github.com> The description from big to small: - Our code to handle the image types we support is too generic, the LCMSImageLayout class can handle, byte, short, int, and double types, and many various properties of the image layout. As a result, we pass a couple of good parameters to the LCMSImageLayout and have to use safeXX methods in it to calculate the final layout, and then validate it. This patch moves the layout properties calculation to one place - the constructor of LCMSImageLayout, and from the outside of the class, we now pass only the data array and the number of components per pixel: - The usage of Double type is removed, we do not use that type currently, and do not plan to support it in the future. Note that we support the float type, and I tried to implement it, but unfortunately, it is [intentionally ](https://github.com/mm2/Little-CMS/issues/356)slow. So will continue to use short type instead of float. - Discussed a few times the `do { } while (false);` block is removed. ------------- Commit messages: - add a comment - Merge branch 'master' into cms_cleanup_v3 - Merge branch 'master' into cms_cleanup_v3 - 8307132: Cleanup the code of sun.java2d.cmm.lcms package Changes: https://git.openjdk.org/jdk/pull/13732/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13732&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307132 Stats: 211 lines in 3 files changed: 10 ins; 124 del; 77 mod Patch: https://git.openjdk.org/jdk/pull/13732.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13732/head:pull/13732 PR: https://git.openjdk.org/jdk/pull/13732 From abhiscxk at openjdk.org Tue May 2 06:34:50 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 2 May 2023 06:34:50 GMT Subject: RFR: 8306489: Open source AWT List related tests Message-ID: This PR is to open source List related AWT tests. ------------- Commit messages: - Few more tests open sourced - Open source List AWT tests Changes: https://git.openjdk.org/jdk/pull/13748/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13748&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306489 Stats: 819 lines in 7 files changed: 819 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13748.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13748/head:pull/13748 PR: https://git.openjdk.org/jdk/pull/13748 From azvegint at openjdk.org Tue May 2 11:09:42 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 2 May 2023 11:09:42 GMT Subject: RFR: 8306943: Open source several dnd AWT tests Message-ID: Open sourcing few more tests: java/awt/dnd/DnDAWTLockTest/DnDAWTLockTest.java java/awt/dnd/DragGestureInvokeLaterTest/DragGestureInvokeLaterTest.java java/awt/dnd/DragOverDropTargetPerformanceTest/DragOverDropTargetPerformanceTest.java java/awt/dnd/DragSourceDragEventModifiersTest/DragSourceDragEventModifiersTest.java java/awt/dnd/DragSourceGCrashTest/DragSourceGCrashTest.java Testing looks good. ------------- Commit messages: - initial Changes: https://git.openjdk.org/jdk/pull/13752/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13752&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306943 Stats: 1349 lines in 5 files changed: 1349 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13752/head:pull/13752 PR: https://git.openjdk.org/jdk/pull/13752 From psadhukhan at openjdk.org Tue May 2 11:13:00 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 2 May 2023 11:13:00 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v2] In-Reply-To: References: Message-ID: > Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. > In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. > Fixed by implementing the equality and hashCode method for CSS.FontSize class. > > All jtreg/jck tests are ok Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision: - Test fix - Test fix - Review comment address ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13405/files - new: https://git.openjdk.org/jdk/pull/13405/files/fddecfbb..e24c1405 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=00-01 Stats: 187 lines in 3 files changed: 126 ins; 60 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13405/head:pull/13405 PR: https://git.openjdk.org/jdk/pull/13405 From psadhukhan at openjdk.org Tue May 2 11:13:22 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 2 May 2023 11:13:22 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() In-Reply-To: References: Message-ID: On Mon, 10 Apr 2023 12:44:08 GMT, Prasanta Sadhukhan wrote: > Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. > In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. > Fixed by implementing the equality and hashCode method for CSS.FontSize class. > > All jtreg/jck tests are ok > The change looks good but it doesn't address the whole problem raised in the [JDK-7083187](https://bugs.openjdk.org/browse/JDK-7083187): `CSS.CssValue` does not implement `equals`. This fix addresses only one particular case: `CSS.FontSize` for `font-size` property. > > I do not think it resolves the problem _entirely_: `CssValue` and all its subclasses must implement `equals` method, otherwise adding another CSS attribute to `AttributeSet` will lead to this same issue described in the bug report. Yes, since CSS Attributes are quite extensive, I have only addressed part of it in this PR mainly CSS.Font properties.. Additional PR can be raised for other attributes in due course.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13405#issuecomment-1531285902 From aivanov at openjdk.org Tue May 2 12:21:16 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 2 May 2023 12:21:16 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() In-Reply-To: References: Message-ID: On Tue, 2 May 2023 11:10:14 GMT, Prasanta Sadhukhan wrote: > > The change looks good but it doesn't address the whole problem raised in the [JDK-7083187](https://bugs.openjdk.org/browse/JDK-7083187): `CSS.CssValue` does not implement `equals`. This fix addresses only one particular case: `CSS.FontSize` for `font-size` property. > > I do not think it resolves the problem _entirely_: `CssValue` and all its subclasses must implement `equals` method, otherwise adding another CSS attribute to `AttributeSet` will lead to this same issue described in the bug report. > > Yes, since CSS Attributes are quite extensive, I have only addressed part of it in this PR mainly CSS.Font properties.. Additional PR can be raised for other attributes in due course.. It sounds reasonable but you have to update the bug summary to make it clear that this bug resolves the issue for `CSS.FontSize` only. The current bug subject suggests `CSS.CssValue` which is the super class of `CSS.FontSize` was fixed but it's not the case. Then, I think you should create a new bug for `CSS.CssValue` right away: we know _the problem exists_. Someone else may take it up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13405#issuecomment-1531375420 From duke at openjdk.org Tue May 2 13:01:31 2023 From: duke at openjdk.org (Ravi Gupta) Date: Tue, 2 May 2023 13:01:31 GMT Subject: RFR: 8305427: Write a test Check whether focus changes as expected when requestFocus is used to traverse randomly around the window [v4] In-Reply-To: References: Message-ID: > This testcase Checking whether the Component becoming the Focus Owner and FocusEvent.FOCUS_GAINED will be received by the Component when the focus is requested on the component using requestFocus. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision: 8305427: CountDownLatch used ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13293/files - new: https://git.openjdk.org/jdk/pull/13293/files/2f071815..064595c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13293&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13293&range=02-03 Stats: 99 lines in 1 file changed: 50 ins; 23 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/13293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13293/head:pull/13293 PR: https://git.openjdk.org/jdk/pull/13293 From aivanov at openjdk.org Tue May 2 15:02:15 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 2 May 2023 15:02:15 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Fri, 28 Apr 2023 21:42:07 GMT, Phil Race wrote: > I guess this could (should?) be backported but Windows 10 is the oldest supported OS no matter what the JDK version. And only the more recent versions of Windows 10 at that ... I think it should be backported. The `OpenThemeDataForDpi` function was introduced in Windows 10 version 1703 which is already 5 years old and is unsupported, that is the function is available in the supported versions of Windows 10 and 11. I may be useful to be able to run Java on previous versions though, yet it's not a priority. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1182674817 From aivanov at openjdk.org Tue May 2 15:05:18 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 2 May 2023 15:05:18 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Fri, 28 Apr 2023 21:27:54 GMT, Sergey Bylokhov wrote: > Why does everything else use defaultDPI, is it possible that some values depend on the DPI? Because Swing's user space coordinates use the default 96dpi. Some values do depend on the DPI, yet layout code still uses the default DPI. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1182679379 From aivanov at openjdk.org Tue May 2 15:31:30 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 2 May 2023 15:31:30 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Thu, 27 Apr 2023 19:25:55 GMT, Rajat Mahajan wrote: > Problem: > > Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: > > - Scrawly ticks in checkboxes; > - Wrong circle relations in selected radio buttons. > > Root-cause: > We open theme on AWT Toolkit Window which always has Primary Monitor DPI. > Due to this when the app window goes to Secondary Screen with different DPI UI buttons > appear incorrectly rendered. > Following is a list proposed changes to fix this issue. > > > Proposed Fix with Summary of changes: > > 1. Open a new Theme Handle per the DPI of the Screen where the App window is. > --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. > window is. > > 2. GetPartSize() of icons returns size based on standard size = 96 DPI. > --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. > > 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. > -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. > > 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. > --> This helps make sure that for .25s scaling we get better rendering. > This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. > > As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. > > > Testing: > > Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. > > ___________________________________ > Monitor 1 | Monitor 2 > (Primary) | > | > 125% | 175% > 150% | 175% > 150% | 225% > 175% | 175% > 175% | 150% > 175% | 225% > _____________________ |_____________ > > Also tested on setup with scaling values of up-to 350%. src/java.desktop/share/classes/sun/swing/CachedPainter.java line 318: > 316: public Image getResolutionVariant(double destWidth, double destHeight) { > 317: int w = (int) Math.floor(destWidth + 0.5); > 318: int h = (int) Math.floor(destHeight + 0.5); Isn't it what `Region.clipRound` does? src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java line 63: > 61: > 62: import java.lang.Math; > 63: The imports should be sorted, static imports follow regular class imports. Please expand all wildcard imports with per-class imports, which is done when classes are updated. src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 108: > 106: if(dpiAwareWidgetToTheme.containsKey(dpi)) > 107: { > 108: if (!dpiAwareWidgetToTheme.get(dpi).isEmpty()) It is better to skip `containsKey` and use `get`; if `get` returns `null`, put the key into the map. src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 136: > 134: if (!dpiAwareWidgetToTheme.isEmpty()) { > 135: for (Long value : > 136: dpiAwareWidgetToTheme.get(dpi).values()) { I think it's still possible that `get(dpi)` returns `null`, you should handle `null` gracefully. src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 140: > 138: } > 139: dpiAwareWidgetToTheme.get(dpi).clear(); > 140: dpiAwareWidgetToTheme.clear(); You clear the entire map, yet it don't call `closeTheme` for dpi values other than the passed one. You should iterate over `dpiAwareWidgetToTheme.values().values()` (pseudo-code). src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 155: > 153: if(dpiAwareWidgetToTheme.containsKey(dpi)) > 154: { > 155: theme = dpiAwareWidgetToTheme.get(dpi).get(widget); Avoid using `contains` followed by `get`, use `get` instead and handle `null` value. src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 179: > 177: try { > 178: > 179: /* We get the part size vased on the theme for current screen DPI and pass it to paintBackground */ Suggestion: /* We get the part size based on the theme for current screen DPI and pass it to paintBackground */ src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 185: > 183: part, state, > 184: (int)d.getWidth(), > 185: (int)d.getHeight() , w, h, stride); Suggestion: d.width, d.height, w, h, stride); You can access the fields directly and avoid casting. src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 243: > 241: (JNIEnv* env, jclass klass, jstring widget, jint dpi) { > 242: > 243: LPCTSTR str = (LPCTSTR)JNU_GetStringPlatformChars(env, widget, NULL); I'd rather keep the original formatting for casts as well as for `JNIEnv *env` in the declaration. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1182682786 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1182685469 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1182690251 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1182694155 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1182696873 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1182699492 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1182702793 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1182704389 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1182709855 From aturbanov at openjdk.org Tue May 2 16:13:21 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 2 May 2023 16:13:21 GMT Subject: RFR: 8306871: Open source more AWT Drag & Drop tests In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 18:34:36 GMT, Damon Nguyen wrote: > This PR open sources more AWT DnD & Event related tests test/jdk/java/awt/event/InputEvent/MouseModsTest.java line 145: > 143: > 144: static int getKeycode(int ctrl) { > 145: switch(ctrl) { Suggestion: switch (ctrl) { test/jdk/java/awt/event/InputEvent/MouseModsTest.java line 154: > 152: > 153: static int getKeyModifier(int ctrl) { > 154: switch(ctrl) { Suggestion: switch (ctrl) { test/jdk/java/awt/event/InputEvent/MouseModsTest.java line 163: > 161: > 162: static int getMouseModifier(int btn) { > 163: switch(btn) { Suggestion: switch (btn) { test/jdk/java/awt/event/KeyEvent/AltGraphModifier.java line 83: > 81: if (modifierPress[i] == true) { > 82: if ((kp.getModifiersEx() & inputMasks[i]) == inputMasks[i]) { > 83: } else { Suggestion: } else { test/jdk/java/awt/event/KeyEvent/KeyTyped/CancelKeyTyped.java line 114: > 112: > 113: protected void printKey(KeyEvent evt) { > 114: switch(evt.getID()) { Suggestion: switch (evt.getID()) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13725#discussion_r1182760866 PR Review Comment: https://git.openjdk.org/jdk/pull/13725#discussion_r1182761072 PR Review Comment: https://git.openjdk.org/jdk/pull/13725#discussion_r1182761201 PR Review Comment: https://git.openjdk.org/jdk/pull/13725#discussion_r1182760384 PR Review Comment: https://git.openjdk.org/jdk/pull/13725#discussion_r1182759973 From prr at openjdk.org Tue May 2 16:55:16 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 2 May 2023 16:55:16 GMT Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical methods in its C API In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> Message-ID: <6CIO56TQgxgXbhgY7ae6etk1PsfrI2RrnABvrm5WTi8=.3f4d13c5-89b8-45e9-8a53-fefc3a76a0b1@github.com> On Sat, 29 Apr 2023 19:26:00 GMT, Julian Waters wrote: > In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge: > > addJavaEventNotification > removeJavaEventNotification > addAccessibilityEventNotification > removeAccessibilityEventNotification > > > However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future These don't seem to be part of the public API, so this is probably deliberate and not a bug. https://docs.oracle.com/javase/accessbridge/2.0.2/api.htm#jab-api-specification ------------- Changes requested by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13734#pullrequestreview-1409498512 From honkar at openjdk.org Tue May 2 17:51:12 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 2 May 2023 17:51:12 GMT Subject: RFR: JDK-8305815: Update Libpng to 1.6.39 Message-ID: Updated libpng to v1.6.39 ------------- Commit messages: - added missing GPLv2 header - .md file commit - libpng src changes Changes: https://git.openjdk.org/jdk/pull/13755/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13755&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305815 Stats: 101 lines in 10 files changed: 15 ins; 1 del; 85 mod Patch: https://git.openjdk.org/jdk/pull/13755.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13755/head:pull/13755 PR: https://git.openjdk.org/jdk/pull/13755 From achung at openjdk.org Tue May 2 17:59:17 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 2 May 2023 17:59:17 GMT Subject: RFR: 8307297: Move some DnD tests to open Message-ID: Adding some DnD tests ------------- Commit messages: - removed extra layer of directories - added tests Changes: https://git.openjdk.org/jdk/pull/13756/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13756&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307297 Stats: 1241 lines in 7 files changed: 1241 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13756/head:pull/13756 PR: https://git.openjdk.org/jdk/pull/13756 From prr at openjdk.org Tue May 2 17:59:18 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 2 May 2023 17:59:18 GMT Subject: RFR: 8307297: Move some DnD tests to open In-Reply-To: References: Message-ID: On Tue, 2 May 2023 17:49:39 GMT, Alisen Chung wrote: > Adding some DnD tests Remove the unnecessary extra folder level. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13756#issuecomment-1531898942 From duke at openjdk.org Tue May 2 18:00:22 2023 From: duke at openjdk.org (Jeremy) Date: Tue, 2 May 2023 18:00:22 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v2] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 11:13:00 GMT, Prasanta Sadhukhan wrote: >> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. >> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. >> Fixed by implementing the equality and hashCode method for CSS.FontSize class. >> >> All jtreg/jck tests are ok > > Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision: > > - Test fix > - Test fix > - Review comment address src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2323: > 2321: @Override > 2322: public boolean equals(Object val) { > 2323: return val instanceof CSS.FontFamily font && family == font.family; Is the `family` field interned somewhere? If it isn't, then should this be: return val instanceof CSS.FontFamily font && Objects.equals(family, font.family); For ex if we tweak the start of the FontFamily unit test as follows does it still pass? private static void testFontFamily() { StyleSheet ss = new StyleSheet(); SimpleAttributeSet a = new SimpleAttributeSet(); ss.addCSSAttribute( a, CSS.Attribute.FONT_FAMILY, "Sans-Serif"); SimpleAttributeSet b = new SimpleAttributeSet(); ss.addCSSAttribute( b, CSS.Attribute.FONT_FAMILY, "Sans-Serif"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1182870307 From aivanov at openjdk.org Tue May 2 18:13:18 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 2 May 2023 18:13:18 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v2] In-Reply-To: References: Message-ID: <6AMf-eKADne9JGixe0AxYWuSCpoT0zPLMSVJ32hg8LU=.77ff4752-a702-4dad-bf80-e44cd91985f0@github.com> On Tue, 2 May 2023 17:57:00 GMT, Jeremy wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision: >> >> - Test fix >> - Test fix >> - Review comment address > > src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2323: > >> 2321: @Override >> 2322: public boolean equals(Object val) { >> 2323: return val instanceof CSS.FontFamily font && family == font.family; > > Is the `family` field interned somewhere? If it isn't, then should this be: > > > return val instanceof CSS.FontFamily font && > Objects.equals(family, font.family); > > > For ex if we tweak the start of the FontFamily unit test as follows does it still pass? > > private static void testFontFamily() { > StyleSheet ss = new StyleSheet(); > > SimpleAttributeSet a = new SimpleAttributeSet(); > ss.addCSSAttribute( a, CSS.Attribute.FONT_FAMILY, "Sans-Serif"); > > SimpleAttributeSet b = new SimpleAttributeSet(); > ss.addCSSAttribute( b, CSS.Attribute.FONT_FAMILY, "Sans-Serif"); I'm pretty sure the test will still pass because Java compiler interns strings. You have to explicitly create a new instance of the String to make the test fail. In real applications, attributes are parsed from a style sheet and therefore the identity test won't pass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1182886410 From aivanov at openjdk.org Tue May 2 18:20:24 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 2 May 2023 18:20:24 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v2] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 11:13:00 GMT, Prasanta Sadhukhan wrote: >> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. >> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. >> Fixed by implementing the equality and hashCode method for CSS.FontSize class. >> >> All jtreg/jck tests are ok > > Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision: > > - Test fix > - Test fix > - Review comment address Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2026: > 2024: return (svalue.contains("sup")); > 2025: } > 2026: Shall it be reverted? src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2319: > 2317: } else { > 2318: return 0; > 2319: } Suggestion: return (family != null) ? family.hashCode() : 0; The conditional operator is perfect here, don't you think? src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2321: > 2319: } > 2320: } > 2321: @Override Let's add a blank line between methods. Suggestion: @Override test/jdk/javax/swing/text/html/CSS/CSSAttributeEqualityBug.java line 44: > 42: > 43: private static void testFontSize() { > 44: StyleSheet ss = new StyleSheet(); The `StyleSheet` object isn't used in any of the tests, you can safely remove it. test/jdk/javax/swing/text/html/CSS/CSSAttributeEqualityBug.java line 54: > 52: > 53: if (a.isEqual(b)) { > 54: System.out.println( "a equals b"); Suggestion: ss.addCSSAttribute(a, CSS.Attribute.FONT_SIZE, fontSize); SimpleAttributeSet b = new SimpleAttributeSet(); ss.addCSSAttribute(b, CSS.Attribute.FONT_SIZE, fontSize); if (a.isEqual(b)) { System.out.println("a equals b"); There should be no space after opening parentheses. ------------- PR Review: https://git.openjdk.org/jdk/pull/13405#pullrequestreview-1409632838 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1182886952 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1182889142 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1182888179 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1182891734 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1182890669 From achung at openjdk.org Tue May 2 18:20:40 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 2 May 2023 18:20:40 GMT Subject: RFR: 8307299: Move more DnD tests to open Message-ID: Added DnD tests ------------- Commit messages: - added DnD tests Changes: https://git.openjdk.org/jdk/pull/13759/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13759&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307299 Stats: 1776 lines in 6 files changed: 1776 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13759.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13759/head:pull/13759 PR: https://git.openjdk.org/jdk/pull/13759 From honkar at openjdk.org Tue May 2 18:37:20 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 2 May 2023 18:37:20 GMT Subject: RFR: JDK-8305815: Update Libpng to 1.6.39 In-Reply-To: References: Message-ID: <6n8adhb8kq5HpYU8JH4uZ-hVcQirwr2ofPH3oKXMSEU=.cac5091e-fb8b-4095-90c1-bc80d11d7690@github.com> On Tue, 2 May 2023 17:43:46 GMT, Harshitha Onkar wrote: > Updated libpng to v1.6.39 @prrace Please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/13755#issuecomment-1531958620 From prr at openjdk.org Tue May 2 18:52:15 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 2 May 2023 18:52:15 GMT Subject: RFR: 8307297: Move some DnD tests to open In-Reply-To: References: Message-ID: On Tue, 2 May 2023 17:49:39 GMT, Alisen Chung wrote: > Adding some DnD tests Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13756#pullrequestreview-1409699894 From prr at openjdk.org Tue May 2 18:58:20 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 2 May 2023 18:58:20 GMT Subject: RFR: 8307299: Move more DnD tests to open In-Reply-To: References: Message-ID: On Tue, 2 May 2023 18:12:38 GMT, Alisen Chung wrote: > Added DnD tests Marked as reviewed by prr (Reviewer). test/jdk/java/awt/dnd/DropTargetingTest.java line 25: > 23: > 24: import javax.swing.JButton; > 25: import javax.swing.JFrame; This isn't important and I noticed the same on the other PR I just looked at, but generally we'd list javax.* APIs after the java.* APIs But it isn't 100% alphabetical as I'd put all the "java.base" APIs first ... not relevant here tho' ------------- PR Review: https://git.openjdk.org/jdk/pull/13759#pullrequestreview-1409708013 PR Review Comment: https://git.openjdk.org/jdk/pull/13759#discussion_r1182932768 From aivanov at openjdk.org Tue May 2 19:00:34 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 2 May 2023 19:00:34 GMT Subject: RFR: 6176679: Application freezes when copying an animated gif image to the system clipboard [v11] In-Reply-To: References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> Message-ID: <-QBkaWAlW5XX210JAoaRFGZEQCmGOkTed_8OSGcCGU8=.49928e23-50a4-4883-82f0-46fe13dc8892@github.com> On Sun, 30 Apr 2023 21:34:53 GMT, Rajat Mahajan wrote: >> **Problem:** >> >> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time. >> Due to this infinite wait the application freezes. >> >> **Proposed Fix:** >> >> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. >> After this change I see the GIF image being correctly copied and animated. >> >> >> **Testing:** >> >> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5. > > Rajat Mahajan has updated the pull request incrementally with three additional commits since the last revision: > > - Update ImageRepresentation.java > > code cleanup > - Update ImageRepresentation.java > > code cleanup > - update fix to work for both cases where image is displayed and not displayed Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/sun/awt/image/ImageRepresentation.java line 1: > 1: /* Could you remove the unused imports, please? src/java.desktop/share/classes/sun/awt/image/ImageRepresentation.java line 119: > 117: while ((availinfo & > 118: (ImageObserver.ERROR | ImageObserver.FRAMEBITS)) == 0 && > 119: missinginfo != 0) In my opinion, such formatting looks confusing, keeping both ERROR and FRAMEBITS on the same line improves readability even though it doesn't fit 80-column limit. Suggestion: while ((availinfo & (ImageObserver.ERROR | ImageObserver.FRAMEBITS)) == 0 && missinginfo != 0) Or alternatively, wrap `FRAMEBITS`: Suggestion: while ((availinfo & (ImageObserver.ERROR | ImageObserver.FRAMEBITS)) == 0 && missinginfo != 0) test/jdk/java/awt/Clipboard/CopyAnimatedGIFTest.java line 54: > 52: public class CopyAnimatedGIFTest { > 53: private static final long TIMEOUT = 10000; > 54: private static final CountDownLatch latch = new CountDownLatch(1); You use the latch twice but initialise only once ? the second test will never fail. You have to create it each time. test/jdk/java/awt/Clipboard/CopyAnimatedGIFTest.java line 90: > 88: > 89: private void createGUI() { > 90: img = Toolkit.getDefaultToolkit().createImage(imageData); `getImage` to avoid code duplication? test/jdk/java/awt/Clipboard/CopyAnimatedGIFTest.java line 106: > 104: } > 105: > 106: private void runTest(boolean isImageDisplayed) throws AWTException, InterruptedException, InvocationTargetException { The line is too long. Suggestion: private void runTest(boolean isImageDisplayed) throws Exception { We don't really care which exceptions the test method throws. test/jdk/java/awt/Clipboard/CopyAnimatedGIFTest.java line 112: > 110: EventQueue.invokeAndWait(test::createGUI); > 111: } > 112: else { Suggestion: } else { In Java code style, you keep both the closing brace, the `else` keyword and the opening brace on the same line. test/jdk/java/awt/Clipboard/CopyAnimatedGIFTest.java line 142: > 140: private static class ImageCanvas extends Canvas { > 141: private final Image img; > 142: public ImageCanvas(Image img) { Suggestion: private final Image img; public ImageCanvas(Image img) { ------------- PR Review: https://git.openjdk.org/jdk/pull/13414#pullrequestreview-1409684703 PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1182918324 PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1182915886 PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1182929831 PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1182925024 PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1182926710 PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1182928209 PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1182936107 From rmahajan at openjdk.org Tue May 2 19:45:10 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Tue, 2 May 2023 19:45:10 GMT Subject: RFR: 6176679: Application freezes when copying an animated gif image to the system clipboard [v12] In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> Message-ID: > **Problem:** > > On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time. > Due to this infinite wait the application freezes. > > **Proposed Fix:** > > There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. > After this change I see the GIF image being correctly copied and animated. > > > **Testing:** > > Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: Update src/java.desktop/share/classes/sun/awt/image/ImageRepresentation.java Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13414/files - new: https://git.openjdk.org/jdk/pull/13414/files/74c5c675..c790beb6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=10-11 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13414/head:pull/13414 PR: https://git.openjdk.org/jdk/pull/13414 From rmahajan at openjdk.org Tue May 2 19:45:14 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Tue, 2 May 2023 19:45:14 GMT Subject: RFR: 6176679: Application freezes when copying an animated gif image to the system clipboard [v11] In-Reply-To: <-QBkaWAlW5XX210JAoaRFGZEQCmGOkTed_8OSGcCGU8=.49928e23-50a4-4883-82f0-46fe13dc8892@github.com> References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> <-QBkaWAlW5XX210JAoaRFGZEQCmGOkTed_8OSGcCGU8=.49928e23-50a4-4883-82f0-46fe13dc8892@github.com> Message-ID: On Tue, 2 May 2023 18:40:02 GMT, Alexey Ivanov wrote: >> Rajat Mahajan has updated the pull request incrementally with three additional commits since the last revision: >> >> - Update ImageRepresentation.java >> >> code cleanup >> - Update ImageRepresentation.java >> >> code cleanup >> - update fix to work for both cases where image is displayed and not displayed > > src/java.desktop/share/classes/sun/awt/image/ImageRepresentation.java line 119: > >> 117: while ((availinfo & >> 118: (ImageObserver.ERROR | ImageObserver.FRAMEBITS)) == 0 && >> 119: missinginfo != 0) > > In my opinion, such formatting looks confusing, keeping both ERROR and FRAMEBITS on the same line improves readability even though it doesn't fit 80-column limit. > Suggestion: > > while ((availinfo & (ImageObserver.ERROR | ImageObserver.FRAMEBITS)) == 0 > && missinginfo != 0) > > > Or alternatively, wrap `FRAMEBITS`: > Suggestion: > > while ((availinfo & (ImageObserver.ERROR > | ImageObserver.FRAMEBITS)) == 0 > && missinginfo != 0) I agree the single line is one is more readable, was just following the 80 column limit you told me before :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1182977651 From serb at openjdk.org Tue May 2 19:46:19 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 May 2023 19:46:19 GMT Subject: RFR: 8307299: Move more DnD tests to open In-Reply-To: References: Message-ID: On Tue, 2 May 2023 18:12:38 GMT, Alisen Chung wrote: > Added DnD tests test/jdk/java/awt/dnd/IntraJVMGetDropSuccessTest.java line 275: > 273: } > 274: > 275: Component c = clickedComponent; this field is used on EDT and the main thread, some synchronisation is needed. test/jdk/java/awt/dnd/LinkAcceptanceTest.java line 94: > 92: } finally { > 93: EventQueue.invokeAndWait(() -> { > 94: if(test.frame != null) { missed space after "if" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13759#discussion_r1182979464 PR Review Comment: https://git.openjdk.org/jdk/pull/13759#discussion_r1182980550 From serb at openjdk.org Tue May 2 19:51:17 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 May 2023 19:51:17 GMT Subject: RFR: 8307297: Move some DnD tests to open In-Reply-To: References: Message-ID: On Tue, 2 May 2023 17:49:39 GMT, Alisen Chung wrote: > Adding some DnD tests test/jdk/java/awt/dnd/DragTriggerEventTest.java line 101: > 99: try { > 100: Point srcPoint = list.getLocationOnScreen(); > 101: Rectangle cellBounds = list.getCellBounds(0, 0); the list is a Swing component that should be accessed on EDT. test/jdk/java/awt/dnd/DropActionChangedTest.java line 79: > 77: } finally { > 78: EventQueue.invokeAndWait(() -> { > 79: if(test.frame != null) { missed space after "if" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13756#discussion_r1182981771 PR Review Comment: https://git.openjdk.org/jdk/pull/13756#discussion_r1182983382 From serb at openjdk.org Tue May 2 19:53:18 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 May 2023 19:53:18 GMT Subject: RFR: JDK-8305815: Update Libpng to 1.6.39 In-Reply-To: References: Message-ID: On Tue, 2 May 2023 17:43:46 GMT, Harshitha Onkar wrote: > Updated libpng to v1.6.39 Please add a note about what testing was done for this patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13755#issuecomment-1532057823 From serb at openjdk.org Tue May 2 19:57:19 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 May 2023 19:57:19 GMT Subject: RFR: 8306943: Open source several dnd AWT tests In-Reply-To: References: Message-ID: <216U1p9HeqRZBB9P9pmWRzJKvsTKLIpIzBXmIQdpuyk=.3ee5df42-d804-43ae-9aca-a73b97e250a1@github.com> On Tue, 2 May 2023 11:01:22 GMT, Alexander Zvegintsev wrote: > Open sourcing few more tests: > > java/awt/dnd/DnDAWTLockTest/DnDAWTLockTest.java > java/awt/dnd/DragGestureInvokeLaterTest/DragGestureInvokeLaterTest.java > java/awt/dnd/DragOverDropTargetPerformanceTest/DragOverDropTargetPerformanceTest.java > java/awt/dnd/DragSourceDragEventModifiersTest/DragSourceDragEventModifiersTest.java > java/awt/dnd/DragSourceGCrashTest/DragSourceGCrashTest.java > > > Testing looks good. test/jdk/java/awt/dnd/DnDAWTLockTest.java line 150: > 148: public void run() { > 149: try { > 150: if (process == null) { do we need to add a sync for process and sourcePoint? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13752#discussion_r1182991175 From serb at openjdk.org Tue May 2 20:04:18 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 May 2023 20:04:18 GMT Subject: RFR: 8306489: Open source AWT List related tests In-Reply-To: References: Message-ID: On Tue, 2 May 2023 06:26:36 GMT, Abhishek Kumar wrote: > This PR is to open source List related AWT tests. test/jdk/java/awt/List/ISCAfterRemoveAllTest.java line 140: > 138: System.out.println(ie); > 139: // We shouldn't generate any events since the list is empty > 140: passed = false; you set this flag on EDT and then read on the main thread, some sync is needed. test/jdk/java/awt/List/ListEnterExitTest.java line 105: > 103: > 104: public void mouseEntered(MouseEvent e) { > 105: passed = true; Can we check enter and exit events separately by different flags? The access to "passed" should use some synchronisation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13748#discussion_r1182993106 PR Review Comment: https://git.openjdk.org/jdk/pull/13748#discussion_r1182995680 From honkar at openjdk.org Tue May 2 20:05:17 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 2 May 2023 20:05:17 GMT Subject: RFR: JDK-8305815: Update Libpng to 1.6.39 In-Reply-To: References: Message-ID: On Tue, 2 May 2023 19:50:12 GMT, Sergey Bylokhov wrote: > Please add a note about what testing was done for this patch. @mrserb Updated the PR description with testing info. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13755#issuecomment-1532072587 From serb at openjdk.org Tue May 2 20:06:19 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 May 2023 20:06:19 GMT Subject: RFR: 8307133: Open source some JTable jtreg tests In-Reply-To: References: Message-ID: On Mon, 1 May 2023 21:11:14 GMT, Phil Race wrote: > Open source some Swing JTable tests test/jdk/javax/swing/JTable/bug4159300.java line 87: > 85: frame.pack(); > 86: frame.setVisible(true); > 87: } finally { Why do we need this empty "finally" block? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13745#discussion_r1182998536 From achung at openjdk.org Tue May 2 20:20:28 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 2 May 2023 20:20:28 GMT Subject: RFR: 8307299: Move more DnD tests to open In-Reply-To: References: Message-ID: On Tue, 2 May 2023 19:42:44 GMT, Sergey Bylokhov wrote: >> Added DnD tests > > test/jdk/java/awt/dnd/IntraJVMGetDropSuccessTest.java line 275: > >> 273: } >> 274: >> 275: Component c = clickedComponent; > > this field is used on EDT and the main thread, some synchronisation is needed. Should I put that field on the EDT as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13759#discussion_r1183010708 From achung at openjdk.org Tue May 2 20:49:27 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 2 May 2023 20:49:27 GMT Subject: RFR: 8307299: Move more DnD tests to open [v2] In-Reply-To: References: Message-ID: > Added DnD tests Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: fix if spacing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13759/files - new: https://git.openjdk.org/jdk/pull/13759/files/ac214c9f..85714681 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13759&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13759&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13759.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13759/head:pull/13759 PR: https://git.openjdk.org/jdk/pull/13759 From dnguyen at openjdk.org Tue May 2 20:53:28 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 2 May 2023 20:53:28 GMT Subject: RFR: 8307165: java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java timed out Message-ID: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> When converting this test to be applicable to be open sourced, changes were made. I reverted some of these changes to get the test stable again. Now it passes when run on various OS's 100x. ------------- Commit messages: - Revert some test conversion changes - Modify waitForIdle - Merge branch 'master' of github.com:DamonGuy/jdk - Fix rebase issue Changes: https://git.openjdk.org/jdk/pull/13761/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13761&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307165 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13761.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13761/head:pull/13761 PR: https://git.openjdk.org/jdk/pull/13761 From achung at openjdk.org Tue May 2 20:57:28 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 2 May 2023 20:57:28 GMT Subject: RFR: 8307297: Move some DnD tests to open [v2] In-Reply-To: References: Message-ID: > Adding some DnD tests Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: added space after if, moved some function calls on EDT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13756/files - new: https://git.openjdk.org/jdk/pull/13756/files/7b6e1703..c2451e28 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13756&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13756&range=00-01 Stats: 14 lines in 2 files changed: 9 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13756/head:pull/13756 PR: https://git.openjdk.org/jdk/pull/13756 From achung at openjdk.org Tue May 2 21:07:21 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 2 May 2023 21:07:21 GMT Subject: RFR: 8307299: Move more DnD tests to open [v3] In-Reply-To: References: Message-ID: > Added DnD tests Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: moved some function calls on EDT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13759/files - new: https://git.openjdk.org/jdk/pull/13759/files/85714681..09ceaf0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13759&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13759&range=01-02 Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13759.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13759/head:pull/13759 PR: https://git.openjdk.org/jdk/pull/13759 From achung at openjdk.org Tue May 2 22:00:21 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 2 May 2023 22:00:21 GMT Subject: RFR: JDK-8307083: Open source some drag and drop tests 3 Message-ID: moving tests to open ------------- Commit messages: - added tests to open Changes: https://git.openjdk.org/jdk/pull/13764/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13764&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307083 Stats: 895 lines in 4 files changed: 895 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13764/head:pull/13764 PR: https://git.openjdk.org/jdk/pull/13764 From achung at openjdk.org Tue May 2 22:16:27 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 2 May 2023 22:16:27 GMT Subject: RFR: JDK-8307128: Open source some drag and drop tests 4 Message-ID: added DnD tests ------------- Commit messages: - added dnd tests Changes: https://git.openjdk.org/jdk/pull/13765/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13765&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307128 Stats: 1678 lines in 5 files changed: 1678 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13765.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13765/head:pull/13765 PR: https://git.openjdk.org/jdk/pull/13765 From prr at openjdk.org Tue May 2 23:19:18 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 2 May 2023 23:19:18 GMT Subject: RFR: JDK-8282232: [Win] GetMousePositionWithPopup test fails due to wrong mouse position [v2] In-Reply-To: References: Message-ID: <3K05c5DrsWj_ArohKIkylhaLqVGEYsnz9bliw6WWEhU=.306f1bbf-a08a-4609-80dd-6b3177eb3b2b@github.com> On Fri, 7 Apr 2023 17:57:41 GMT, Harshitha Onkar wrote: >> This test issue was due to race condition that occured when using `-Dsun.java2d.uiScale >= 2`. >> As a result it led to incorrect mouse position being compared as opposed to the updated mouse position after the final mouse move event. >> >> Following is the event log before and after fix. >> >> **Before fix:** >> >> 1st mouse move >> 2nd mouse move >> Frame-1 Mouse Event >> Frame-2 Mouse Event >> java.awt.Point[x=29,y=29] >> >> >> **After fix:** >> >> 1st mouse move >> 2nd mouse move >> Frame-1 Mouse Event >> 3rd mouse move >> Frame-2 Mouse Event >> java.awt.Point[x=50,y=50] >> >> >> Earlier Frame-2's mouseMoved() was being triggered on Robot's 2nd mouse move instead of 3rd mouse move. To fix it, the mouseMotionListener for Frame-2 is now added after Robot's 2nd mouse move is processed to avoid the race condition. >> >> The updated test fix is checked on multiple uiScales including fractional scales for windows platform. >> CI testing works as expected on all platforms. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > added syncLocationToWindowManager(), changed literals to vars Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13380#pullrequestreview-1410000713 From honkar at openjdk.org Tue May 2 23:25:25 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 2 May 2023 23:25:25 GMT Subject: Integrated: JDK-8282232: [Win] GetMousePositionWithPopup test fails due to wrong mouse position In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 23:50:26 GMT, Harshitha Onkar wrote: > This test issue was due to race condition that occured when using `-Dsun.java2d.uiScale >= 2`. > As a result it led to incorrect mouse position being compared as opposed to the updated mouse position after the final mouse move event. > > Following is the event log before and after fix. > > **Before fix:** > > 1st mouse move > 2nd mouse move > Frame-1 Mouse Event > Frame-2 Mouse Event > java.awt.Point[x=29,y=29] > > > **After fix:** > > 1st mouse move > 2nd mouse move > Frame-1 Mouse Event > 3rd mouse move > Frame-2 Mouse Event > java.awt.Point[x=50,y=50] > > > Earlier Frame-2's mouseMoved() was being triggered on Robot's 2nd mouse move instead of 3rd mouse move. To fix it, the mouseMotionListener for Frame-2 is now added after Robot's 2nd mouse move is processed to avoid the race condition. > > The updated test fix is checked on multiple uiScales including fractional scales for windows platform. > CI testing works as expected on all platforms. This pull request has now been integrated. Changeset: 76991c81 Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/76991c8129a6599a3dfaa0cfdc77a23014a02b35 Stats: 117 lines in 1 file changed: 66 ins; 28 del; 23 mod 8282232: [Win] GetMousePositionWithPopup test fails due to wrong mouse position Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13380 From dnguyen at openjdk.org Tue May 2 23:49:28 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 2 May 2023 23:49:28 GMT Subject: Integrated: 8306466: Open source more AWT Drag & Drop related tests In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 18:08:53 GMT, Damon Nguyen wrote: > This PR open sources a few more AWT DnD related tests This pull request has now been integrated. Changeset: 418a8255 Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/418a82551a2c58e43963beb5aa242a58bbd30e2f Stats: 848 lines in 8 files changed: 848 ins; 0 del; 0 mod 8306466: Open source more AWT Drag & Drop related tests Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13653 From jiangli at openjdk.org Wed May 3 02:16:08 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 02:16:08 GMT Subject: RFR: 8307194: Enhance static-libs-image Message-ID: This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; - For libjvm.a specifically, exclude operator_new.o; - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; - Handle long arguments case for static build in make/common/NativeCompilation.gmk; - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; ------------- Commit messages: - Remove unused $$($1_EXTRA_ARGS) from DeclareHotspotLibsRecipe. - 8307194: Enhance static-libs-image Changes: https://git.openjdk.org/jdk/pull/13768/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307194 Stats: 146 lines in 6 files changed: 100 ins; 34 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Wed May 3 02:18:17 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 02:18:17 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image [v2] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 19:32:40 GMT, Erik Joelsson wrote: > This is the same list as the LIBJLI_EXTRA_FILES above. Would be good to avoid the duplication. @erikj79 Addressed in the extracted https://github.com/openjdk/jdk/pull/13768, which contains .a related changes only (without linking 'javastatic' part), thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1183188806 From jiangli at openjdk.org Wed May 3 03:03:21 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 03:03:21 GMT Subject: RFR: 8303796: Optionally build fully statically linked JDK image [v2] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 19:34:40 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Use $(JVM_LIBS), which includes -lrt on Linux currently. > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 228: > >> 226: # static libraries cause linking errors due to duplicate symbols. >> 227: LIBAWT_XAWT_STATIC_EXCLUDE_OBJS := \ >> 228: debug_assert.o debug_util.o debug_trace.o debug_mem.o systemScale.o > > Can this list be derived dynamically in some way? If they are all in the same directory, maybe we could base it on that instead of having to maintain an explicit list? With additional testing, I found 'debug_assert.o debug_util.o debug_trace.o debug_mem.o' are no longer included when building libawt_xawt, using JDK head code base. We no longer need to be filtered out those for libawt_xawt.a. They were needed for JDK 11. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1183201634 From duke at openjdk.org Wed May 3 03:33:15 2023 From: duke at openjdk.org (Ravi Gupta) Date: Wed, 3 May 2023 03:33:15 GMT Subject: RFR: 8305427: Write a test Check whether focus changes as expected when requestFocus is used to traverse randomly around the window [v4] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 13:01:31 GMT, Ravi Gupta wrote: >> This testcase Checking whether the Component becoming the Focus Owner and FocusEvent.FOCUS_GAINED will be received by the Component when the focus is requested on the component using requestFocus. >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8305427: CountDownLatch used Any volunteers for a review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13293#issuecomment-1532417914 From rmahajan at openjdk.org Wed May 3 03:36:25 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Wed, 3 May 2023 03:36:25 GMT Subject: RFR: 6176679: Application freezes when copying an animated gif image to the system clipboard [v13] In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> Message-ID: > **Problem:** > > On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time. > Due to this infinite wait the application freezes. > > **Proposed Fix:** > > There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. > After this change I see the GIF image being correctly copied and animated. > > > **Testing:** > > Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: make code changes suggested by reviewers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13414/files - new: https://git.openjdk.org/jdk/pull/13414/files/c790beb6..c78d77cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=11-12 Stats: 35 lines in 2 files changed: 4 ins; 20 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13414/head:pull/13414 PR: https://git.openjdk.org/jdk/pull/13414 From psadhukhan at openjdk.org Wed May 3 03:48:20 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 3 May 2023 03:48:20 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v3] In-Reply-To: References: Message-ID: > Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. > In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. > Fixed by implementing the equality and hashCode method for CSS.FontSize class. > > All jtreg/jck tests are ok Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Review update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13405/files - new: https://git.openjdk.org/jdk/pull/13405/files/e24c1405..d30156f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=01-02 Stats: 14 lines in 2 files changed: 2 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13405/head:pull/13405 PR: https://git.openjdk.org/jdk/pull/13405 From psadhukhan at openjdk.org Wed May 3 03:48:22 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 3 May 2023 03:48:22 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v2] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 18:16:34 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision: >> >> - Test fix >> - Test fix >> - Review comment address > > test/jdk/javax/swing/text/html/CSS/CSSAttributeEqualityBug.java line 44: > >> 42: >> 43: private static void testFontSize() { >> 44: StyleSheet ss = new StyleSheet(); > > The `StyleSheet` object isn't used in any of the tests, you can safely remove it. it is being used `ss.addCSSAttribute(a, CSS.Attribute.FONT_SIZE, fontSize);` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1183214010 From tr at openjdk.org Wed May 3 04:37:31 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 3 May 2023 04:37:31 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v4] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 12:13:57 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 47: > >> 45: public ScrollPane scrollpane; >> 46: public Frame frame; >> 47: public int count = 0; > > Suggestion: > > public volatile int count = 0; > > `count` is accessed from two threads, it should be `volatile` or you should use `AtomicInteger` instead. Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 53: > >> 51: public static boolean mouseWasPressed = false; >> 52: public static Component child = null; >> 53: private Object lock = new Object(); > > Suggestion: > > private final Object lock = new Object(); Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 83: > >> 81: if (e.getID() == MouseEvent.MOUSE_PRESSED) { >> 82: if (e.getSource() == ScrollPaneLimitation.child >> 83: && e.getY() > SCROLL_POS) { > > The two `if` blocks could be merged together into one. Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 145: > >> 143: throw new RuntimeException("test was interrupted"); >> 144: } >> 145: } > > A `CountDownLatch` would be better rather than plain `lock`. Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 138: > >> 136: waiting--; >> 137: } >> 138: } > > This method is never used, it can safely be dropped. Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 77: > >> 75: hScroll = (ScrollPaneAdjustable) sp.getHAdjustable(); >> 76: vScroll.addAdjustmentListener(this); >> 77: hScroll.addAdjustmentListener(this); > > `vScroll` and `hScroll` should also go into `invokeAndWait` above. Updated. > test/jdk/java/awt/ScrollPane/ScrollPositionIntact.java line 85: > >> 83: >> 84: int i; >> 85: i = (int) (sp.getScrollPosition().getX()); > > Suggestion: > > int i = (int) (sp.getScrollPosition().getX()); Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1183230264 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1183229539 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1183230178 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1183230201 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1183229514 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1183229628 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1183229572 From tr at openjdk.org Wed May 3 04:37:32 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 3 May 2023 04:37:32 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v4] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 10:50:00 GMT, Andrey Turbanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 106: > >> 104: sp.getLocationOnScreen().y + sp.getHeight() - paneInsets.bottom / 2); >> 105: testOneScrollbar(hScroll); >> 106: } finally{ > > Suggestion: > > } finally { Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1183230299 From abhiscxk at openjdk.org Wed May 3 07:01:28 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 3 May 2023 07:01:28 GMT Subject: RFR: 8306489: Open source AWT List related tests [v2] In-Reply-To: References: Message-ID: > This PR is to open source List related AWT tests. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Review comment update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13748/files - new: https://git.openjdk.org/jdk/pull/13748/files/d47ef223..28e36f0e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13748&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13748&range=00-01 Stats: 17 lines in 3 files changed: 5 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/13748.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13748/head:pull/13748 PR: https://git.openjdk.org/jdk/pull/13748 From abhiscxk at openjdk.org Wed May 3 07:01:31 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 3 May 2023 07:01:31 GMT Subject: RFR: 8306489: Open source AWT List related tests [v2] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 19:57:03 GMT, Sergey Bylokhov wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment update > > test/jdk/java/awt/List/ISCAfterRemoveAllTest.java line 140: > >> 138: System.out.println(ie); >> 139: // We shouldn't generate any events since the list is empty >> 140: passed = false; > > you set this flag on EDT and then read on the main thread, some sync is needed. Updated. > test/jdk/java/awt/List/ListEnterExitTest.java line 105: > >> 103: >> 104: public void mouseEntered(MouseEvent e) { >> 105: passed = true; > > Can we check enter and exit events separately by different flags? The access to "passed" should use some synchronisation. Added separate flags to test enter and exit events. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13748#discussion_r1183301492 PR Review Comment: https://git.openjdk.org/jdk/pull/13748#discussion_r1183301860 From psadhukhan at openjdk.org Wed May 3 11:00:36 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 3 May 2023 11:00:36 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v4] In-Reply-To: References: Message-ID: > Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. > In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. > Fixed by implementing the equality and hashCode method for CSS.FontSize class. > > All jtreg/jck tests are ok Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: More Attrbutes added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13405/files - new: https://git.openjdk.org/jdk/pull/13405/files/d30156f6..2bc265cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=02-03 Stats: 156 lines in 2 files changed: 151 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13405/head:pull/13405 PR: https://git.openjdk.org/jdk/pull/13405 From duke at openjdk.org Wed May 3 13:15:14 2023 From: duke at openjdk.org (Nikita Provotorov) Date: Wed, 3 May 2023 13:15:14 GMT Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical methods in its C API In-Reply-To: <6CIO56TQgxgXbhgY7ae6etk1PsfrI2RrnABvrm5WTi8=.3f4d13c5-89b8-45e9-8a53-fefc3a76a0b1@github.com> References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> <6CIO56TQgxgXbhgY7ae6etk1PsfrI2RrnABvrm5WTi8=.3f4d13c5-89b8-45e9-8a53-fefc3a76a0b1@github.com> Message-ID: On Tue, 2 May 2023 16:52:04 GMT, Phil Race wrote: > These don't seem to be part of the public API, so this is probably deliberate and not a bug. > https://docs.oracle.com/javase/accessbridge/2.0.2/api.htm#jab-api-specification @prrace should non-public API methods be removed from .DEF then? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1533009910 From jwaters at openjdk.org Wed May 3 13:23:15 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 3 May 2023 13:23:15 GMT Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical methods in its C API In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> Message-ID: On Sat, 29 Apr 2023 19:26:00 GMT, Julian Waters wrote: > In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge: > > addJavaEventNotification > removeJavaEventNotification > addAccessibilityEventNotification > removeAccessibilityEventNotification > > > However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future I should think so, it doesn't make sense to export a function that doesn't even exist at all. And to make matters worse Microsoft Visual C still does export functions with those names (you can easily verify this with dumpbin) which is even more confusing. It may be a cursed Microsoft extension that has simply gone under the radar, and is somehow exporting the C++ class instance methods as static, or even exporting dummy functions, neither of which is what we want it to do! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1533020156 From erikj at openjdk.org Wed May 3 13:37:15 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 May 2023 13:37:15 GMT Subject: RFR: 8307194: Enhance static-libs-image In-Reply-To: References: Message-ID: <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com> On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; The current target user of the .a libraries is GraalVM, so we should check with them that the changes to the contents of the `.a` files isn't impacting them in a bad way. @dougxc what do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1533040157 From erikj at openjdk.org Wed May 3 13:46:17 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 May 2023 13:46:17 GMT Subject: RFR: 8307194: Enhance static-libs-image In-Reply-To: References: Message-ID: On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; make/StaticLibsImage.gmk line 61: > 59: $(eval TARGETS += $$(COPY_STATIC_LIBS_libjvm)) \ > 60: ) > 61: Won't this fail if we were building more than one variant? Perhaps only put `$(JVM_VARIANT_MAIN)` in the static image to avoid problems? make/modules/java.base/lib/CoreLibraries.gmk line 168: > 166: # The duplicate objects in different static libraries cause linking > 167: # errors due to duplicate symbols. > 168: LIBJLI_STATIC_EXCLUDE_OBJS := $(subst .c,.o,$(LIBJLI_EXTRA_FILE_LIST)) Should probably use `$(OBJ_SUFFIX)` instead of `.o`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1183706646 PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1183702610 From dnsimon at openjdk.org Wed May 3 14:01:22 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 3 May 2023 14:01:22 GMT Subject: RFR: 8307194: Enhance static-libs-image In-Reply-To: <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com> References: <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com> Message-ID: On Wed, 3 May 2023 13:34:12 GMT, Erik Joelsson wrote: > The current target user of the .a libraries is GraalVM, so we should check with them that the changes to the contents of the `.a` files isn't impacting them in a bad way. @dougxc what do you think? Thanks for the heads up - I've asked the GraalVM Native Image team to look at this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1533078913 From tr at openjdk.org Wed May 3 16:00:39 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 3 May 2023 16:00:39 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v6] In-Reply-To: References: Message-ID: > Open source few AWT ScrollPane related tests. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Removed whitespace error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13621/files - new: https://git.openjdk.org/jdk/pull/13621/files/d9bfe956..922bb902 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621 PR: https://git.openjdk.org/jdk/pull/13621 From dnguyen at openjdk.org Wed May 3 16:05:39 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 3 May 2023 16:05:39 GMT Subject: RFR: 8306871: Open source more AWT Drag & Drop tests [v2] In-Reply-To: References: Message-ID: > This PR open sources more AWT DnD & Event related tests Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Fix syntax. Edit comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13725/files - new: https://git.openjdk.org/jdk/pull/13725/files/9999d9cc..97383c7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13725&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13725&range=00-01 Stats: 6 lines in 3 files changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13725.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13725/head:pull/13725 PR: https://git.openjdk.org/jdk/pull/13725 From dnguyen at openjdk.org Wed May 3 16:05:46 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 3 May 2023 16:05:46 GMT Subject: RFR: 8306871: Open source more AWT Drag & Drop tests [v2] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 16:10:16 GMT, Andrey Turbanov wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix syntax. Edit comment > > test/jdk/java/awt/event/InputEvent/MouseModsTest.java line 145: > >> 143: >> 144: static int getKeycode(int ctrl) { >> 145: switch(ctrl) { > > Suggestion: > > switch (ctrl) { Fixed > test/jdk/java/awt/event/InputEvent/MouseModsTest.java line 154: > >> 152: >> 153: static int getKeyModifier(int ctrl) { >> 154: switch(ctrl) { > > Suggestion: > > switch (ctrl) { Fixed > test/jdk/java/awt/event/InputEvent/MouseModsTest.java line 163: > >> 161: >> 162: static int getMouseModifier(int btn) { >> 163: switch(btn) { > > Suggestion: > > switch (btn) { Fixed > test/jdk/java/awt/event/KeyEvent/AltGraphModifier.java line 83: > >> 81: if (modifierPress[i] == true) { >> 82: if ((kp.getModifiersEx() & inputMasks[i]) == inputMasks[i]) { >> 83: } else { > > Suggestion: > > } else { Fixed > test/jdk/java/awt/event/KeyEvent/KeyTyped/CancelKeyTyped.java line 114: > >> 112: >> 113: protected void printKey(KeyEvent evt) { >> 114: switch(evt.getID()) { > > Suggestion: > > switch (evt.getID()) { Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13725#discussion_r1183893293 PR Review Comment: https://git.openjdk.org/jdk/pull/13725#discussion_r1183893416 PR Review Comment: https://git.openjdk.org/jdk/pull/13725#discussion_r1183893511 PR Review Comment: https://git.openjdk.org/jdk/pull/13725#discussion_r1183893216 PR Review Comment: https://git.openjdk.org/jdk/pull/13725#discussion_r1183893133 From dnguyen at openjdk.org Wed May 3 16:05:47 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 3 May 2023 16:05:47 GMT Subject: RFR: 8306871: Open source more AWT Drag & Drop tests [v2] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 22:07:28 GMT, Phil Race wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix syntax. Edit comment > > test/jdk/java/awt/event/KeyEvent/AltGraphModifier.java line 28: > >> 26: @bug 4343344 >> 27: @summary Tests key modifiers when ALT_GRAPH key is pressed by Robot. >> 28: This test is for UNIX only. > > I think this comment is confusing and should be removed since > (1) the test is only being excluded on mac which is actually Unix > (2) it is being run on Windows which most definitely isn't Unix. Section about "UNIX ONLY" removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13725#discussion_r1183893937 From tr at openjdk.org Wed May 3 16:21:17 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 3 May 2023 16:21:17 GMT Subject: RFR: 8307091: Few test threw ConcurrentModificationException Intermittently Message-ID: Few test are throwing Concurrent Modification Exception Intermittently. Since the issue is intermittent and from the log and code review, It is found that the shared variable `fileCache` is used in comparison with the `newFileCache` where the comparison invokes the iterator method in AbstractList class. Since based on vector documentation it was evident that listIterator are fail-fast iterators and hence it would be better to make a separate local copy of vectors for comparing operations. The same is implemented and tested in CI system which shows green. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/13783/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13783&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307091 Stats: 18 lines in 1 file changed: 8 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13783.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13783/head:pull/13783 PR: https://git.openjdk.org/jdk/pull/13783 From sgehwolf at openjdk.org Wed May 3 17:00:26 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 3 May 2023 17:00:26 GMT Subject: RFR: 8307194: Enhance static-libs-image In-Reply-To: References: Message-ID: On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; @jianglizhou How does the produced image look like after this patch? I.e. what's the contents of `build/*/images/static-libs`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1533385050 From sgehwolf at openjdk.org Wed May 3 17:08:15 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 3 May 2023 17:08:15 GMT Subject: RFR: 8307194: Enhance static-libs-image In-Reply-To: References: Message-ID: On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; make/Main.gmk line 1060: > 1058: symbols-image: $(LIBS_TARGETS) $(LAUNCHER_TARGETS) > 1059: > 1060: static-libs-image: hotspot-static-libs $(STATIC_LIBS_TARGETS) Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1183974910 From prr at openjdk.org Wed May 3 17:30:16 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 17:30:16 GMT Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical methods in its C API In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> Message-ID: On Sat, 29 Apr 2023 19:26:00 GMT, Julian Waters wrote: > In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge: > > addJavaEventNotification > removeJavaEventNotification > addAccessibilityEventNotification > removeAccessibilityEventNotification > > > However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future So perhaps something internal in the various accessbridge dll's needs it. How will you test this ? Who here has JAWS ? If you don't have JAWS and therefore can't use it to verify the A11Y test suite then I don't think you can test this change in a way that makes me comfortable in doing anything here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1533432208 From prr at openjdk.org Wed May 3 17:38:37 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 17:38:37 GMT Subject: RFR: 8307133: Open source some JTable jtreg tests [v2] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 20:03:14 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8307133 > > test/jdk/javax/swing/JTable/bug4159300.java line 87: > >> 85: frame.pack(); >> 86: frame.setVisible(true); >> 87: } finally { > > Why do we need this empty "finally" block? We don't. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13745#discussion_r1184009963 From prr at openjdk.org Wed May 3 17:38:36 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 17:38:36 GMT Subject: RFR: 8307133: Open source some JTable jtreg tests [v2] In-Reply-To: References: Message-ID: > Open source some Swing JTable tests Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8307133 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13745/files - new: https://git.openjdk.org/jdk/pull/13745/files/19269e2f..44941b91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13745&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13745&range=00-01 Stats: 30 lines in 1 file changed: 0 ins; 3 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/13745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13745/head:pull/13745 PR: https://git.openjdk.org/jdk/pull/13745 From jiangli at openjdk.org Wed May 3 17:58:25 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 17:58:25 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: References: Message-ID: <0T3QYhW2lCL0cut65awn0zF2_xsBu57OhgeBfG13Mbk=.31927d2d-876b-4e8d-8ad1-8642ff0cfb3f@github.com> > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update based on @erikj79 review comments and suggestions: - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk. - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/f8be9e95..f74b576d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=00-01 Stats: 10 lines in 2 files changed: 0 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Wed May 3 17:58:27 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 17:58:27 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 13:42:03 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Update based on @erikj79 review comments and suggestions: >> - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk. >> - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk. > > make/StaticLibsImage.gmk line 61: > >> 59: $(eval TARGETS += $$(COPY_STATIC_LIBS_libjvm)) \ >> 60: ) >> 61: > > Won't this fail if we were building more than one variant? Perhaps only put `$(JVM_VARIANT_MAIN)` in the static image to avoid problems? Changed to copy for $(JVM_VARIANT_MAIN) only, as suggested. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184061602 From jiangli at openjdk.org Wed May 3 18:15:13 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 18:15:13 GMT Subject: RFR: 8307194: Enhance static-libs-image In-Reply-To: References: Message-ID: <2SPZE-0hNv2CIMD9vVZynRUmk-bw8QCquiDELC2QzDE=.e66960f0-f4ff-4740-99d6-44abe1d8071b@github.com> On Wed, 3 May 2023 16:57:04 GMT, Severin Gehwolf wrote: > @jianglizhou How does the produced image look like after this patch? I.e. what's the contents of `build/*/images/static-libs`? With the changes in this patch, `build/*/images/static-libs` will contain the `libjvm.a` in addition to the JDK `.a` static libraries. For the following JDK static libraries (`.a`), the duplicate `.o` files are excluded to avoid linking failures when the the JDK static libraries are linked with: - For `libjli.a`: Not include `inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o` (compiled from `zlib` sources) if `zlib` is built as JDK bundled. When `zlib` is built as bundled, the extra source files from it are compiled and the produced object files are linked into `libjli`. That's intended for the shared library, `libjli.so`, but that's problematic for `libjli.a`. It's not an issue when `zlib` is not bundled, as the extra sources are not included for `libjli` in that case. - For `libawt_xawt.a` and `libawt_head.a`: Not include `systemScale.o`, since it's provided in `libawt.a`. I'll add these details in the PR description as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1533494769 From erikj at openjdk.org Wed May 3 18:37:16 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 May 2023 18:37:16 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: <0T3QYhW2lCL0cut65awn0zF2_xsBu57OhgeBfG13Mbk=.31927d2d-876b-4e8d-8ad1-8642ff0cfb3f@github.com> References: <0T3QYhW2lCL0cut65awn0zF2_xsBu57OhgeBfG13Mbk=.31927d2d-876b-4e8d-8ad1-8642ff0cfb3f@github.com> Message-ID: On Wed, 3 May 2023 17:58:25 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: >> >> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; >> - For libjvm.a specifically, exclude operator_new.o; >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk; >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update based on @erikj79 review comments and suggestions: > - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk. > - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk. make/Main.gmk line 261: > 259: endef > 260: > 261: $(foreach v, $(JVM_VARIANTS), $(eval $(call DeclareHotspotStaticLibsRecipe,$v))) If we are only using the libjvm.a from the main variant, we don't need to generate top level rules for all variants, or we could at least limit the dependency declaration at line 1109 to only need the main variant. make/StaticLibsImage.gmk line 56: > 54: DEST := $(STATIC_LIBS_IMAGE_DIR)/lib, \ > 55: FILES := $(filter %$(STATIC_LIBRARY_SUFFIX), \ > 56: $(call FindFiles, $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/libjvm/objs/static)))) I would recommend using `wildcard` instead of `FindFiles` as the files are expected to be in a single directory (no recursive directory searching needed). We also try to put the closing double braces on a new line matching the initial eval in indentation. Suggestion: FILES := $(wildcard $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/libjvm/objs/static/*$(STATIC_LIBRARY_SUFFIX)), \ )) make/StaticLibsImage.gmk line 57: > 55: FILES := $(filter %$(STATIC_LIBRARY_SUFFIX), \ > 56: $(call FindFiles, $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/libjvm/objs/static)))) > 57: $(eval TARGETS += $$(COPY_STATIC_LIBS_libjvm)) No need for eval around this assignment. Suggestion: TARGETS += $(COPY_STATIC_LIBS_libjvm) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184105236 PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184103554 PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184099771 From erikj at openjdk.org Wed May 3 18:37:19 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 May 2023 18:37:19 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 17:05:29 GMT, Severin Gehwolf wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Update based on @erikj79 review comments and suggestions: >> - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk. >> - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk. > > make/Main.gmk line 1060: > >> 1058: symbols-image: $(LIBS_TARGETS) $(LAUNCHER_TARGETS) >> 1059: >> 1060: static-libs-image: hotspot-static-libs $(STATIC_LIBS_TARGETS) > > Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. > > Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? I'm hoping to get input from the graal team on the impact of this change. The exact usage of the new libjvm.a file is still under discussion so I share you concern about changing things for the current static libs usecase before we fully understand where this is going. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184107079 From jiangli at openjdk.org Wed May 3 18:43:16 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 18:43:16 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 18:33:56 GMT, Erik Joelsson wrote: >> make/Main.gmk line 1060: >> >>> 1058: symbols-image: $(LIBS_TARGETS) $(LAUNCHER_TARGETS) >>> 1059: >>> 1060: static-libs-image: hotspot-static-libs $(STATIC_LIBS_TARGETS) >> >> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. >> >> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? > > I'm hoping to get input from the graal team on the impact of this change. The exact usage of the new libjvm.a file is still under discussion so I share you concern about changing things for the current static libs usecase before we fully understand where this is going. > Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. > > Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? Good questions. I had similar thoughts when making the makefile changes. Here's my reasoning with the current approach in this PR: The `images/static-libs/lib` would provide a super set of the JDK/VM static libraries (in a JDK binary/release) for downstream developers to produce their desired final static image. With the addition of the `libjvm.a` and potentially bundled `libzlib.a` and `libfreetype.a` included in `static-libs-image` output, users could select the needed subset of the static libraries for their linking step (e.g. via jlink based on the needed modules) to produce the final image. If these changes are cumbersome for `graal-builder-image` usages, using `hotspot-static-libs` directly for producing `libjvm.a` as you suggested could be doable. Or, we could try using a new make target for producing the `.a` superset. There might be potential concerns/issues with the differences between `graal-builder-image` support and Java static image support, i.e. it might be a good idea to explore unified solution for both if possible. @dougxc and others related to GraalVM Native Image are on this review thread. It's a good idea to collect the thoughts together. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184113709 From sgehwolf at openjdk.org Wed May 3 18:54:15 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 3 May 2023 18:54:15 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 18:40:52 GMT, Jiangli Zhou wrote: >> I'm hoping to get input from the graal team on the impact of this change. The exact usage of the new libjvm.a file is still under discussion so I share you concern about changing things for the current static libs usecase before we fully understand where this is going. > >> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. >> >> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? > > Good questions. I had similar thoughts when making the makefile changes. Here's my reasoning with the current approach in this PR: > > The `images/static-libs/lib` would provide a super set of the JDK/VM static libraries (in a JDK binary/release) for downstream developers to produce their desired final static image. With the addition of the `libjvm.a` and potentially bundled `libzlib.a` and `libfreetype.a` included in `static-libs-image` output, users could select the needed subset of the static libraries for their linking step (e.g. via jlink based on the needed modules) to produce the final image. > > If these changes are cumbersome for `graal-builder-image` usages, using `hotspot-static-libs` directly for producing `libjvm.a` as you suggested could be doable. Or, we could try using a new make target for producing the `.a` superset. There might be potential concerns/issues with the differences between `graal-builder-image` support and Java static image support, i.e. it might be a good idea to explore unified solution for both if possible. @dougxc and others related to GraalVM Native Image are on this review thread. It's a good idea to collect the thoughts together. GraalVM native-image has it's own `libjvm.a` shim which would likely conflict or produce undesirable results. So I'd prefer the approach where `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For new uses-cases needing that, we could add a new top-level target (like `graal-builder-image`) which would produce such an image. As one of the [Mandrel](https://github.com/graalvm/mandrel) maintainers, I'm not sure any post-build filtering via `jlink` or the like would be ideal for us. I'll see if I can test this on a mandrel build tomorrow... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184123989 From jiangli at openjdk.org Wed May 3 19:11:28 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 19:11:28 GMT Subject: RFR: 8307194: Enhance static-libs-image [v3] In-Reply-To: References: Message-ID: <2F3flYLZ6fDkLmUEgEGjwbFpflTPWHCtBmgFowmXq2o=.c465f39d-d798-4266-8851-867155a64d30@github.com> > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update make/StaticLibsImage.gmk Thanks Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/f74b576d..1f62842e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Wed May 3 19:19:33 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 19:19:33 GMT Subject: RFR: 8307194: Enhance static-libs-image [v4] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update make/StaticLibsImage.gmk thanks Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/1f62842e..e65aee25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From prr at openjdk.org Wed May 3 19:32:15 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 19:32:15 GMT Subject: RFR: JDK-8305815: Update Libpng to 1.6.39 In-Reply-To: References: Message-ID: On Tue, 2 May 2023 17:43:46 GMT, Harshitha Onkar wrote: > Updated libpng from 1.6.38 to 1.6.39. > > - libpng.md file updated accordingly > - src code files updated from upstream > > CIient (CI Testing) and SplashScreen related tests work as expected with the changes. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13755#pullrequestreview-1411660792 From honkar at openjdk.org Wed May 3 19:42:23 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 3 May 2023 19:42:23 GMT Subject: Integrated: JDK-8305815: Update Libpng to 1.6.39 In-Reply-To: References: Message-ID: On Tue, 2 May 2023 17:43:46 GMT, Harshitha Onkar wrote: > Updated libpng from 1.6.38 to 1.6.39. > > - libpng.md file updated accordingly > - src code files updated from upstream > > CIient (CI Testing) and SplashScreen related tests work as expected with the changes. This pull request has now been integrated. Changeset: 14874779 Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/14874779eeb9a279479c5aaddb40c056780d6152 Stats: 101 lines in 10 files changed: 15 ins; 1 del; 85 mod 8305815: Update Libpng to 1.6.39 Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13755 From prr at openjdk.org Wed May 3 19:57:13 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 19:57:13 GMT Subject: RFR: 8307165: java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java timed out In-Reply-To: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> References: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> Message-ID: On Tue, 2 May 2023 20:46:00 GMT, Damon Nguyen wrote: > When converting this test to be applicable to be open sourced, changes were made. I reverted some of these changes to get the test stable again. Now it passes when run on various OS's 100x. The delay -> sleep changes really are no-ops .. except one you made shorter .. And the calls like validate() seem OK .. Do you have any explanation as to why these changes fix the time out ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13761#issuecomment-1533648520 From asemenov at openjdk.org Wed May 3 20:00:16 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Wed, 3 May 2023 20:00:16 GMT Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical methods in its C API In-Reply-To: References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> Message-ID: <4NG6KzG3leJNFP8yh-PrzvPePVWcmunyunCjkIk6kTI=.2200584a-d694-4f6b-b7ec-721ec42790af@github.com> On Wed, 3 May 2023 17:27:53 GMT, Phil Race wrote: >> In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge: >> >> addJavaEventNotification >> removeJavaEventNotification >> addAccessibilityEventNotification >> removeAccessibilityEventNotification >> >> >> However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future > > So perhaps something internal in the various accessbridge dll's needs it. How will you test this ? > Who here has JAWS ? If you don't have JAWS and therefore can't use it to verify the A11Y test suite then > I don't think you can test this change in a way that makes me comfortable in doing anything here. @prrace Maybe try using free NVDA for testing? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1533652112 From prr at openjdk.org Wed May 3 20:00:15 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 20:00:15 GMT Subject: RFR: JDK-8307083: Open source some drag and drop tests 3 In-Reply-To: References: Message-ID: On Tue, 2 May 2023 21:53:59 GMT, Alisen Chung wrote: > moving tests to open Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13764#pullrequestreview-1411702529 From prr at openjdk.org Wed May 3 20:07:19 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 20:07:19 GMT Subject: RFR: 8307091: Few test threw ConcurrentModificationException Intermittently In-Reply-To: References: Message-ID: On Wed, 3 May 2023 16:13:53 GMT, Tejesh R wrote: > Few test are throwing Concurrent Modification Exception Intermittently. Since the issue is intermittent and from the log and code review, It is found that the shared variable `fileCache` is used in comparison with the `newFileCache` where the comparison invokes the iterator method in AbstractList class. Since based on vector documentation it was evident that listIterator are fail-fast iterators and hence it would be better to make a separate local copy of vectors for comparing operations. > The same is implemented and tested in CI system which shows green. Looks reasonable. Fix the formatting I noted PS update the PR summary to match the revised JBS one - "A few client tests intermittently throw ConcurrentModificationException" src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 387: > 385: if (start >= 0 && end > start) { > 386: List listEnd_OldSize = new Vector<>(fileCache.subList(end, oldSize)); > 387: if(listEnd_OldSize.equals(newFileCache.subList(start, newSize))) { if( -> "if (" ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13783#pullrequestreview-1411706092 PR Comment: https://git.openjdk.org/jdk/pull/13783#issuecomment-1533660964 PR Review Comment: https://git.openjdk.org/jdk/pull/13783#discussion_r1184196345 From prr at openjdk.org Wed May 3 20:15:14 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 20:15:14 GMT Subject: RFR: 8306489: Open source AWT List related tests [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 07:01:28 GMT, Abhishek Kumar wrote: >> This PR is to open source List related AWT tests. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13748#pullrequestreview-1411728950 From jiangli at openjdk.org Wed May 3 20:25:13 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 20:25:13 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/e65aee25..84861990 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=03-04 Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Wed May 3 20:25:17 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 20:25:17 GMT Subject: RFR: 8307194: Enhance static-libs-image [v2] In-Reply-To: References: <0T3QYhW2lCL0cut65awn0zF2_xsBu57OhgeBfG13Mbk=.31927d2d-876b-4e8d-8ad1-8642ff0cfb3f@github.com> Message-ID: On Wed, 3 May 2023 18:31:56 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Update based on @erikj79 review comments and suggestions: >> - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk. >> - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk. > > make/Main.gmk line 261: > >> 259: endef >> 260: >> 261: $(foreach v, $(JVM_VARIANTS), $(eval $(call DeclareHotspotStaticLibsRecipe,$v))) > > If we are only using the libjvm.a from the main variant, we don't need to generate top level rules for all variants, or we could at least limit the dependency declaration at line 1109 to only need the main variant. Changed to define/use the `libjvm.a` rule for the main variant only as suggested, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184217800 From prr at openjdk.org Wed May 3 20:32:14 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 20:32:14 GMT Subject: RFR: JDK-8307128: Open source some drag and drop tests 4 In-Reply-To: References: Message-ID: On Tue, 2 May 2023 22:09:18 GMT, Alisen Chung wrote: > added DnD tests Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13765#pullrequestreview-1411754421 From prr at openjdk.org Wed May 3 20:47:22 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 20:47:22 GMT Subject: RFR: 8307132: Cleanup the code of sun.java2d.cmm.lcms package In-Reply-To: <_LRz2K4G7ZNjIO9C_5z2N9xWTfz25uUtRmefY2FRfkA=.d111a3fc-4264-43fb-a238-dc7129c61506@github.com> References: <_LRz2K4G7ZNjIO9C_5z2N9xWTfz25uUtRmefY2FRfkA=.d111a3fc-4264-43fb-a238-dc7129c61506@github.com> Message-ID: <9mMbcu9aJE_XKmjHNtBkWeUf-pwQ_59XYQvVPSpu8Ps=.fb521168-9b18-4eb1-a171-f62556f927b9@github.com> On Fri, 28 Apr 2023 21:34:36 GMT, Sergey Bylokhov wrote: > The description from big to small: > > - Our code to handle the image types we support is too generic, the LCMSImageLayout class can handle, byte, short, int, and double types, and many various properties of the image layout. As a result, we pass a couple of good parameters to the LCMSImageLayout and have to use safeXX methods in it to calculate the final layout, and then validate it. > This patch moves the layout properties calculation to one place - the constructor of LCMSImageLayout, and from the outside of the class, we now pass only the data array and the number of components per pixel: > - The usage of Double type is removed, we do not use that type currently, and do not plan to support it in the future. Note that we support the float type, and I tried to implement it, but unfortunately, it is [intentionally ](https://github.com/mm2/Little-CMS/issues/356)slow. So will continue to use short type instead of float. > - Discussed a few times the `do { } while (false);` block is removed. src/java.desktop/share/native/liblcms/LCMS.c line 51: > 49: #define DT_BYTE sun_java2d_cmm_lcms_LCMSImageLayout_DT_BYTE > 50: #define DT_SHORT sun_java2d_cmm_lcms_LCMSImageLayout_DT_SHORT > 51: #define DT_INT sun_java2d_cmm_lcms_LCMSImageLayout_DT_INT I don't understand why this isn't a step backwards. It is overloading the "size" to mean the "type" How would you tell the difference between SHORT vs UNSIGNED SHORT - both 2 bytes, or INT vs FLOAT - both 4 bytes ? or LONG vs DOUBLE .. If we ever need to, then this all needs to be reverted. % cd java/lang % grep BYTES *java Byte.java: public static final int BYTES = SIZE / Byte.SIZE; Character.java: public static final int BYTES = SIZE / Byte.SIZE; Double.java: public static final int BYTES = SIZE / Byte.SIZE; Float.java: public static final int BYTES = SIZE / Byte.SIZE; Integer.java: public static final int BYTES = SIZE / Byte.SIZE; Long.java: public static final int BYTES = SIZE / Byte.SIZE; Short.java: public static final int BYTES = SIZE / Byte.SIZE; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13732#discussion_r1184257243 From duke at openjdk.org Wed May 3 20:49:30 2023 From: duke at openjdk.org (Martin Desruisseaux) Date: Wed, 3 May 2023 20:49:30 GMT Subject: Integrated: 8306320: BufferedImage spec needs clarification w.r.t its implementation of the WritableRenderedImage interface In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 09:30:07 GMT, Martin Desruisseaux wrote: > `BufferedImage` implements the `WritableRenderedImage` interface. But the Javadoc is copied from `WritableRenderedImage`, while `BufferedImage` does something quite different. In particular, `TileObserver` are ignored. This pull request add `@implSlec` for explaining the default behaviour. > > This commit has one specification change in `isTileWritable`: the exception type is changed from `ArrayIndexOutOfBoundsException` to `IllegalArgumentException` for matching the implementation. The logical conditions is also corrected. > > This commit contains a trivial code change: `new Point(0,0)` is replaced by `new Point()` for saving a few byte codes. This pull request has now been integrated. Changeset: dcb2f3f5 Author: Martin Desruisseaux Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/dcb2f3f5029ebdb2bb088ad10bed2134aa71cf1a Stats: 39 lines in 1 file changed: 36 ins; 0 del; 3 mod 8306320: BufferedImage spec needs clarification w.r.t its implementation of the WritableRenderedImage interface Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13506 From duke at openjdk.org Wed May 3 20:51:33 2023 From: duke at openjdk.org (Jeremy) Date: Wed, 3 May 2023 20:51:33 GMT Subject: Integrated: 4200096: OffScreenImageSource.removeConsumer NullPointerException In-Reply-To: References: Message-ID: On Mon, 10 Apr 2023 16:16:32 GMT, Jeremy wrote: > This resolves a 25 year old P4 ticket: a NullPointerException is printed to System.err needlessly. > > This resolution involves confirming that an ImageConsumer is still registered before every notification. > > I'll understand if this is rejected as unimportant, but I stumbled across this in the real world the other day and thought this was a simple enough bug to practice on. This pull request has now been integrated. Changeset: 63cd0a36 Author: jeremy Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/63cd0a36dabb3b3446996d0409803238f81fc197 Stats: 394 lines in 5 files changed: 392 ins; 0 del; 2 mod 4200096: OffScreenImageSource.removeConsumer NullPointerException Reviewed-by: prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/13408 From prr at openjdk.org Wed May 3 20:54:14 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 20:54:14 GMT Subject: RFR: JDK-8305593: Add @spec tags in java.desktop In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 20:09:40 GMT, Jonathan Gibbons wrote: >> src/java.desktop/share/classes/java/awt/Desktop.java line 591: >> >>> 589: * subprocess >>> 590: * @spec https://www.rfc-editor.org/info/rfc2368 >>> 591: * RFC 2368: The mailto URL scheme >> >> The javadoc above references ietf.org. This tag references rfc-editor.org. It seems odd to use two different URLs >> in the same method specification for the same RFC. I would have thought the ietf one better to use .. although it should be updated to https > > This work is primarily about adding `@spec` tags, in a semi-automated fashion, using a custom utility that scans comments in the public API, looking for `href`s to "well-known" sites hosting external specifications. While "mostly automated", I did manually cleanup the references by line-wrapping as appropriate. > > It is out of scope at this time to cleanup up the underlying `href`s, although we should look at cleaning up those links later, identifying the latest/preferred URL for the appropriate version of the spec document, which may or may not be the latest overall version of the spec. (For example, the client docs reference HTML 3.2, and should not reference anything more recent.). This cleanup can be done later and needs to be done in conjunction with the relevant teams, and probably not as a semi-automated update. Such cleanup should be somewhat easier once we have tagged the affected comments with the relevant `@spec` tags. > > I note that once we have completed the addition of the `@spec` tags, we will, re-enable the new "External Specifications" page, which cross-references where each individual external specification is mentioned in the overall API documentation. Sorry, but no matter how many times I try, it seems wrong to even for some short amount of time to have @spec point to one place and the javadoc point to another. They should always be consistent. If it is out of scope to update the javadoc, then the new spec tag should just match the existing javadoc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13360#discussion_r1184267504 From honkar at openjdk.org Wed May 3 21:05:36 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 3 May 2023 21:05:36 GMT Subject: RFR: JDK-8307381: Open Source JFrame, JIF related Swing Tests Message-ID: Open sourced few JFrame, JIF related Swing tests. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/13787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13787&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307381 Stats: 354 lines in 6 files changed: 354 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13787/head:pull/13787 PR: https://git.openjdk.org/jdk/pull/13787 From azvegint at openjdk.org Wed May 3 21:05:45 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 3 May 2023 21:05:45 GMT Subject: RFR: 8306943: Open source several dnd AWT tests [v2] In-Reply-To: References: Message-ID: > Open sourcing few more tests: > > java/awt/dnd/DnDAWTLockTest/DnDAWTLockTest.java > java/awt/dnd/DragGestureInvokeLaterTest/DragGestureInvokeLaterTest.java > java/awt/dnd/DragOverDropTargetPerformanceTest/DragOverDropTargetPerformanceTest.java > java/awt/dnd/DragSourceDragEventModifiersTest/DragSourceDragEventModifiersTest.java > java/awt/dnd/DragSourceGCrashTest/DragSourceGCrashTest.java > > > Testing looks good. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: add volatile ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13752/files - new: https://git.openjdk.org/jdk/pull/13752/files/b0cdf45f..ec43740f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13752&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13752&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13752/head:pull/13752 PR: https://git.openjdk.org/jdk/pull/13752 From azvegint at openjdk.org Wed May 3 21:05:45 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 3 May 2023 21:05:45 GMT Subject: RFR: 8306943: Open source several dnd AWT tests [v2] In-Reply-To: <216U1p9HeqRZBB9P9pmWRzJKvsTKLIpIzBXmIQdpuyk=.3ee5df42-d804-43ae-9aca-a73b97e250a1@github.com> References: <216U1p9HeqRZBB9P9pmWRzJKvsTKLIpIzBXmIQdpuyk=.3ee5df42-d804-43ae-9aca-a73b97e250a1@github.com> Message-ID: <_WnZV7fFq7kzgLVqmFIGSO97sn4nJY7gIzMDb3GqBm8=.25111a85-5dfc-41f9-b14a-0ad0d935cea3@github.com> On Tue, 2 May 2023 19:54:45 GMT, Sergey Bylokhov wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> add volatile > > test/jdk/java/awt/dnd/DnDAWTLockTest.java line 150: > >> 148: public void run() { >> 149: try { >> 150: if (process == null) { > > do we need to add a sync for process and sourcePoint? I don't think so. `lostOwnership` is called when some other client changes the contents of the clipboard. It can be either our `Child` process or other programs in the system. In first case `process` and `sourcePoint` are not `null` by this time. In the second case, it will also mean a test failure because the test expects a very certain clipboard content. I made them volatile just in case, since they are accessed from several threads. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13752#discussion_r1184276306 From prr at openjdk.org Wed May 3 21:17:15 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 21:17:15 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v2] In-Reply-To: <6AMf-eKADne9JGixe0AxYWuSCpoT0zPLMSVJ32hg8LU=.77ff4752-a702-4dad-bf80-e44cd91985f0@github.com> References: <6AMf-eKADne9JGixe0AxYWuSCpoT0zPLMSVJ32hg8LU=.77ff4752-a702-4dad-bf80-e44cd91985f0@github.com> Message-ID: <0gOhTUXPHgGwkGUPT-I8JNKvQWQcXCfenFMFRRWv-mE=.5e796740-d480-4190-b0bb-45770e248aee@github.com> On Tue, 2 May 2023 18:10:55 GMT, Alexey Ivanov wrote: >> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2323: >> >>> 2321: @Override >>> 2322: public boolean equals(Object val) { >>> 2323: return val instanceof CSS.FontFamily font && family == font.family; >> >> Is the `family` field interned somewhere? If it isn't, then should this be: >> >> >> return val instanceof CSS.FontFamily font && >> Objects.equals(family, font.family); >> >> >> For ex if we tweak the start of the FontFamily unit test as follows does it still pass? >> >> private static void testFontFamily() { >> StyleSheet ss = new StyleSheet(); >> >> SimpleAttributeSet a = new SimpleAttributeSet(); >> ss.addCSSAttribute( a, CSS.Attribute.FONT_FAMILY, "Sans-Serif"); >> >> SimpleAttributeSet b = new SimpleAttributeSet(); >> ss.addCSSAttribute( b, CSS.Attribute.FONT_FAMILY, "Sans-Serif"); > > I'm pretty sure the test will still pass because Java compiler interns strings. You have to explicitly create a new instance of the String to make the test fail. > > In real applications, attributes are parsed from a style sheet and therefore the identity test won't pass. yes this needs to be changed. Also needs to be changed at line 2034. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1184292300 From prr at openjdk.org Wed May 3 21:21:15 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 21:21:15 GMT Subject: RFR: 8306943: Open source several dnd AWT tests [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 21:05:45 GMT, Alexander Zvegintsev wrote: >> Open sourcing few more tests: >> >> java/awt/dnd/DnDAWTLockTest/DnDAWTLockTest.java >> java/awt/dnd/DragGestureInvokeLaterTest/DragGestureInvokeLaterTest.java >> java/awt/dnd/DragOverDropTargetPerformanceTest/DragOverDropTargetPerformanceTest.java >> java/awt/dnd/DragSourceDragEventModifiersTest/DragSourceDragEventModifiersTest.java >> java/awt/dnd/DragSourceGCrashTest/DragSourceGCrashTest.java >> >> >> Testing looks good. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > add volatile Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13752#pullrequestreview-1411873995 From jiangli at openjdk.org Wed May 3 21:43:19 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 3 May 2023 21:43:19 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 18:51:54 GMT, Severin Gehwolf wrote: >>> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. >>> >>> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? >> >> Good questions. I had similar thoughts when making the makefile changes. Here's my reasoning with the current approach in this PR: >> >> The `images/static-libs/lib` would provide a super set of the JDK/VM static libraries (in a JDK binary/release) for downstream developers to produce their desired final static image. With the addition of the `libjvm.a` and potentially bundled `libzlib.a` and `libfreetype.a` included in `static-libs-image` output, users could select the needed subset of the static libraries for their linking step (e.g. via jlink based on the needed modules) to produce the final image. >> >> If these changes are cumbersome for `graal-builder-image` usages, using `hotspot-static-libs` directly for producing `libjvm.a` as you suggested could be doable. Or, we could try using a new make target for producing the `.a` superset. There might be potential concerns/issues with the differences between `graal-builder-image` support and Java static image support, i.e. it might be a good idea to explore unified solution for both if possible. @dougxc and others related to GraalVM Native Image are on this review thread. It's a good idea to collect the thoughts together. > > GraalVM native-image has it's own `libjvm.a` shim which would likely conflict or produce undesirable results. So I'd prefer the approach where `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For new uses-cases needing that, we could add a new top-level target (like `graal-builder-image`) which would produce such an image. As one of the [Mandrel](https://github.com/graalvm/mandrel) maintainers, I'm not sure any post-build filtering via `jlink` or the like would be ideal for us. I'll see if I can test this on a mandrel build tomorrow... @jerboaa, thanks for the info. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184317386 From prr at openjdk.org Wed May 3 21:45:18 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 3 May 2023 21:45:18 GMT Subject: RFR: 8304503: Modernize debugging jvm args in demo netbeans projects In-Reply-To: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com> References: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com> Message-ID: On Mon, 20 Mar 2023 13:06:19 GMT, Eirik Bjorsnos wrote: > Please review this PR which suggests to modernize the JVM arguments used to enable debugging in the netbeans project files for demos. > > The netbeans projects found in src/demo/share/nbproject currently use the following outdated combination of jvm arguments to set up debugging: > > > > > > > > > They should instead just do: > > > > > > Additionally, the source dir set up in build.properties for these projects do not seem to align with the source layout. > > `src.dir=${main.dir}/src` should instead be just `src.dir=${main.dir}/` Ok, since you tested it .. I'm approving, but I think the odds are few people will notice either way. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13101#pullrequestreview-1411928989 From honkar at openjdk.org Wed May 3 21:47:18 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 3 May 2023 21:47:18 GMT Subject: RFR: 8307165: java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java timed out In-Reply-To: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> References: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> Message-ID: On Tue, 2 May 2023 20:46:00 GMT, Damon Nguyen wrote: > When converting this test to be applicable to be open sourced, changes were made. I reverted some of these changes to get the test stable again. Now it passes when run on various OS's 100x. test/jdk/java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java line 97: > 95: frame.getToolkit().addAWTEventListener(this, AWTEvent.MOUSE_EVENT_MASK); > 96: frame.pack(); > 97: frame.setLocationRelativeTo(null); It would be better to retain `frame.setLocationRelativeTo(null)` since you are calling `getLocationOnScreen()` later on. test/jdk/java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java line 104: > 102: try { > 103: Robot robot = new Robot(); > 104: Thread.sleep(FRAME_ACTIVATION_TIMEOUT); Curious to know the difference of using `Thread.sleep()` instead of `robot.delay()` here ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13761#discussion_r1184320143 PR Review Comment: https://git.openjdk.org/jdk/pull/13761#discussion_r1184317155 From dnguyen at openjdk.org Thu May 4 02:16:14 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 4 May 2023 02:16:14 GMT Subject: RFR: 8307091: Few test threw ConcurrentModificationException Intermittently In-Reply-To: References: Message-ID: On Wed, 3 May 2023 16:13:53 GMT, Tejesh R wrote: > Few test are throwing Concurrent Modification Exception Intermittently. Since the issue is intermittent and from the log and code review, It is found that the shared variable `fileCache` is used in comparison with the `newFileCache` where the comparison invokes the iterator method in AbstractList class. Since based on vector documentation it was evident that listIterator are fail-fast iterators and hence it would be better to make a separate local copy of vectors for comparing operations. > The same is implemented and tested in CI system which shows green. Marked as reviewed by dnguyen (Committer). Looks like there's a title mismatch blocking you from integrating but changes LGTM. ------------- PR Review: https://git.openjdk.org/jdk/pull/13783#pullrequestreview-1412167729 PR Comment: https://git.openjdk.org/jdk/pull/13783#issuecomment-1533986428 From tr at openjdk.org Thu May 4 04:57:11 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 4 May 2023 04:57:11 GMT Subject: RFR: 8307091: A few client tests intermittently throw ConcurrentModificationException [v2] In-Reply-To: References: Message-ID: > Few test are throwing Concurrent Modification Exception Intermittently. Since the issue is intermittent and from the log and code review, It is found that the shared variable `fileCache` is used in comparison with the `newFileCache` where the comparison invokes the iterator method in AbstractList class. Since based on vector documentation it was evident that listIterator are fail-fast iterators and hence it would be better to make a separate local copy of vectors for comparing operations. > The same is implemented and tested in CI system which shows green. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13783/files - new: https://git.openjdk.org/jdk/pull/13783/files/5829aade..03493ba6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13783&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13783&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13783.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13783/head:pull/13783 PR: https://git.openjdk.org/jdk/pull/13783 From tr at openjdk.org Thu May 4 04:57:13 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 4 May 2023 04:57:13 GMT Subject: RFR: 8307091: A few client tests intermittently throw ConcurrentModificationException [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 19:59:15 GMT, Phil Race wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 387: > >> 385: if (start >= 0 && end > start) { >> 386: List listEnd_OldSize = new Vector<>(fileCache.subList(end, oldSize)); >> 387: if(listEnd_OldSize.equals(newFileCache.subList(start, newSize))) { > > if( -> "if (" Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13783#discussion_r1184536691 From tr at openjdk.org Thu May 4 04:57:15 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 4 May 2023 04:57:15 GMT Subject: Integrated: 8307091: A few client tests intermittently throw ConcurrentModificationException In-Reply-To: References: Message-ID: On Wed, 3 May 2023 16:13:53 GMT, Tejesh R wrote: > Few test are throwing Concurrent Modification Exception Intermittently. Since the issue is intermittent and from the log and code review, It is found that the shared variable `fileCache` is used in comparison with the `newFileCache` where the comparison invokes the iterator method in AbstractList class. Since based on vector documentation it was evident that listIterator are fail-fast iterators and hence it would be better to make a separate local copy of vectors for comparing operations. > The same is implemented and tested in CI system which shows green. This pull request has now been integrated. Changeset: 465bdd9e Author: Tejesh R URL: https://git.openjdk.org/jdk/commit/465bdd9e416cacc6cc7dd91a29cc84adf2eaf1ed Stats: 18 lines in 1 file changed: 8 ins; 2 del; 8 mod 8307091: A few client tests intermittently throw ConcurrentModificationException Reviewed-by: prr, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/13783 From serb at openjdk.org Thu May 4 05:44:15 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 May 2023 05:44:15 GMT Subject: RFR: 8307299: Move more DnD tests to open [v3] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 21:07:21 GMT, Alisen Chung wrote: >> Added DnD tests > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > moved some function calls on EDT test/jdk/java/awt/dnd/IntraJVMGetDropSuccessTest.java line 253: > 251: > 252: public void reset() { > 253: clickedComponent = null; seems here you access/reset that field on the main thread as well ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13759#discussion_r1184562790 From serb at openjdk.org Thu May 4 05:45:13 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 May 2023 05:45:13 GMT Subject: RFR: 8307133: Open source some JTable jtreg tests [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 17:38:36 GMT, Phil Race wrote: >> Open source some Swing JTable tests > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8307133 Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13745#pullrequestreview-1412321646 From serb at openjdk.org Thu May 4 05:48:13 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 May 2023 05:48:13 GMT Subject: RFR: 8306489: Open source AWT List related tests [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 07:01:28 GMT, Abhishek Kumar wrote: >> This PR is to open source List related AWT tests. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update Looks fine, please confirm that mach5 is green. ------------- Marked as reviewed by serb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13748#pullrequestreview-1412323824 From serb at openjdk.org Thu May 4 05:49:16 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 May 2023 05:49:16 GMT Subject: RFR: 8306943: Open source several dnd AWT tests [v2] In-Reply-To: References: Message-ID: <_EAfXlp5SdrvDxw11G088Q2RW7UVnowW3EyXWmpygJA=.e12cfd5d-29fa-468b-8e5c-f03b4ed885c1@github.com> On Wed, 3 May 2023 21:05:45 GMT, Alexander Zvegintsev wrote: >> Open sourcing few more tests: >> >> java/awt/dnd/DnDAWTLockTest/DnDAWTLockTest.java >> java/awt/dnd/DragGestureInvokeLaterTest/DragGestureInvokeLaterTest.java >> java/awt/dnd/DragOverDropTargetPerformanceTest/DragOverDropTargetPerformanceTest.java >> java/awt/dnd/DragSourceDragEventModifiersTest/DragSourceDragEventModifiersTest.java >> java/awt/dnd/DragSourceGCrashTest/DragSourceGCrashTest.java >> >> >> Testing looks good. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > add volatile Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13752#pullrequestreview-1412324499 From serb at openjdk.org Thu May 4 05:51:16 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 May 2023 05:51:16 GMT Subject: RFR: 8307297: Move some DnD tests to open [v2] In-Reply-To: References: Message-ID: <_6XymQP2QLAUaRiGf2JBqgBahcUNhcKoajRBNElWtL8=.b4a48524-d899-43e3-b831-7ad5d7e3f559@github.com> On Tue, 2 May 2023 20:57:28 GMT, Alisen Chung wrote: >> Adding some DnD tests > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > added space after if, moved some function calls on EDT Looks fine, please confirm that mach5 is green. ------------- Marked as reviewed by serb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13756#pullrequestreview-1412325845 From serb at openjdk.org Thu May 4 05:52:12 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 May 2023 05:52:12 GMT Subject: RFR: JDK-8307381: Open Source JFrame, JIF related Swing Tests In-Reply-To: References: Message-ID: On Wed, 3 May 2023 20:58:00 GMT, Harshitha Onkar wrote: > Open sourced the following JFrame, JIF related Swing tests. > > > test/jdk/javax/swing/JFrame/bug4101444.java > test/jdk/javax/swing/JFrame/bug4208018.java > test/jdk/javax/swing/JInternalFrame/bug4308938.java > test/jdk/javax/swing/JInternalFrame/bug4320889.java > test/jdk/javax/swing/JTextField/bug4300552.java > test/jdk/javax/swing/JToggleButton/bug4277049.java > > > CI testing looks good. Looks like the JBS issue is confidential: ?? Temporary failure when trying to retrieve information on issue JDK-8307381 ------------- PR Comment: https://git.openjdk.org/jdk/pull/13787#issuecomment-1534127095 From serb at openjdk.org Thu May 4 05:57:14 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 May 2023 05:57:14 GMT Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11 sessions [v5] In-Reply-To: References: <8OXzmL_G8FE4dhl0Y5zgQT6cYDSd_VIH-LLtjRM0v2E=.b848094f-2f58-4de4-90fe-1ac459efc0d1@github.com> Message-ID: On Thu, 27 Apr 2023 09:16:26 GMT, Maxim Kartashev wrote: >> src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java line 894: >> >>> 892: Insets insets = device.getInsets(); >>> 893: if (insets == null) { >>> 894: insets = getScreenInsetsImpl(gc); >> >> Is it possible to set insets in the device constructor and update it on a callback? In this case, this method will be just an accessor. > >> Is it possible to set insets in the device constructor > > I would very much like to delay getting the insets until they are actually needed. The device construction is already happening at the time when lots of info is being fetched from the X server; however, insets are needed relatively rarely, the major use case being pull-down menus. > > In Ubuntu, for instance, you can change your Dock size gradually with a slider and each time insets get updated. But unless you open a menu while dragging that slider (which is virtually impossible), the Java program doesn't need to know about new insets, all it needs is to know that the current insets are outdated. Once Dock has been resized *and* the focus has shifted to the Java application *and* menu is about to be opened, then we *must* call `getScreenInsetsImpl()` to fetch the new insets. In this scenario we do this only once instead of each time the slider in the Dock configuration dialog changes its state. > >> Is it possible [...] update it on a callback? In this case, this method will be just an accessor. > > I'm afraid I don't fully understand what you meant. Can you give an example in pseudo-code? If we would like to initialize it lazy then can we change that synchronization to use the "double-checked locking" instead of "synchronized (device)"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13346#discussion_r1184569050 From abhiscxk at openjdk.org Thu May 4 06:11:26 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 4 May 2023 06:11:26 GMT Subject: Integrated: 8306489: Open source AWT List related tests In-Reply-To: References: Message-ID: On Tue, 2 May 2023 06:26:36 GMT, Abhishek Kumar wrote: > This PR is to open source List related AWT tests. This pull request has now been integrated. Changeset: 82a8e91e Author: Abhishek Kumar URL: https://git.openjdk.org/jdk/commit/82a8e91ef7c3b397f9cce3854722cfe4bace6f2e Stats: 824 lines in 7 files changed: 824 ins; 0 del; 0 mod 8306489: Open source AWT List related tests Reviewed-by: prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/13748 From serb at openjdk.org Thu May 4 06:18:14 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 May 2023 06:18:14 GMT Subject: RFR: 8307132: Cleanup the code of sun.java2d.cmm.lcms package In-Reply-To: <9mMbcu9aJE_XKmjHNtBkWeUf-pwQ_59XYQvVPSpu8Ps=.fb521168-9b18-4eb1-a171-f62556f927b9@github.com> References: <_LRz2K4G7ZNjIO9C_5z2N9xWTfz25uUtRmefY2FRfkA=.d111a3fc-4264-43fb-a238-dc7129c61506@github.com> <9mMbcu9aJE_XKmjHNtBkWeUf-pwQ_59XYQvVPSpu8Ps=.fb521168-9b18-4eb1-a171-f62556f927b9@github.com> Message-ID: <92zysAQG9gAswvFcNm9RXTHtSe-rJDTNV-NNEGF0egM=.8ab6d539-1218-402c-b244-85460207ce71@github.com> On Wed, 3 May 2023 20:44:24 GMT, Phil Race wrote: >> The description from big to small: >> >> - Our code to handle the image types we support is too generic, the LCMSImageLayout class can handle, byte, short, int, and double types, and many various properties of the image layout. As a result, we pass a couple of good parameters to the LCMSImageLayout and have to use safeXX methods in it to calculate the final layout, and then validate it. >> This patch moves the layout properties calculation to one place - the constructor of LCMSImageLayout, and from the outside of the class, we now pass only the data array and the number of components per pixel: >> - The usage of Double type is removed, we do not use that type currently, and do not plan to support it in the future. Note that we support the float type, and I tried to implement it, but unfortunately, it is [intentionally ](https://github.com/mm2/Little-CMS/issues/356)slow. So will continue to use short type instead of float. >> - Discussed a few times the `do { } while (false);` block is removed. > > src/java.desktop/share/native/liblcms/LCMS.c line 51: > >> 49: #define DT_BYTE sun_java2d_cmm_lcms_LCMSImageLayout_DT_BYTE >> 50: #define DT_SHORT sun_java2d_cmm_lcms_LCMSImageLayout_DT_SHORT >> 51: #define DT_INT sun_java2d_cmm_lcms_LCMSImageLayout_DT_INT > > I don't understand why this isn't a step backwards. > It is overloading the "size" to mean the "type" > How would you tell the difference between SHORT vs UNSIGNED SHORT - both 2 bytes, > or INT vs FLOAT - both 4 bytes ? > or LONG vs DOUBLE .. > If we ever need to, then this all needs to be reverted. > % cd java/lang > % grep BYTES *java > Byte.java: public static final int BYTES = SIZE / Byte.SIZE; > Character.java: public static final int BYTES = SIZE / Byte.SIZE; > Double.java: public static final int BYTES = SIZE / Byte.SIZE; > Float.java: public static final int BYTES = SIZE / Byte.SIZE; > Integer.java: public static final int BYTES = SIZE / Byte.SIZE; > Long.java: public static final int BYTES = SIZE / Byte.SIZE; > Short.java: public static final int BYTES = SIZE / Byte.SIZE; right, the idea was to use one variable to select the supported type using its size. Based on size we will switch what GetXXArrayElements to use. java right now supports these related functions: GetByteArrayElements, GetShortArrayElements, GetIntArrayElements, GetLongArrayElements, GetFloatArrayElements, GetDoubleArrayElements, The images based on long format currently are not supported by java2d and lcms. And the "float" formats are really slow in LCMS as mentioned in the description. >How would you tell the difference between SHORT vs UNSIGNED SHORT - both 2 bytes, Both will use the same code path. But I can switch this to using two different variables for type and size. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13732#discussion_r1184580685 From duke at openjdk.org Thu May 4 06:41:18 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Thu, 4 May 2023 06:41:18 GMT Subject: RFR: 8304503: Modernize debugging jvm args in demo netbeans projects In-Reply-To: References: <2rBCva9zeqhfdLlc16Rto6gB-qp8zk6XZkQyO5eufj8=.f97c92e7-d66a-4fd6-a85d-64544a535567@github.com> Message-ID: On Wed, 3 May 2023 21:42:50 GMT, Phil Race wrote: > Ok, since you tested it .. I'm approving, but I think the odds are few people will notice either way. Thanks Phil, I?ve integrated. I?ll consider a removal patch once I get back from vacation. If nobody uses these projects, I agree it would be cleaner to simply remove them. But for this PR, the purpose was to rid the OpenJDK of reference to the removed property so they don?t show up in code searches. It?s good to have that done, so thanks for your approval ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13101#issuecomment-1534162540 From jwaters at openjdk.org Thu May 4 07:08:14 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 4 May 2023 07:08:14 GMT Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical methods in its C API In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> Message-ID: <6dWmIc0E2pbK_jxjHOuxslZz6z_044vqCIm7a79WQFc=.94961641-35be-417b-8c9c-7648609fcb2e@github.com> On Sat, 29 Apr 2023 19:26:00 GMT, Julian Waters wrote: > In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge: > > addJavaEventNotification > removeJavaEventNotification > addAccessibilityEventNotification > removeAccessibilityEventNotification > > > However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future The problem as I see it is that the .def is exporting something that simply does not exist at all, even if it is a non-public API and the symbols are simply exported from the DLL for internal use by other accessbridge code, then these methods should still be placed in the extern "C" block in the .cpp (but maybe not in the corresponding header since they aren't public). Conversely if it is never meant to be exported but the accessbridge DLLs somehow need the .def files to export phantom, nonexistent symbols to work properly, then something is seriously wrong with them and we should probably take a look at what on earth is going on there ------------- PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1534192271 From duke at openjdk.org Thu May 4 07:41:29 2023 From: duke at openjdk.org (Ravi Gupta) Date: Thu, 4 May 2023 07:41:29 GMT Subject: RFR: 8307325: Verify the focus owner when non focused windows requesting focus Message-ID: Write a test Check, when the top level Window is not the focused Window requesting for focus and becoming the Focus Owner for any Component in that Window checking the following 1.The Component is the Focus Owner and the Window becomes the focused Window If the platform supports cross requesting focus across Windows. 2.The request is remembered and be granted when the Window is later focused If the platform does not support requesting focus across Windows. Testing: Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. ------------- Commit messages: - 8307325: Verify the focus owner when non focused windows requesting focus Changes: https://git.openjdk.org/jdk/pull/13790/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13790&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307325 Stats: 149 lines in 1 file changed: 149 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13790.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13790/head:pull/13790 PR: https://git.openjdk.org/jdk/pull/13790 From mkartashev at openjdk.org Thu May 4 08:06:11 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Thu, 4 May 2023 08:06:11 GMT Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11 sessions [v6] In-Reply-To: References: Message-ID: > Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish. > > On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration. > > A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year. Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision: Double-checked locking for insets and less synchronization for bounds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13346/files - new: https://git.openjdk.org/jdk/pull/13346/files/1db1431c..a3d32570 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13346&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13346&range=04-05 Stats: 25 lines in 2 files changed: 4 ins; 10 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13346.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13346/head:pull/13346 PR: https://git.openjdk.org/jdk/pull/13346 From mkartashev at openjdk.org Thu May 4 08:06:14 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Thu, 4 May 2023 08:06:14 GMT Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11 sessions [v5] In-Reply-To: References: <8OXzmL_G8FE4dhl0Y5zgQT6cYDSd_VIH-LLtjRM0v2E=.b848094f-2f58-4de4-90fe-1ac459efc0d1@github.com> Message-ID: On Thu, 4 May 2023 05:54:09 GMT, Sergey Bylokhov wrote: >>> Is it possible to set insets in the device constructor >> >> I would very much like to delay getting the insets until they are actually needed. The device construction is already happening at the time when lots of info is being fetched from the X server; however, insets are needed relatively rarely, the major use case being pull-down menus. >> >> In Ubuntu, for instance, you can change your Dock size gradually with a slider and each time insets get updated. But unless you open a menu while dragging that slider (which is virtually impossible), the Java program doesn't need to know about new insets, all it needs is to know that the current insets are outdated. Once Dock has been resized *and* the focus has shifted to the Java application *and* menu is about to be opened, then we *must* call `getScreenInsetsImpl()` to fetch the new insets. In this scenario we do this only once instead of each time the slider in the Dock configuration dialog changes its state. >> >>> Is it possible [...] update it on a callback? In this case, this method will be just an accessor. >> >> I'm afraid I don't fully understand what you meant. Can you give an example in pseudo-code? > > If we would like to initialize it lazy then can we change that synchronization to use the "double-checked locking" instead of "synchronized (device)"? Makes sense to me. Please, check the update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13346#discussion_r1184674091 From duke at openjdk.org Thu May 4 09:56:18 2023 From: duke at openjdk.org (Ravi Gupta) Date: Thu, 4 May 2023 09:56:18 GMT Subject: RFR: 8305427: Write a test Check whether focus changes as expected when requestFocus is used to traverse randomly around the window [v5] In-Reply-To: References: Message-ID: > This testcase Checking whether the Component becoming the Focus Owner and FocusEvent.FOCUS_GAINED will be received by the Component when the focus is requested on the component using requestFocus. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision: code modified ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13293/files - new: https://git.openjdk.org/jdk/pull/13293/files/064595c2..a02de7da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13293&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13293&range=03-04 Stats: 93 lines in 1 file changed: 28 ins; 55 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13293/head:pull/13293 PR: https://git.openjdk.org/jdk/pull/13293 From duke at openjdk.org Thu May 4 10:10:17 2023 From: duke at openjdk.org (Paul Woegerer) Date: Thu, 4 May 2023 10:10:17 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: References: Message-ID: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> On Wed, 3 May 2023 18:51:54 GMT, Severin Gehwolf wrote: >>> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it. >>> >>> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both? >> >> Good questions. I had similar thoughts when making the makefile changes. Here's my reasoning with the current approach in this PR: >> >> The `images/static-libs/lib` would provide a super set of the JDK/VM static libraries (in a JDK binary/release) for downstream developers to produce their desired final static image. With the addition of the `libjvm.a` and potentially bundled `libzlib.a` and `libfreetype.a` included in `static-libs-image` output, users could select the needed subset of the static libraries for their linking step (e.g. via jlink based on the needed modules) to produce the final image. >> >> If these changes are cumbersome for `graal-builder-image` usages, using `hotspot-static-libs` directly for producing `libjvm.a` as you suggested could be doable. Or, we could try using a new make target for producing the `.a` superset. There might be potential concerns/issues with the differences between `graal-builder-image` support and Java static image support, i.e. it might be a good idea to explore unified solution for both if possible. @dougxc and others related to GraalVM Native Image are on this review thread. It's a good idea to collect the thoughts together. > > GraalVM native-image has it's own `libjvm.a` shim which would likely conflict or produce undesirable results. So I'd prefer the approach where `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For new uses-cases needing that, we could add a new top-level target (like `graal-builder-image`) which would produce such an image. As one of the [Mandrel](https://github.com/graalvm/mandrel) maintainers, I'm not sure any post-build filtering via `jlink` or the like would be ideal for us. I'll see if I can test this on a mandrel build tomorrow... As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184786403 From martin.desruisseaux at geomatys.com Thu May 4 11:02:25 2023 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Thu, 4 May 2023 13:02:25 +0200 Subject: BufferedImage.setData(Raster) does not copy float and double sample values properly Message-ID: Hello The BufferedImage Javadoc does not mention any constraint about the data type. In practice, BufferedImage with floating point values can be rendered as well as integers (only slower) provided that a compatible ColorModel was supplied at construction time. However calls to setData(Raster) unexpectedly cast floating point values to integers. For example sample value 0.8 become 0. This is demonstrated by a test case, together with a proposed fix, in the following pull request: https://github.com/openjdk/jdk/pull/13797 The proposed fix is very simple: just replace the whole method body by a call to WritableRaster.setRect(Raster), which handles all supported data types correctly. The pull request description contains code comparison for showing that this is equivalent, except for robustness to integer underflow. The pull request discusses the possible impact on behavior, which are: * Change in behavior under integer underflow. * One more user-overrideable method get invoked. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From aivanov at openjdk.org Thu May 4 12:42:18 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 May 2023 12:42:18 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v2] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 03:43:09 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/text/html/CSS/CSSAttributeEqualityBug.java line 44: >> >>> 42: >>> 43: private static void testFontSize() { >>> 44: StyleSheet ss = new StyleSheet(); >> >> The `StyleSheet` object isn't used in any of the tests, you can safely remove it. > > it is being used > `ss.addCSSAttribute(a, CSS.Attribute.FONT_SIZE, fontSize);` My bad! I lost track of it, and it appeared unused to me; I should've pulled the changes into a local branch and opened the test in IDE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1184957195 From aivanov at openjdk.org Thu May 4 12:45:19 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 May 2023 12:45:19 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v4] In-Reply-To: References: Message-ID: <8KEx3YjVgXqUW8_qds0xJj4ArHuJycwwyJNuSu2IGWY=.abf970be-b5cb-4954-8163-5113b73699f1@github.com> On Wed, 3 May 2023 11:00:36 GMT, Prasanta Sadhukhan wrote: >> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. >> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. >> Fixed by implementing the equality and hashCode method for CSS.FontSize class. >> >> All jtreg/jck tests are ok > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > More Attrbutes added Changes requested by aivanov (Reviewer). test/jdk/javax/swing/text/html/CSS/CSSAttributeEqualityBug.java line 119: > 117: System.out.println("b = " + b); > 118: throw new RuntimeException("CSS.Attribute.Color a is not equal to b"); > 119: } Does it make sense to introduce a new method which compares the two attributes sets `a` and `b`, prints messages and throws the exception? You'll need to pass the CSS attribute name to it. The code will be cleaner. ------------- PR Review: https://git.openjdk.org/jdk/pull/13405#pullrequestreview-1413005794 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1184960471 From azvegint at openjdk.org Thu May 4 15:33:07 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 4 May 2023 15:33:07 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots Message-ID: This PR is to make it easier to review documentation changes from #13803 and also covers the following issues https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures [Doc changes](https://github.com/openjdk/jdk/pull/13804/commits/bddf9683065175eba352f4a88806a7bed16f5e4c) are on top of #13803 ------------- Commit messages: - Merge branch 'X11_compatibility_screencast' into X11_compatibility_screencast_docs - replace tabs with spaces - doc changes - main changes - add pipewire header files Changes: https://git.openjdk.org/jdk/pull/13804/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13804&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8280982 Stats: 14325 lines in 107 files changed: 14283 ins; 18 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/13804.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13804/head:pull/13804 PR: https://git.openjdk.org/jdk/pull/13804 From azvegint at openjdk.org Thu May 4 15:34:42 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 4 May 2023 15:34:42 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots Message-ID: Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. This comes with some difficulties, and one of them is the inability to get screenshots from the system. This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) But this functionality is a very important part of automated testing. At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) It has several drawbacks though: + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). + There is no way to disable the visual "screen flash" after screenshot + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. But we still can consider this option as a fallback. 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. + implementation is more complicated comparing to Screenshot API + no intermediate file, screenshot data can be obtained from memory + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. This change also introduces some new behavior for the robot: A system window now appears asking for confirmation from the user to capture the screen. + The user can refuse the screen capture completely. In this case a security exception will be thrown. + The user can allow a screen capture for all screens or some of them. For screens without permission there will be a black image. + If the user wishes to change their mind about the screens allowed to be captured, the user should use the new `Robot#resetScreenCapturePermission` method Also added several system properties: `awt.robot.screencastEnabled` false by default, uses the ScreenCast API if true `awt.robot.screencastDebug` false by default, prints some debug information if true For convenience, this change is divided into two commits: 1. added [pipewire headers](https://gitlab.freedesktop.org/pipewire/pipewire/) that are needed for the build 2. main changes Changes in the documentation are in a separate PR (#13804) also for convenience. At the moment, the planned supported systems are Ubuntu 22.04+, the latest Oracle Linux 9.1 and RHEL 9.1 has some issues with restore_token support. ------------- Commit messages: - replace tabs with spaces - main changes - add pipewire header files Changes: https://git.openjdk.org/jdk/pull/13803/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8280982 Stats: 14277 lines in 107 files changed: 14237 ins; 18 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From azvegint at openjdk.org Thu May 4 15:42:31 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 4 May 2023 15:42:31 GMT Subject: Integrated: 8306943: Open source several dnd AWT tests In-Reply-To: References: Message-ID: On Tue, 2 May 2023 11:01:22 GMT, Alexander Zvegintsev wrote: > Open sourcing few more tests: > > java/awt/dnd/DnDAWTLockTest/DnDAWTLockTest.java > java/awt/dnd/DragGestureInvokeLaterTest/DragGestureInvokeLaterTest.java > java/awt/dnd/DragOverDropTargetPerformanceTest/DragOverDropTargetPerformanceTest.java > java/awt/dnd/DragSourceDragEventModifiersTest/DragSourceDragEventModifiersTest.java > java/awt/dnd/DragSourceGCrashTest/DragSourceGCrashTest.java > > > Testing looks good. This pull request has now been integrated. Changeset: 2adb3b40 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/2adb3b409e8cc87685a4379be3f7beeb53706e2e Stats: 1349 lines in 5 files changed: 1349 ins; 0 del; 0 mod 8306943: Open source several dnd AWT tests Reviewed-by: prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/13752 From kcr at openjdk.org Thu May 4 15:53:15 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 May 2023 15:53:15 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: On Thu, 4 May 2023 14:20:30 GMT, Alexander Zvegintsev wrote: > This PR is to make it easier to review documentation changes from #13803 and also covers the following issues > > https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots > https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor > https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. > https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures > > [Doc changes](https://github.com/openjdk/jdk/pull/13804/commits/bddf9683065175eba352f4a88806a7bed16f5e4c) are on top of #13803 @azvegint what is your plan for eventually integrating this? You can't integrate two separate PRs for the same bug ID, so if you want to integrate them separately, then you will need two different bug IDs; that might be best anyway, since I'm pretty sure you want the spec changes to go in separately and first. If you do intend to integrate this with as a single commit for a single bug ID, then you can make this PR as Draft and eventually fold it into the other PR. @prrace Can you comment as to how you want to proceed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13804#issuecomment-1535017332 From azvegint at openjdk.org Thu May 4 16:33:31 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 4 May 2023 16:33:31 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: On Thu, 4 May 2023 15:50:10 GMT, Kevin Rushforth wrote: >> This PR is to make it easier to review documentation changes from #13803 and also covers the following issues >> >> https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots >> https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor >> https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. >> https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures >> >> [Doc changes](https://github.com/openjdk/jdk/pull/13804/commits/bddf9683065175eba352f4a88806a7bed16f5e4c) are on top of #13803 > > @azvegint what is your plan for eventually integrating this? You can't integrate two separate PRs for the same bug ID, so if you want to integrate them separately, then you will need two different bug IDs; that might be best anyway, since I'm pretty sure you want the spec changes to go in separately and first. If you do intend to integrate this with as a single commit for a single bug ID, then you can make this PR as Draft and eventually fold it into the other PR. > > @prrace Can you comment as to how you want to proceed? @kevinrushforth thanks for your suggestions. I do not plan to integrate this PR, I would like to first discuss all questions regarding the documentation here, separately, and add the final version to the main PR #13803 > If you do intend to integrate this with as a single commit for a single bug ID, then you can make this PR as Draft and eventually fold it into the other PR. I created a new draft PR for this #13809. This PR got polluted with "tab to spaces" changes, hence closing it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13804#issuecomment-1535047461 From azvegint at openjdk.org Thu May 4 16:33:33 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 4 May 2023 16:33:33 GMT Subject: Withdrawn: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: <-XPMo2jucl2kkPDcctmwgtKLPEK5LnhFJ1K9vIiGHFY=.93dacd47-4a00-4074-817f-66d270346208@github.com> On Thu, 4 May 2023 14:20:30 GMT, Alexander Zvegintsev wrote: > This PR is to make it easier to review documentation changes from #13803 and also covers the following issues > > https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots > https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor > https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. > https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures > > [Doc changes](https://github.com/openjdk/jdk/pull/13804/commits/bddf9683065175eba352f4a88806a7bed16f5e4c) are on top of #13803 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13804 From prr at openjdk.org Thu May 4 16:46:22 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 4 May 2023 16:46:22 GMT Subject: RFR: 8307132: Cleanup the code of sun.java2d.cmm.lcms package In-Reply-To: <92zysAQG9gAswvFcNm9RXTHtSe-rJDTNV-NNEGF0egM=.8ab6d539-1218-402c-b244-85460207ce71@github.com> References: <_LRz2K4G7ZNjIO9C_5z2N9xWTfz25uUtRmefY2FRfkA=.d111a3fc-4264-43fb-a238-dc7129c61506@github.com> <9mMbcu9aJE_XKmjHNtBkWeUf-pwQ_59XYQvVPSpu8Ps=.fb521168-9b18-4eb1-a171-f62556f927b9@github.com> <92zysAQG9gAswvFcNm9RXTHtSe-rJDTNV-NNEGF0egM=.8ab6d539-1218-402c-b244-85460207ce71@github.com> Message-ID: On Thu, 4 May 2023 06:15:12 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/native/liblcms/LCMS.c line 51: >> >>> 49: #define DT_BYTE sun_java2d_cmm_lcms_LCMSImageLayout_DT_BYTE >>> 50: #define DT_SHORT sun_java2d_cmm_lcms_LCMSImageLayout_DT_SHORT >>> 51: #define DT_INT sun_java2d_cmm_lcms_LCMSImageLayout_DT_INT >> >> I don't understand why this isn't a step backwards. >> It is overloading the "size" to mean the "type" >> How would you tell the difference between SHORT vs UNSIGNED SHORT - both 2 bytes, >> or INT vs FLOAT - both 4 bytes ? >> or LONG vs DOUBLE .. >> If we ever need to, then this all needs to be reverted. >> % cd java/lang >> % grep BYTES *java >> Byte.java: public static final int BYTES = SIZE / Byte.SIZE; >> Character.java: public static final int BYTES = SIZE / Byte.SIZE; >> Double.java: public static final int BYTES = SIZE / Byte.SIZE; >> Float.java: public static final int BYTES = SIZE / Byte.SIZE; >> Integer.java: public static final int BYTES = SIZE / Byte.SIZE; >> Long.java: public static final int BYTES = SIZE / Byte.SIZE; >> Short.java: public static final int BYTES = SIZE / Byte.SIZE; > > right, the idea was to use one variable to select the supported type using its size. > Based on size we will switch what GetXXArrayElements to use. java right now supports these related functions: > > GetByteArrayElements, > GetShortArrayElements, > GetIntArrayElements, > GetLongArrayElements, > GetFloatArrayElements, > GetDoubleArrayElements, > > The images based on long format currently are not supported by java2d and lcms. And the "float" formats are really slow in LCMS as mentioned in the description. > >>How would you tell the difference between SHORT vs UNSIGNED SHORT - both 2 bytes, > > Both will use the same code path. > > But I can switch this to using two different variables for type and size. I'd prefer that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13732#discussion_r1185263336 From prr at openjdk.org Thu May 4 16:47:28 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 4 May 2023 16:47:28 GMT Subject: Integrated: 8307133: Open source some JTable jtreg tests In-Reply-To: References: Message-ID: On Mon, 1 May 2023 21:11:14 GMT, Phil Race wrote: > Open source some Swing JTable tests This pull request has now been integrated. Changeset: 5ca0b08a Author: Phil Race URL: https://git.openjdk.org/jdk/commit/5ca0b08a7505d5c210d906e76c2a4cfc3eed64aa Stats: 486 lines in 9 files changed: 486 ins; 0 del; 0 mod 8307133: Open source some JTable jtreg tests Reviewed-by: serb ------------- PR: https://git.openjdk.org/jdk/pull/13745 From aivanov at openjdk.org Thu May 4 17:11:24 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 May 2023 17:11:24 GMT Subject: RFR: 6176679: Application freezes when copying an animated gif image to the system clipboard [v13] In-Reply-To: References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> Message-ID: <1fVo5BlDCv-1foybJ-2mklChUOJM0gFfh9J4lNjZUZ0=.ae9c75b1-8d9c-4cfd-870e-bb8ee3537e3a@github.com> On Wed, 3 May 2023 03:36:25 GMT, Rajat Mahajan wrote: >> **Problem:** >> >> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time. >> Due to this infinite wait the application freezes. >> >> **Proposed Fix:** >> >> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. >> After this change I see the GIF image being correctly copied and animated. >> >> >> **Testing:** >> >> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > make code changes suggested by reviewers Looks good to me now. You have to address the trailing whitespace error too. test/jdk/java/awt/Clipboard/CopyAnimatedGIFTest.java line 106: > 104: > 105: robot.waitForIdle(); > 106: robot.delay(1000); Robot is needed only when UI is displayed, so it could be moved inside the `if (isImageDisplayed)` block. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13414#pullrequestreview-1413537844 PR Review Comment: https://git.openjdk.org/jdk/pull/13414#discussion_r1185287383 From rmahajan at openjdk.org Thu May 4 17:36:33 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Thu, 4 May 2023 17:36:33 GMT Subject: RFR: 6176679: Application freezes when copying an animated gif image to the system clipboard [v14] In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> Message-ID: > **Problem:** > > On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time. > Due to this infinite wait the application freezes. > > **Proposed Fix:** > > There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. > After this change I see the GIF image being correctly copied and animated. > > > **Testing:** > > Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: code cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13414/files - new: https://git.openjdk.org/jdk/pull/13414/files/c78d77cb..92ace819 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13414&range=12-13 Stats: 9 lines in 2 files changed: 3 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13414/head:pull/13414 PR: https://git.openjdk.org/jdk/pull/13414 From aivanov at openjdk.org Thu May 4 17:42:20 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 May 2023 17:42:20 GMT Subject: RFR: 6176679: Application freezes when copying an animated gif image to the system clipboard [v14] In-Reply-To: References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> Message-ID: <27NyvtTfpgzJtjZS9kodEQiqMtCD-_Wq73FvPKeRpXA=.31cebe39-77e2-47c1-89e4-11791eeca8bf@github.com> On Thu, 4 May 2023 17:36:33 GMT, Rajat Mahajan wrote: >> **Problem:** >> >> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time. >> Due to this infinite wait the application freezes. >> >> **Proposed Fix:** >> >> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. >> After this change I see the GIF image being correctly copied and animated. >> >> >> **Testing:** >> >> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > code cleanup Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13414#pullrequestreview-1413589202 From aturbanov at openjdk.org Thu May 4 18:24:31 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 May 2023 18:24:31 GMT Subject: RFR: 8307091: A few client tests intermittently throw ConcurrentModificationException [v2] In-Reply-To: References: Message-ID: On Thu, 4 May 2023 04:57:11 GMT, Tejesh R wrote: >> Few test are throwing Concurrent Modification Exception Intermittently. Since the issue is intermittent and from the log and code review, It is found that the shared variable `fileCache` is used in comparison with the `newFileCache` where the comparison invokes the iterator method in AbstractList class. Since based on vector documentation it was evident that listIterator are fail-fast iterators and hence it would be better to make a separate local copy of vectors for comparing operations. >> The same is implemented and tested in CI system which shows green. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 365: > 363: > 364: if (start >= 0 && end > start) { > 365: List listStart_OldSize = new Vector<>(fileCache.subList(start, oldSize)); Why Vector was used instead of ArrayList ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13783#discussion_r1185358653 From sgehwolf at openjdk.org Thu May 4 19:15:15 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 4 May 2023 19:15:15 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> References: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> Message-ID: On Thu, 4 May 2023 09:40:31 GMT, Paul Woegerer wrote: >> GraalVM native-image has it's own `libjvm.a` shim which would likely conflict or produce undesirable results. So I'd prefer the approach where `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For new uses-cases needing that, we could add a new top-level target (like `graal-builder-image`) which would produce such an image. As one of the [Mandrel](https://github.com/graalvm/mandrel) maintainers, I'm not sure any post-build filtering via `jlink` or the like would be ideal for us. I'll see if I can test this on a mandrel build tomorrow... > > As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. > > Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. > [...] I'll see if I can test this on a mandrel build tomorrow... @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1185416553 From jiangli at openjdk.org Thu May 4 19:25:18 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 4 May 2023 19:25:18 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: References: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> Message-ID: On Thu, 4 May 2023 19:12:14 GMT, Severin Gehwolf wrote: >> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. >> >> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. > >> [...] I'll see if I can test this on a mandrel build tomorrow... > > @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you? @jerboaa Thanks very much for testing with mandrel. Based on yours and @olpaw's feedback, I'll refactor this PR to not use the existing `static-libs-image` target for including hotspot `libjvm.a`. I'll also reflect that in the bug & PR titles as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1185426052 From jiangli at openjdk.org Thu May 4 19:35:39 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 4 May 2023 19:35:39 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: References: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> Message-ID: On Thu, 4 May 2023 19:12:14 GMT, Severin Gehwolf wrote: >> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. >> >> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. > >> [...] I'll see if I can test this on a mandrel build tomorrow... > > @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you? > As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. > > Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. @olpaw Thanks for the input. Could you also please take a look of the changes that excludes the object files from the following static libraries from Graal native image usage perspective? - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled. - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1185436692 From rmahajan at openjdk.org Thu May 4 19:38:15 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Thu, 4 May 2023 19:38:15 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Tue, 2 May 2023 15:05:23 GMT, Alexey Ivanov wrote: >> Problem: >> >> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: >> >> - Scrawly ticks in checkboxes; >> - Wrong circle relations in selected radio buttons. >> >> Root-cause: >> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. >> Due to this when the app window goes to Secondary Screen with different DPI UI buttons >> appear incorrectly rendered. >> Following is a list proposed changes to fix this issue. >> >> >> Proposed Fix with Summary of changes: >> >> 1. Open a new Theme Handle per the DPI of the Screen where the App window is. >> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. >> window is. >> >> 2. GetPartSize() of icons returns size based on standard size = 96 DPI. >> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. >> >> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. >> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. >> >> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. >> --> This helps make sure that for .25s scaling we get better rendering. >> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. >> >> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. >> >> >> Testing: >> >> Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. >> >> ___________________________________ >> Monitor 1 | Monitor 2 >> (Primary) | >> | >> 125% | 175% >> 150% | 175% >> 150% | 225% >> 175% | 175% >> 175% | 150% >> 175% | 225% >> _____________________ |_____________ >> >> Also tested on setup with scaling values of up-to 350%. > > src/java.desktop/share/classes/sun/swing/CachedPainter.java line 318: > >> 316: public Image getResolutionVariant(double destWidth, double destHeight) { >> 317: int w = (int) Math.floor(destWidth + 0.5); >> 318: int h = (int) Math.floor(destHeight + 0.5); > > Isn't it what `Region.clipRound` does? No, Region.clipRound does something little different than what I intend to do in this code . It works same as my code for 0.25 and 0.75 case. But not for 0.5 case. For example in case of destwidth and destHeight = 19.5, for my current code I see them rounded to 20, while with clipRound it is rounded to 19. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1185438958 From erikj at openjdk.org Thu May 4 19:59:17 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 4 May 2023 19:59:17 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: <_cTykE_ylL_s6FEZD-whKcVLZHtoca25nQ07DJg3zbc=.9107511d-1770-4259-8465-ae1998e0aba6@github.com> On Thu, 4 May 2023 14:18:44 GMT, Alexander Zvegintsev wrote: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens or some of them. For screens without permission there will be a black image. > + If the user wishes to change their mind about the screens allowed to be captured, the user should use the new `Robot#resetScreenCapturePermission` method > > Also added several system properties: > `awt.robot.screencastEnabled` false by default, uses the ScreenCast API if true > `awt.robot.screencastDebug` false by default, prints some debug information if true > > For convenience, this change is divided into two commits: > 1. added [pipewire headers](https://gitlab.freedesktop.org/pipewire/pipewire/) that are needed for the build > 2. main changes > > Changes in the documentation are in a separate draft PR (#13809) also for convenience. > > At the moment, the planned supported systems are Ubuntu 22.04+, the latest Oracle Linux 9.1 and RHEL 9.1 has some issues with restore_token support. I would like to understand why we need to add third party headers to our source tree. Are these not generally available on Linux systems? You say that the functionality isn't enabled by default, is that a runtime thing? It loos like it will be built unconditionally. make/modules/java.desktop/lib/Awt2dLibraries.gmk line 194: > 192: LIBAWT_XAWT_EXCLUDES := medialib debug > 193: > 194: BUILD_LIBPIPEWIRE_HEADER_DIRS := \ This variable name indicates that LIBPIPEWIRE is a library that we would build, but it seems to just be headers. I would suggest dropping the `BUILD_` prefix. ------------- PR Review: https://git.openjdk.org/jdk/pull/13803#pullrequestreview-1413812683 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185452739 From aturbanov at openjdk.org Thu May 4 20:20:14 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 May 2023 20:20:14 GMT Subject: RFR: JDK-8307381: Open Source JFrame, JIF related Swing Tests In-Reply-To: References: Message-ID: On Wed, 3 May 2023 20:58:00 GMT, Harshitha Onkar wrote: > Open sourced the following JFrame, JIF related Swing tests. > > > test/jdk/javax/swing/JFrame/bug4101444.java > test/jdk/javax/swing/JFrame/bug4208018.java > test/jdk/javax/swing/JInternalFrame/bug4308938.java > test/jdk/javax/swing/JInternalFrame/bug4320889.java > test/jdk/javax/swing/JTextField/bug4300552.java > test/jdk/javax/swing/JToggleButton/bug4277049.java > > > CI testing looks good. test/jdk/javax/swing/JToggleButton/bug4277049.java line 35: > 33: */ > 34: > 35: public class bug4277049 implements ItemListener { Suggestion: public class bug4277049 implements ItemListener { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13787#discussion_r1185473400 From prr at openjdk.org Thu May 4 20:25:18 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 4 May 2023 20:25:18 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: <_cTykE_ylL_s6FEZD-whKcVLZHtoca25nQ07DJg3zbc=.9107511d-1770-4259-8465-ae1998e0aba6@github.com> References: <_cTykE_ylL_s6FEZD-whKcVLZHtoca25nQ07DJg3zbc=.9107511d-1770-4259-8465-ae1998e0aba6@github.com> Message-ID: On Thu, 4 May 2023 19:56:21 GMT, Erik Joelsson wrote: > I would like to understand why we need to add third party headers to our source tree. Are these not generally available on Linux systems? They are not available on anything except very new Linux distros. Forget RHEL 6.x / 7.x. I'm fairly sure not 8.x either. RHEL/OL 9.x could an example of the earliest that would work to build without these imports. And that's just for building, even current 9.1 doesn't have sufficiently working runtime libs. There should be a fix for that in 9.2 .. Ubuntu 22.04 is however known to be OK. > You say that the functionality isn't enabled by default, is that a runtime thing? It loos like it will be built unconditionally. Yes, a runtime thing. An implementation System Property needs to be set. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1535363156 From aturbanov at openjdk.org Thu May 4 20:26:26 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 May 2023 20:26:26 GMT Subject: RFR: JDK-8307128: Open source some drag and drop tests 4 In-Reply-To: References: Message-ID: On Tue, 2 May 2023 22:09:18 GMT, Alisen Chung wrote: > added DnD tests test/jdk/java/awt/dnd/MozillaDnDTest.java line 97: > 95: } finally { > 96: EventQueue.invokeAndWait(() -> { > 97: if(test.frame != null) { Suggestion: if (test.frame != null) { test/jdk/java/awt/dnd/MozillaDnDTest.java line 347: > 345: // the variable finished is set to true. > 346: pres.exitValue = p.exitValue(); > 347: finished = true; Suggestion: finished = true; test/jdk/java/awt/dnd/MultiDataFlavorDropTest.java line 378: > 376: > 377: if (flavor.getRepresentationClass().equals(Integer.class)) { > 378: try{ Suggestion: try { test/jdk/java/awt/dnd/MultiDataFlavorDropTest.java line 380: > 378: try{ > 379: transferNumber = (Integer)t.getTransferData(flavor); > 380: } catch(Exception e) { Suggestion: } catch (Exception e) { test/jdk/java/awt/dnd/MultiDataFlavorDropTest.java line 390: > 388: for (int j = 0; j < TransferableNumber.NUM_DATA_FLAVORS; j++) { > 389: int number = (i + j) % TransferableNumber.NUM_DATA_FLAVORS; > 390: try{ Suggestion: try { test/jdk/java/awt/dnd/MultiDataFlavorDropTest.java line 400: > 398: break; > 399: } > 400: } catch(ClassNotFoundException cannotHappen) { Suggestion: } catch (ClassNotFoundException cannotHappen) { test/jdk/java/awt/dnd/NativeDragJavaDropTest.java line 140: > 138: DataFlavor[] dfs = dtde.getCurrentDataFlavors(); > 139: > 140: if(dfs != null && dfs.length >= 1) { Suggestion: if (dfs != null && dfs.length >= 1) { test/jdk/java/awt/dnd/NestedHeavyweightDropTargetTest.java line 478: > 476: Component comp = null; > 477: > 478: if(dfs != null && dfs.length >= 1) { Suggestion: if (dfs != null && dfs.length >= 1) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13765#discussion_r1185477231 PR Review Comment: https://git.openjdk.org/jdk/pull/13765#discussion_r1185477419 PR Review Comment: https://git.openjdk.org/jdk/pull/13765#discussion_r1185477864 PR Review Comment: https://git.openjdk.org/jdk/pull/13765#discussion_r1185477973 PR Review Comment: https://git.openjdk.org/jdk/pull/13765#discussion_r1185478088 PR Review Comment: https://git.openjdk.org/jdk/pull/13765#discussion_r1185478199 PR Review Comment: https://git.openjdk.org/jdk/pull/13765#discussion_r1185478362 PR Review Comment: https://git.openjdk.org/jdk/pull/13765#discussion_r1185477637 From aturbanov at openjdk.org Thu May 4 20:27:21 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 May 2023 20:27:21 GMT Subject: RFR: JDK-8307083: Open source some drag and drop tests 3 In-Reply-To: References: Message-ID: On Tue, 2 May 2023 21:53:59 GMT, Alisen Chung wrote: > moving tests to open test/jdk/java/awt/dnd/MissedDragEnterTest.java line 234: > 232: Component comp = null; > 233: > 234: if(dfs != null && dfs.length >= 1) { Suggestion: if (dfs != null && dfs.length >= 1) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13764#discussion_r1185478691 From honkar at openjdk.org Thu May 4 20:27:48 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 4 May 2023 20:27:48 GMT Subject: RFR: JDK-8307381: Open Source JFrame, JIF related Swing Tests [v2] In-Reply-To: References: Message-ID: <_2YqwfjaUIo1OEtvF8BqCgZtaGoaElJ2e9hzEa4dRdQ=.7459421d-d19a-4829-a39c-c25c0de16c26@github.com> > Open sourced the following JFrame, JIF related Swing tests. > > > test/jdk/javax/swing/JFrame/bug4101444.java > test/jdk/javax/swing/JFrame/bug4208018.java > test/jdk/javax/swing/JInternalFrame/bug4308938.java > test/jdk/javax/swing/JInternalFrame/bug4320889.java > test/jdk/javax/swing/JTextField/bug4300552.java > test/jdk/javax/swing/JToggleButton/bug4277049.java > > > CI testing looks good. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: removed extra space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13787/files - new: https://git.openjdk.org/jdk/pull/13787/files/196b9c11..71d7b273 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13787&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13787&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13787/head:pull/13787 PR: https://git.openjdk.org/jdk/pull/13787 From aturbanov at openjdk.org Thu May 4 20:28:20 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 May 2023 20:28:20 GMT Subject: RFR: 8307299: Move more DnD tests to open [v3] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 21:07:21 GMT, Alisen Chung wrote: >> Added DnD tests > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > moved some function calls on EDT test/jdk/java/awt/dnd/DroppingVMHangTest.java line 98: > 96: } finally { > 97: EventQueue.invokeAndWait(() -> { > 98: if(test.frame != null) { Suggestion: if (test.frame != null) { test/jdk/java/awt/dnd/InterJVMLinkTest.java line 85: > 83: } finally { > 84: EventQueue.invokeAndWait(() -> { > 85: if(test.frame != null) { Suggestion: if (test.frame != null) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13759#discussion_r1185479410 PR Review Comment: https://git.openjdk.org/jdk/pull/13759#discussion_r1185479614 From honkar at openjdk.org Thu May 4 20:28:06 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 4 May 2023 20:28:06 GMT Subject: RFR: JDK-8307381: Open Source JFrame, JIF related Swing Tests In-Reply-To: References: Message-ID: On Thu, 4 May 2023 05:49:51 GMT, Sergey Bylokhov wrote: > Looks like the JBS issue is confidential: ?? Temporary failure when trying to retrieve information on issue JDK-8307381 @mrserb Looks to be resolved now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13787#issuecomment-1535366244 From aturbanov at openjdk.org Thu May 4 20:31:20 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 4 May 2023 20:31:20 GMT Subject: RFR: 8307297: Move some DnD tests to open [v2] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 20:57:28 GMT, Alisen Chung wrote: >> Adding some DnD tests > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > added space after if, moved some function calls on EDT test/jdk/java/awt/dnd/DropPerformanceTest.java line 237: > 235: Object ret = null; > 236: ByteArrayOutputStream baos = new ByteArrayOutputStream(); > 237: ObjectOutputStream oos = new ObjectOutputStream(baos); Suggestion: ObjectOutputStream oos = new ObjectOutputStream(baos); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13756#discussion_r1185480708 From kizune at openjdk.org Thu May 4 20:32:17 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 4 May 2023 20:32:17 GMT Subject: RFR: 8303830: update for deprecated sprintf for jdk.accessibility In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 18:20:47 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the jdk.accessibility module. > > Thanks, > Xuelei I tested this change on Windows using JAWS and built in jaccesswalker and jaccessinspector and found no problems caused by this change. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12929#pullrequestreview-1413859880 From dcubed at openjdk.org Thu May 4 21:13:37 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 4 May 2023 21:13:37 GMT Subject: RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 Message-ID: Trivial fixes to ProblemList a few tests: - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 ------------- Commit messages: - get rid of extra blank line. - 8307491: ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 - 8307490: ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 - 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 Changes: https://git.openjdk.org/jdk/pull/13816/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13816&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307489 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13816.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13816/head:pull/13816 PR: https://git.openjdk.org/jdk/pull/13816 From darcy at openjdk.org Thu May 4 21:24:14 2023 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 4 May 2023 21:24:14 GMT Subject: RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 In-Reply-To: References: Message-ID: On Thu, 4 May 2023 20:49:26 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a few tests: > - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 > - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 > - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13816#pullrequestreview-1413942638 From xuelei at openjdk.org Thu May 4 21:25:17 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 4 May 2023 21:25:17 GMT Subject: RFR: 8303830: update for deprecated sprintf for jdk.accessibility In-Reply-To: References: Message-ID: <-aOTe5fb37_zD1LDT6QAGsjFPXtItz_b2du67bIYuyg=.920b37fe-5c49-4621-bfec-85f3795f9fb2@github.com> On Sat, 29 Apr 2023 08:29:39 GMT, Alexander Zuev wrote: >> Hi, >> >> May I have this update reviewed? >> >> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the jdk.accessibility module. >> >> Thanks, >> Xuelei > > The problem with testing of this code is that a lot of it (if not all) is inside the debug and logging part, which means that not only library should be loaded (doable) and the debug is on (also doable) but some of that code is just an error report and in order to cause system to misbehave enough to cause such error is not trivial. Looking into it though. @azuev-java Thank you very much for helping the testing. Are two reviewers required for client lib PR review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/12929#issuecomment-1535431609 From dcubed at openjdk.org Thu May 4 21:35:39 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 4 May 2023 21:35:39 GMT Subject: RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 In-Reply-To: References: Message-ID: On Thu, 4 May 2023 21:21:38 GMT, Joe Darcy wrote: >> Trivial fixes to ProblemList a few tests: >> - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 >> - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 >> - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 > > Marked as reviewed by darcy (Reviewer). @jddarcy - Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13816#issuecomment-1535438955 From dcubed at openjdk.org Thu May 4 21:35:40 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 4 May 2023 21:35:40 GMT Subject: Integrated: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 In-Reply-To: References: Message-ID: On Thu, 4 May 2023 20:49:26 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a few tests: > - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 > - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 > - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 This pull request has now been integrated. Changeset: 111858f3 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/111858f3ff86a15666537df515375fa04ffef048 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64 8307490: ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64 8307491: ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64 Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk/pull/13816 From dnguyen at openjdk.org Thu May 4 22:43:19 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 4 May 2023 22:43:19 GMT Subject: RFR: 8307165: java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java timed out [v2] In-Reply-To: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> References: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> Message-ID: > When converting this test to be applicable to be open sourced, changes were made. I reverted some of these changes to get the test stable again. Now it passes when run on various OS's 100x. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Re-add certain lines. Make passed volatile. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13761/files - new: https://git.openjdk.org/jdk/pull/13761/files/e26797e1..6273c12c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13761&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13761&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13761.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13761/head:pull/13761 PR: https://git.openjdk.org/jdk/pull/13761 From dnguyen at openjdk.org Thu May 4 23:31:14 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 4 May 2023 23:31:14 GMT Subject: RFR: 8307165: java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java timed out [v3] In-Reply-To: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> References: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> Message-ID: <73UVaqsv0RLw8QiM-sHXx6xd3fVeDtGu4-p_5BQp_iU=.bc9c12ca-5a82-4a4f-9a70-ea420bdf0107@github.com> > When converting this test to be applicable to be open sourced, changes were made. I reverted some of these changes to get the test stable again. Now it passes when run on various OS's 100x. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert some more changes since irrelevant. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13761/files - new: https://git.openjdk.org/jdk/pull/13761/files/6273c12c..34c649b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13761&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13761&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13761.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13761/head:pull/13761 PR: https://git.openjdk.org/jdk/pull/13761 From serb at openjdk.org Thu May 4 23:47:21 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 May 2023 23:47:21 GMT Subject: RFR: 8307132: Cleanup the code of sun.java2d.cmm.lcms package [v2] In-Reply-To: <_LRz2K4G7ZNjIO9C_5z2N9xWTfz25uUtRmefY2FRfkA=.d111a3fc-4264-43fb-a238-dc7129c61506@github.com> References: <_LRz2K4G7ZNjIO9C_5z2N9xWTfz25uUtRmefY2FRfkA=.d111a3fc-4264-43fb-a238-dc7129c61506@github.com> Message-ID: > The description from big to small: > > - Our code to handle the image types we support is too generic, the LCMSImageLayout class can handle, byte, short, int, and double types, and many various properties of the image layout. As a result, we pass a couple of good parameters to the LCMSImageLayout and have to use safeXX methods in it to calculate the final layout, and then validate it. > This patch moves the layout properties calculation to one place - the constructor of LCMSImageLayout, and from the outside of the class, we now pass only the data array and the number of components per pixel: > - The usage of Double type is removed, we do not use that type currently, and do not plan to support it in the future. Note that we support the float type, and I tried to implement it, but unfortunately, it is [intentionally ](https://github.com/mm2/Little-CMS/issues/356)slow. So will continue to use short type instead of float. > - Discussed a few times the `do { } while (false);` block is removed. Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: split type and size ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13732/files - new: https://git.openjdk.org/jdk/pull/13732/files/d91e8706..fcf3bcbc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13732&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13732&range=00-01 Stats: 19 lines in 1 file changed: 9 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13732.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13732/head:pull/13732 PR: https://git.openjdk.org/jdk/pull/13732 From dnguyen at openjdk.org Fri May 5 00:24:14 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 5 May 2023 00:24:14 GMT Subject: RFR: 8307165: java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java timed out In-Reply-To: References: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> Message-ID: <7tR2yzXNsG5vnFltTghybMEopknIw8Cwx3_84k0xhGw=.aa3c1fbc-25dd-4217-b4ac-9027ac9ffdd3@github.com> On Wed, 3 May 2023 19:54:46 GMT, Phil Race wrote: > The delay -> sleep changes really are no-ops .. except one you made shorter .. And the calls like validate() seem OK .. Do you have any explanation as to why these changes fix the time out ? The original test had this shorter delay, so I experimented with reverting the change here. After your suggestion to make ```passed``` volatile, the test passes on windows. The original intermittent failure due to timeout seems to have been caused by the setAutoWaitForIdle() call. On my local machine, this line causes the test to take much longer to start for some reason. After removing this, the test consistently passes on 100 repeat runs of the test on all OS's except Windows. Windows fails intermittently as well, but changing the ```passed``` var to volatile fixes this. Now all OS's are passing 100 repeat runs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13761#issuecomment-1535552643 From dnguyen at openjdk.org Fri May 5 00:24:19 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 5 May 2023 00:24:19 GMT Subject: RFR: 8307165: java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java timed out [v3] In-Reply-To: References: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> Message-ID: On Wed, 3 May 2023 21:43:39 GMT, Harshitha Onkar wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert some more changes since irrelevant. > > test/jdk/java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java line 97: > >> 95: frame.getToolkit().addAWTEventListener(this, AWTEvent.MOUSE_EVENT_MASK); >> 96: frame.pack(); >> 97: frame.setLocationRelativeTo(null); > > It would be better to retain `frame.setLocationRelativeTo(null)` since you are calling `getLocationOnScreen()` later on. I have restored the line > test/jdk/java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java line 104: > >> 102: try { >> 103: Robot robot = new Robot(); >> 104: Thread.sleep(FRAME_ACTIVATION_TIMEOUT); > > Curious to know the difference of using `Thread.sleep()` instead of `robot.delay()` here ? Initially, I thought ```Thread.sleep``` may have been the cause since there are some synchronization lines. But, I think robot.delay does the same behavior here. So, to keep the modern test format, I reverted this to robot.delay ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13761#discussion_r1185617342 PR Review Comment: https://git.openjdk.org/jdk/pull/13761#discussion_r1185617608 From dnguyen at openjdk.org Fri May 5 00:27:15 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 5 May 2023 00:27:15 GMT Subject: RFR: JDK-8307381: Open Source JFrame, JIF related Swing Tests [v2] In-Reply-To: <_2YqwfjaUIo1OEtvF8BqCgZtaGoaElJ2e9hzEa4dRdQ=.7459421d-d19a-4829-a39c-c25c0de16c26@github.com> References: <_2YqwfjaUIo1OEtvF8BqCgZtaGoaElJ2e9hzEa4dRdQ=.7459421d-d19a-4829-a39c-c25c0de16c26@github.com> Message-ID: On Thu, 4 May 2023 20:27:48 GMT, Harshitha Onkar wrote: >> Open sourced the following JFrame, JIF related Swing tests. >> >> >> test/jdk/javax/swing/JFrame/bug4101444.java >> test/jdk/javax/swing/JFrame/bug4208018.java >> test/jdk/javax/swing/JInternalFrame/bug4308938.java >> test/jdk/javax/swing/JInternalFrame/bug4320889.java >> test/jdk/javax/swing/JTextField/bug4300552.java >> test/jdk/javax/swing/JToggleButton/bug4277049.java >> >> >> CI testing looks good. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > removed extra space Marked as reviewed by dnguyen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13787#pullrequestreview-1414069082 From prr at openjdk.org Fri May 5 01:11:21 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 5 May 2023 01:11:21 GMT Subject: RFR: 8307165: java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java timed out [v3] In-Reply-To: <73UVaqsv0RLw8QiM-sHXx6xd3fVeDtGu4-p_5BQp_iU=.bc9c12ca-5a82-4a4f-9a70-ea420bdf0107@github.com> References: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> <73UVaqsv0RLw8QiM-sHXx6xd3fVeDtGu4-p_5BQp_iU=.bc9c12ca-5a82-4a4f-9a70-ea420bdf0107@github.com> Message-ID: On Thu, 4 May 2023 23:31:14 GMT, Damon Nguyen wrote: >> When converting this test to be applicable to be open sourced, changes were made. I reverted some of these changes to get the test stable again. Now it passes when run on various OS's 100x. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert some more changes since irrelevant. OK. These changes should improve things. Let's push it and see. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13761#pullrequestreview-1414087066 From serb at openjdk.org Fri May 5 02:40:12 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 5 May 2023 02:40:12 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: On Thu, 4 May 2023 14:18:44 GMT, Alexander Zvegintsev wrote: > If the user wishes to change their mind about the screens allowed to be captured, the user should use the new Robot#resetScreenCapturePermission method Do we really need to add this new API? probably we can implement the feature w/o this new method? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1535626183 From abhiscxk at openjdk.org Fri May 5 05:04:34 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 5 May 2023 05:04:34 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests Message-ID: This PR is to open source JMenuItem related swing tests. ------------- Commit messages: - Open Source Swing JMenuItem Tests Changes: https://git.openjdk.org/jdk/pull/13822/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13822&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306996 Stats: 447 lines in 4 files changed: 447 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13822/head:pull/13822 PR: https://git.openjdk.org/jdk/pull/13822 From itakiguchi at openjdk.org Fri May 5 05:06:14 2023 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Fri, 5 May 2023 05:06:14 GMT Subject: RFR: 6928542: Chinese characters in RTF are not decoded In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 05:47:35 GMT, Ichiroh Takiguchi wrote: > "character set of font" (font charset) table was created by "Rich Text Format Specification 1.9.1" > https://interoperability.blob.core.windows.net/files/Archive_References/[MSFT-RTF].pdf > It refers windgi.h > https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-textmetrica > > Test files and testcase are in bugid [JDK-6928542](https://bugs.openjdk.org/browse/JDK-6928542) > > Additional change: > Special character `\line` should `\n` > > **Note:** Following GitHub actions were failed > linux-x86 / test (jdk/tier1 part 1) was failed, it seems it was already reported >> [JDK-8305875](https://bugs.openjdk.org/browse/JDK-8305875) Test TraceVirtualThreadLocals should be run with continuations only > > windows-aarch64 / build (debug) was failed, but I have no idea... Gentle reminder, could you give your suggestions ? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13553#issuecomment-1535698838 From tr at openjdk.org Fri May 5 05:28:24 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 5 May 2023 05:28:24 GMT Subject: RFR: 8307091: A few client tests intermittently throw ConcurrentModificationException [v2] In-Reply-To: References: Message-ID: On Thu, 4 May 2023 18:20:58 GMT, Andrey Turbanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 365: > >> 363: >> 364: if (start >= 0 && end > start) { >> 365: List listStart_OldSize = new Vector<>(fileCache.subList(start, oldSize)); > > Why Vector was used instead of ArrayList ? Nothing specific reason why I choose vector apart from the main object is of Vector type and since in this context (where both the objects are not shared) both Vector/Arraylist comparison remains same. Does Arraylist comparison has any advantage here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13783#discussion_r1185710608 From dmarkov at openjdk.org Fri May 5 09:46:26 2023 From: dmarkov at openjdk.org (Dmitry Markov) Date: Fri, 5 May 2023 09:46:26 GMT Subject: RFR: 6176679: Application freezes when copying an animated gif image to the system clipboard [v14] In-Reply-To: References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> Message-ID: On Thu, 4 May 2023 17:36:33 GMT, Rajat Mahajan wrote: >> **Problem:** >> >> On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time. >> Due to this infinite wait the application freezes. >> >> **Proposed Fix:** >> >> There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. >> After this change I see the GIF image being correctly copied and animated. >> >> >> **Testing:** >> >> Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > code cleanup Marked as reviewed by dmarkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13414#pullrequestreview-1414476234 From tr at openjdk.org Fri May 5 10:02:37 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 5 May 2023 10:02:37 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests Message-ID: Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. ------------- Commit messages: - Open source few Applet test - Open source few Applet test Changes: https://git.openjdk.org/jdk/pull/13828/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13828&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306812 Stats: 542 lines in 5 files changed: 542 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13828.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13828/head:pull/13828 PR: https://git.openjdk.org/jdk/pull/13828 From mkartashev at openjdk.org Fri May 5 10:55:21 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Fri, 5 May 2023 10:55:21 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: <1ZGirSGimyAgLdQ_kmia0mw1qnFaY7_5N5xeDxET4DE=.7d5b9a18-ef76-4078-beeb-756f9afde420@github.com> On Thu, 4 May 2023 14:18:44 GMT, Alexander Zvegintsev wrote: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens or some of them. For screens without permission there will be a black image. > + If the user wishes to change their mind about the screens allowed to be captured, the user should use the new `Robot#resetScreenCapturePermission` method > > Also added several system properties: > `awt.robot.screencastEnabled` false by default, uses the ScreenCast API if true > `awt.robot.screencastDebug` false by default, prints some debug information if true > > For convenience, this change is divided into two commits: > 1. added [pipewire headers](https://gitlab.freedesktop.org/pipewire/pipewire/) that are needed for the build > 2. main changes > > Changes in the documentation are in a separate draft PR (#13809) also for convenience. > > At the moment, the planned supported systems are Ubuntu 22.04+, the latest Oracle Linux 9.1 and RHEL 9.1 has some issues with restore_token support. src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java line 428: > 426: > 427: @SuppressWarnings("removal") > 428: public static boolean isOnWayland() { It seems that this method doesn't have to part of a public interface of `UNIXToolkit`. src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 56: > 54: } > 55: > 56: private static final int DENIED = -11; //defined in native code The comment is confusing as the field is defined right here, not in native code. src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 58: > 56: private static final int DENIED = -11; //defined in native code > 57: > 58: private static synchronized native int getRGBPixelsImpl( Is `synchronized` really needed on the declaration of `getRGBPixelsImpl()`? src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 50: > 48: jmethodID storeTokenMethodID = NULL; > 49: > 50: inline void debug_screencast( Does this one need to be externally visible? If not, it can be (also) made `static`. src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 138: > 136: } > 137: > 138: static inline void convertRGBxToBGRx(int* in) { Will this work correctly on little-endian ARM systems? src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 602: > 600: } > 601: > 602: pipewire_libhandle = dlopen("libpipewire-0.3.so.0", There's a useful macro for wrapping library names: `VERSIONED_JNI_LIB_NAME("pipewire-0.3", "0")` src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 722: > 720: > 721: const gchar *token = jtoken > 722: ? token = (*env)->GetStringUTFChars(env, jtoken, NULL) The variable `token` is unnecessarily used in its own initializer here. src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 789: > 787: env, pixelArray, > 788: start, len, > 789: ((jint *) screenProps->captureData) I'm not sure if endianness of `captureData` matches the expected endianness of `pixelArray`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185887472 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185891793 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185894200 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185907122 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185917587 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185942008 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185946946 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1185951908 From azvegint at openjdk.org Fri May 5 12:34:12 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 5 May 2023 12:34:12 GMT Subject: RFR: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland Message-ID: On Linux systems, we rely on XGrabPointer (X11 API) to capture mouse input and dismiss popup menus on mouse clicks outside the popup menu. Unfortunately, on Linux systems using the [Wayland](https://wayland.freedesktop.org/) session this only works inside [XWayland(Wayland's X11 server implementation)](https://wayland.freedesktop.org/xserver.html). This means if a user clicks on a part of the screen not controlled by XWayland (e.g. window decorations, other non X11 applications) the popup menu will not be hidden. As a workaround, we can hide this menu when the parent popup menu window loses focus. However, it does have its drawbacks, which should be described in the documentation.The focus does not change when clicking on the header of its own parent window or on non-focusable windows, .e.g., empty space in system dock, so in this case the popup menu is not hidden. Third-party applications use a similar approach. I also have doubts about the need to change the documentation, as I can't find where it is described that the popup menu should be hidden when clicked outside the menu. CSR: https://bugs.openjdk.org/browse/JDK-8307529 ------------- Commit messages: - doc changes - actual fix - Wayland detection Changes: https://git.openjdk.org/jdk/pull/13830/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13830&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8280993 Stats: 195 lines in 6 files changed: 181 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/13830.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13830/head:pull/13830 PR: https://git.openjdk.org/jdk/pull/13830 From aivanov at openjdk.org Fri May 5 12:53:35 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 5 May 2023 12:53:35 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v6] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 16:00:39 GMT, Tejesh R wrote: >> Open source few AWT ScrollPane related tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Removed whitespace error Changes requested by aivanov (Reviewer). test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 42: > 40: import java.awt.event.AdjustmentListener; > 41: > 42: import java.lang.reflect.InvocationTargetException; `InvocationTargetException` is unused, remove unused imports, please. test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 72: > 70: @Override > 71: public void adjustmentValueChanged(AdjustmentEvent adjustmentEvent) { > 72: count++; IDE warns that we're changing a volatile field in a non-atomic fashion? but it's probably okay here. test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 87: > 85: }); > 86: > 87: Thread.sleep(5000); Sleeping for 5 seconds could be too much. It would be great to ensure the updated test reproduces the problem that was fixed by [JDK-4342129](https://bugs.openjdk.org/browse/JDK-4342129) in 1.3.0 and 1.4.0. Otherwise, these 5 seconds could be a waste of time. test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 52: > 50: > 51: public class ScrollPaneLimitation { > 52: final static int SCROLL_POS = 50000; Suggestion: static final int SCROLL_POS = 50000; Address the missorted modifiers. test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 91: > 89: lock.notify(); > 90: } > 91: } Suggestion: if (e.getID() == MouseEvent.MOUSE_PRESSED && e.getSource() == ScrollPaneLimitation.child && e.getY() > SCROLL_POS) { go.countDown(); } I meant replacing synchronisation with `lock` by `CountDownLatch`. You created a mix of them. (Here, I moved the first `&&` operator to wrapped line ? you should be consistent: either move binary operators to wrapped line or leave them on the previous line. test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 106: > 104: > 105: EventQueue.invokeAndWait(() -> { > 106: p = child.getLocation(); The synchronization here doesn't look correct. `p` is later used on main thread. It is safer to create a local variable inside the lambda expression, print the positions etc. As the last statement create a new `Point` instance with the computed coordinates for mouse click and assign it to `p` which will be used on the main thread to move the mouse cursor. It is not necessary to mark the field as `volatile` because `invokeAndWait` serves a the synchronisation point between the two thread. test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 144: > 142: if (!mouseWasPressed) { > 143: throw new RuntimeException("mouse was not pressed"); > 144: } Suggestion: if (!go.await(3, TimeUnit.SECONDS)) { throw new RuntimeException("mouse was not pressed"); } If mouse is clicked and the event is sent, the `go` reaches zero and `await` returns `true`; otherwise `await` returns `false` and the test fails. The `lock` and `mouseWasPressed` are to be removed. test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 39: > 37: import java.awt.Robot; > 38: import java.awt.ScrollPane; > 39: import java.awt.Toolkit; `BorderLayout` and `Toolkit` are unused, remove unused imports, please. test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 71: > 69: button.addActionListener(new ActionListener() { > 70: public void actionPerformed(ActionEvent e) { > 71: actionSema.raise(); The entire thing with a custom `Semaphore` is overly complicated and unnecessary. What it verifies is that the button is clicked, isn't it. Use the standard `CountDownLatch` for it. So, here it'll be: Suggestion: latch.countDown(); test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 111: > 109: throw new RuntimeException("ScrollPane doesn't handle " + > 110: "correctly add after remove"); > 111: } All this code will be as simple as this: Suggestion: if (!latch.await(1, TimeUnit.SECONDS)) { throw new RuntimeException("ScrollPane doesn't handle " + "correctly add after remove"); } No need to `waitForIdle` because the latch will be released only after the clicked event gets handled. Then remove the `Semaphore` class which is not implemented correctly. test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 98: > 96: > 97: robot.mouseMove(sp.getLocationOnScreen().x + sp.getWidth() - paneInsets.right / 2, > 98: sp.getLocationOnScreen().y + sp.getHeight() / 2); You should get the location on the scroll pane and its size inside `invokeAndWait` and use these two new fields to move the mouse. test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 174: > 172: } catch (InterruptedException e) { > 173: throw new RuntimeException("Test interrupted while keys being pressed.", e); > 174: } You can remove the try-catch block here, the throws clause in the method declaration allows throwing `InterruptedException`. Since this exception is unlikely to be thrown ever, the additional detail message isn't as useful. test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 178: > 176: > 177: public void adjustmentValueChanged(AdjustmentEvent e) { > 178: notifyReceived = true; `notifyReceived` should be modified and read inside `synchronized (ScrollPaneWindowsTest.LOCK)` block. test/jdk/java/awt/ScrollPane/ScrollPositionIntact.java line 74: > 72: robot.delay(1000); > 73: robot.waitForIdle(); > 74: EventQueue.invokeAndWait(() -> { Suggestion: }); Robot robot = new Robot(); robot.delay(1000); robot.waitForIdle(); EventQueue.invokeAndWait(() -> { Let's add blank lines to separate the code portions visually. ------------- PR Review: https://git.openjdk.org/jdk/pull/13621#pullrequestreview-1414573417 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1185984003 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1185994523 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1186039141 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1186052205 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1185957430 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1185966007 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1185961134 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1185984651 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1185986092 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1185988584 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1186046722 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1186051071 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1186048121 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1186056045 From mkartashev at openjdk.org Fri May 5 13:59:18 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Fri, 5 May 2023 13:59:18 GMT Subject: RFR: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland In-Reply-To: References: Message-ID: On Fri, 5 May 2023 12:27:04 GMT, Alexander Zvegintsev wrote: > I also have doubts about the need to change the documentation, as I can't find where it is described that the popup menu should be hidden when clicked outside the menu. FWIW, I agree that you only need to change the documentation if someone can actually point to where it says that popup hides when there's a mouse click outside its bounds. Otherwise the implementation notes seem to do more harm (by confusing the reader) than good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13830#issuecomment-1536300509 From ngubarkov at openjdk.org Fri May 5 14:00:44 2023 From: ngubarkov at openjdk.org (Nikita Gubarkov) Date: Fri, 5 May 2023 14:00:44 GMT Subject: RFR: 8269806: Emoji rendering on Linux [v20] In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 14:31:34 GMT, Nikita Gubarkov wrote: >> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR >> It includes: >> - Bitmap glyph loading via Freetype >> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint >> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs >> - Small fixes in related code like null-checks which could cause NPE & comment typos > > Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: > > EmojiFont CRLF -> LF ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/4798#issuecomment-1536301952 From alanb at openjdk.org Fri May 5 14:04:23 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 May 2023 14:04:23 GMT Subject: RFR: 8307194: Enhance static-libs-image [v5] In-Reply-To: References: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> Message-ID: On Thu, 4 May 2023 19:32:45 GMT, Jiangli Zhou wrote: >>> [...] I'll see if I can test this on a mandrel build tomorrow... >> >> @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you? > >> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. >> >> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. > > @olpaw Thanks for the input. Could you also please take a look of the changes that excludes the object files from the following static libraries from Graal native image usage perspective? > > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled. > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a. At first glance, static-libs-image create libjvm.a in the same directory as the other lib .a files make sense but I don't know how that works if --with-jvm-variants is used to create more more than one libjvm. Might have to think whether this combination make sense or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1186134127 From azvegint at openjdk.org Fri May 5 14:35:46 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 5 May 2023 14:35:46 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: References: Message-ID: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens or some of them. For screens without permission there will be a black image. > + If the user wishes to change their mind about the screens allowed to be captured, the user should use the new `Robot#resetScreenCapturePermission` method > > Also added several system properties: > `awt.robot.screencastEnabled` false by default, uses the ScreenCast API if true > `awt.robot.screencastDebug` false by default, prints some debug information if true > > For convenience, this change is divided into two commits: > 1. added [pipewire headers](https://gitlab.freedesktop.org/pipewire/pipewire/) that are needed for the build > 2. main changes > > Changes in the documentation are in a separate draft PR (#13809) also for convenience. > > At the moment, the planned supported systems are Ubuntu 22.04+, the latest Oracle Linux 9.1 and RHEL 9.1 has some issues with restore_token support. Alexander Zvegintsev has updated the pull request incrementally with three additional commits since the last revision: - update, based on review comments - remove wayland detection - BUILD_LIBPIPEWIRE_HEADER_DIRS -> LIBPIPEWIRE_HEADER_DIRS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/94fcd916..482471df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=00-01 Stats: 43 lines in 6 files changed: 0 ins; 37 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From azvegint at openjdk.org Fri May 5 14:35:47 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 5 May 2023 14:35:47 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: <1ZGirSGimyAgLdQ_kmia0mw1qnFaY7_5N5xeDxET4DE=.7d5b9a18-ef76-4078-beeb-756f9afde420@github.com> References: <1ZGirSGimyAgLdQ_kmia0mw1qnFaY7_5N5xeDxET4DE=.7d5b9a18-ef76-4078-beeb-756f9afde420@github.com> Message-ID: On Fri, 5 May 2023 09:33:00 GMT, Maxim Kartashev wrote: >> Alexander Zvegintsev has updated the pull request incrementally with three additional commits since the last revision: >> >> - update, based on review comments >> - remove wayland detection >> - BUILD_LIBPIPEWIRE_HEADER_DIRS -> LIBPIPEWIRE_HEADER_DIRS > > src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java line 428: > >> 426: >> 427: @SuppressWarnings("removal") >> 428: public static boolean isOnWayland() { > > It seems that this method doesn't have to part of a public interface of `UNIXToolkit`. You're right. Furthermore, Wayland detection is no longer used in this change, so I am removing it. It is now in #13830, where it belongs. > src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 56: > >> 54: } >> 55: >> 56: private static final int DENIED = -11; //defined in native code > > The comment is confusing as the field is defined right here, not in native code. removed. > src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 58: > >> 56: private static final int DENIED = -11; //defined in native code >> 57: >> 58: private static synchronized native int getRGBPixelsImpl( > > Is `synchronized` really needed on the declaration of `getRGBPixelsImpl()`? This code was written with the understanding that it will not run in parallel, so the `synchronized` is used. Moreover, we will get a significant benefit from removing `synchronized` only if `getRGBPixelsImpl` is called frequently from different threads. If it is called from a single thread(which seems to me to be the main use case), the results of my quick tests with JMH show that the difference between synchronized and not synchronized is within the margin of error. Removing the `synchronized` keyword would require additional testing, which at this point I want to avoid. And since this is not a public API we have no problem revisiting it later. P.S. I removed `synchronized` modifier from `getRGBPixels` > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 50: > >> 48: jmethodID storeTokenMethodID = NULL; >> 49: >> 50: inline void debug_screencast( > > Does this one need to be externally visible? If not, it can be (also) made `static`. It is used by `screencast_portal.c` and `screencast_pipewire.c`. > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 138: > >> 136: } >> 137: >> 138: static inline void convertRGBxToBGRx(int* in) { > > Will this work correctly on little-endian ARM systems? I haven't tested it, but I'll try to find a machine to test it on. > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 602: > >> 600: } >> 601: >> 602: pipewire_libhandle = dlopen("libpipewire-0.3.so.0", > > There's a useful macro for wrapping library names: `VERSIONED_JNI_LIB_NAME("pipewire-0.3", "0")` Updated. > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 722: > >> 720: >> 721: const gchar *token = jtoken >> 722: ? token = (*env)->GetStringUTFChars(env, jtoken, NULL) > > The variable `token` is unnecessarily used in its own initializer here. Fixed. > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 789: > >> 787: env, pixelArray, >> 788: start, len, >> 789: ((jint *) screenProps->captureData) > > I'm not sure if endianness of `captureData` matches the expected endianness of `pixelArray`. For now, it is going to be supported on x86-64 only, but it is a good candidate for investigation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186164127 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163925 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163799 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163601 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163575 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163520 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163465 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186163401 From azvegint at openjdk.org Fri May 5 14:38:19 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 5 May 2023 14:38:19 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: <_cTykE_ylL_s6FEZD-whKcVLZHtoca25nQ07DJg3zbc=.9107511d-1770-4259-8465-ae1998e0aba6@github.com> References: <_cTykE_ylL_s6FEZD-whKcVLZHtoca25nQ07DJg3zbc=.9107511d-1770-4259-8465-ae1998e0aba6@github.com> Message-ID: On Thu, 4 May 2023 19:52:22 GMT, Erik Joelsson wrote: >> Alexander Zvegintsev has updated the pull request incrementally with three additional commits since the last revision: >> >> - update, based on review comments >> - remove wayland detection >> - BUILD_LIBPIPEWIRE_HEADER_DIRS -> LIBPIPEWIRE_HEADER_DIRS > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 194: > >> 192: LIBAWT_XAWT_EXCLUDES := medialib debug >> 193: >> 194: BUILD_LIBPIPEWIRE_HEADER_DIRS := \ > > This variable name indicates that LIBPIPEWIRE is a library that we would build, but it seems to just be headers. I would suggest dropping the `BUILD_` prefix. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186173916 From mkartashev at openjdk.org Fri May 5 14:47:22 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Fri, 5 May 2023 14:47:22 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: References: <1ZGirSGimyAgLdQ_kmia0mw1qnFaY7_5N5xeDxET4DE=.7d5b9a18-ef76-4078-beeb-756f9afde420@github.com> Message-ID: On Fri, 5 May 2023 14:26:49 GMT, Alexander Zvegintsev wrote: > P.S. I removed synchronized modifier from getRGBPixels My main point was that you don't seem to need to have both, and while I picked one you picked the other ;-) So it's OK. >> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 50: >> >>> 48: jmethodID storeTokenMethodID = NULL; >>> 49: >>> 50: inline void debug_screencast( >> >> Does this one need to be externally visible? If not, it can be (also) made `static`. > > It is used by `screencast_portal.c` and `screencast_pipewire.c`. OK, then it actually does need to be externally visible. Thanks! >> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 789: >> >>> 787: env, pixelArray, >>> 788: start, len, >>> 789: ((jint *) screenProps->captureData) >> >> I'm not sure if endianness of `captureData` matches the expected endianness of `pixelArray`. > > For now, it is going to be supported on x86-64 only, but it is a good candidate for investigation. Is this enforced somehow? I mean what happens if this code is built on risc-v or arm? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186179577 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186180467 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1186184024 From djelinski at openjdk.org Fri May 5 15:00:20 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 5 May 2023 15:00:20 GMT Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical methods in its C API In-Reply-To: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> Message-ID: <4JoRRn8Ma2zhZDRAPTe5q2u42_ZR-PF96LYRXM1vxtc=.086f0bf3-da69-4f07-b6e5-f43c5c3a1577@github.com> On Sat, 29 Apr 2023 19:26:00 GMT, Julian Waters wrote: > In windowsaccessbridge(-64).dll the following methods are exported in a def file to C API which in turn call their real implementation, which are instance methods of the class WinAccessBridge: > > addJavaEventNotification > removeJavaEventNotification > addAccessibilityEventNotification > removeAccessibilityEventNotification > > > However, they are nowhere to be seen in the actual C interface, in AccessBridgeWindowsEntryPoints.cpp. Your guess is as good as mine as to how on earth MSVC is still capable of compiling and linking this without any errors whatsoever, but in any case, this is a severe oversight and should be properly defined in the C API lest this happy accident within MSVC is fixed by Microsoft in the future FWIW, this is what dumpbin displays for these entries: 1 2 0000351C addAccessibilityEventNotification = ?addAccessibilityEventNotification at WinAccessBridge@@QEAAX_J at Z (public: void __cdecl WinAccessBridge::addAccessibilityEventNotification(__int64)) 2 4 00003628 addJavaEventNotification = ?addJavaEventNotification at WinAccessBridge@@QEAAX_J at Z (public: void __cdecl WinAccessBridge::addJavaEventNotification(__int64)) 3 42 00006D94 removeAccessibilityEventNotification = ?removeAccessibilityEventNotification at WinAccessBridge@@QEAAX_J at Z (public: void __cdecl WinAccessBridge::removeAccessibilityEventNotification(__int64)) 4 44 00006EA0 removeJavaEventNotification = ?removeJavaEventNotification at WinAccessBridge@@QEAAX_J at Z (public: void __cdecl WinAccessBridge::removeJavaEventNotification(__int64)) There's no way to get a pointer to an instance of `WinAccessBridge` using the supported interface, and calling these methods with garbage value for `this` would likely crash. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1536386059 From azvegint at openjdk.org Fri May 5 15:01:51 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 5 May 2023 15:01:51 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: On Fri, 5 May 2023 02:37:28 GMT, Sergey Bylokhov wrote: > > If the user wishes to change their mind about the screens allowed to be captured, the user should use the new Robot#resetScreenCapturePermission method > > Do we really need to add this new API? probably we can implement the feature w/o this new method? I couldn't think of anything better. We need to somehow let the robot know that the saved `restore_token` no longer meets the user's expectations. It seems that the current robot API is not suitable for this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1536387259 From jwaters at openjdk.org Fri May 5 15:07:08 2023 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 5 May 2023 15:07:08 GMT Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical methods in its C API In-Reply-To: <4JoRRn8Ma2zhZDRAPTe5q2u42_ZR-PF96LYRXM1vxtc=.086f0bf3-da69-4f07-b6e5-f43c5c3a1577@github.com> References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> <4JoRRn8Ma2zhZDRAPTe5q2u42_ZR-PF96LYRXM1vxtc=.086f0bf3-da69-4f07-b6e5-f43c5c3a1577@github.com> Message-ID: On Fri, 5 May 2023 14:57:27 GMT, Daniel Jeli?ski wrote: > FWIW, this is what dumpbin displays for these entries: > > ``` > 1 2 0000351C addAccessibilityEventNotification = ?addAccessibilityEventNotification at WinAccessBridge@@QEAAX_J at Z (public: void __cdecl WinAccessBridge::addAccessibilityEventNotification(__int64)) > 2 4 00003628 addJavaEventNotification = ?addJavaEventNotification at WinAccessBridge@@QEAAX_J at Z (public: void __cdecl WinAccessBridge::addJavaEventNotification(__int64)) > 3 42 00006D94 removeAccessibilityEventNotification = ?removeAccessibilityEventNotification at WinAccessBridge@@QEAAX_J at Z (public: void __cdecl WinAccessBridge::removeAccessibilityEventNotification(__int64)) > 4 44 00006EA0 removeJavaEventNotification = ?removeJavaEventNotification at WinAccessBridge@@QEAAX_J at Z (public: void __cdecl WinAccessBridge::removeJavaEventNotification(__int64)) > ``` > > There's no way to get a pointer to an instance of `WinAccessBridge` using the supported interface, and calling these methods with garbage value for `this` would likely crash. Dear lord, the Microsoft linker is truly cursed, through and through @prrace What sort of testing would need to be done for such a change? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1536396606 From azvegint at openjdk.org Fri May 5 15:36:15 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 5 May 2023 15:36:15 GMT Subject: RFR: 8280031: Deprecate GTK2 for removal in JDK 21 Message-ID: GTK3 has been the default for several years now. GTK2 is now only available by specifying it with the jdk.gtk.version system property. With the announcement of the GTK 4 release in December 2020, the GTK 2 toolkit has reached its end of life. It is time to deprecate it for removal. Since there's no associated API, we just print a deprecation message once when trying to load gtk2. CSR: https://bugs.openjdk.org/browse/JDK-8307481 ------------- Commit messages: - initial Changes: https://git.openjdk.org/jdk/pull/13834/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13834&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8280031 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13834/head:pull/13834 PR: https://git.openjdk.org/jdk/pull/13834 From dnguyen at openjdk.org Fri May 5 16:31:32 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 5 May 2023 16:31:32 GMT Subject: Integrated: 8306871: Open source more AWT Drag & Drop tests In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 18:34:36 GMT, Damon Nguyen wrote: > This PR open sources more AWT DnD & Event related tests This pull request has now been integrated. Changeset: b5a48277 Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/b5a48277ab5b42c4b13db7ddb5418a17ada512ec Stats: 1915 lines in 6 files changed: 1915 ins; 0 del; 0 mod 8306871: Open source more AWT Drag & Drop tests Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13725 From jiangli at openjdk.org Fri May 5 16:45:35 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 5 May 2023 16:45:35 GMT Subject: RFR: 8307194: Enhance static-libs-image [v6] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw: - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a. - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a. - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib. - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now: - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk. - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/84861990..e49d7b4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=04-05 Stats: 78 lines in 4 files changed: 64 ins; 8 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Fri May 5 16:48:12 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 5 May 2023 16:48:12 GMT Subject: RFR: 8307194: Enhance static-libs-image [v6] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw: - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a. - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a. - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib. - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now: - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk. - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/84861990..e49d7b4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=04-05 Stats: 78 lines in 4 files changed: 64 ins; 8 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Fri May 5 16:48:13 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 5 May 2023 16:48:13 GMT Subject: RFR: 8307194: Enhance static-libs-image [v6] In-Reply-To: References: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> Message-ID: On Thu, 4 May 2023 19:12:14 GMT, Severin Gehwolf wrote: >> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736. >> >> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same. > >> [...] I'll see if I can test this on a mandrel build tomorrow... > > @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you? > @jerboaa Thanks very much for testing with mandrel. Based on yours and @olpaw's feedback, I'll refactor this PR to not use the existing `static-libs-image` target for including hotspot `libjvm.a`. Updated PR to decouple building libjvm.a from static-libs-image target. Add a java-static-libs-image target for building the static library super set, which includes JDK .a static libraries and hotspot libjvm.a. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1186300461 From jiangli at openjdk.org Fri May 5 16:52:22 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 5 May 2023 16:52:22 GMT Subject: RFR: 8307194: Enhance static-libs-image [v7] In-Reply-To: References: Message-ID: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries: > > - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib'; > - For libjvm.a specifically, exclude operator_new.o; > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files; > - Handle long arguments case for static build in make/common/NativeCompilation.gmk; > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS; Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Fix whitespace error in make/StaticJvmLibsImage.gmk. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/e49d7b4e..2cb786ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Fri May 5 16:53:35 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 5 May 2023 16:53:35 GMT Subject: RFR: 8307194: Enhance static-libs-image [v7] In-Reply-To: References: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com> Message-ID: On Fri, 5 May 2023 16:43:46 GMT, Jiangli Zhou wrote: >>> [...] I'll see if I can test this on a mandrel build tomorrow... >> >> @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you? > >> @jerboaa Thanks very much for testing with mandrel. Based on yours and @olpaw's feedback, I'll refactor this PR to not use the existing `static-libs-image` target for including hotspot `libjvm.a`. > > Updated PR to decouple building libjvm.a from static-libs-image target. Add a java-static-libs-image target for building the static library super set, which includes JDK .a static libraries and hotspot libjvm.a. > At first glance, static-libs-image create libjvm.a in the same directory as the other lib .a files make sense but I don't know how that works if --with-jvm-variants is used to create more more than one libjvm. Might have to think whether this combination make sense or not. We now use a java-static-libs-image target for building all JDK and hotspot .a static libraries. @erikj79 Suggested building libjvm.a for $(JVM_VARIANT_MAIN) for now. I think that's a good starting point. The PR has been updated accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1186308007 From honkar at openjdk.org Fri May 5 16:58:20 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 5 May 2023 16:58:20 GMT Subject: RFR: JDK-8307301: Update HarfBuzz to 7.2.0 Message-ID: Harfbuzz updated from 7.0.1 to 7.2.0. Files changed - - harfbuzz.md file updated - 1 newly added source file - hb-ot-var-cvar-table.hh - 73 modified source files Following testing was carried for the update and works as expected. 1. Client CI Testing 2. TextLayout related tests 3. Font2DTest in TextLayout mode 4. Manual Testing of Arabic, Hebrew, Thai, Indic languages on TextLayout. (Mac, Windows and Linux) ------------- Commit messages: - removed whitespaces - added .md file - modified files - newly added file Changes: https://git.openjdk.org/jdk/pull/13835/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13835&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307301 Stats: 2679 lines in 75 files changed: 1972 ins; 424 del; 283 mod Patch: https://git.openjdk.org/jdk/pull/13835.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13835/head:pull/13835 PR: https://git.openjdk.org/jdk/pull/13835 From azvegint at openjdk.org Fri May 5 17:01:30 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 5 May 2023 17:01:30 GMT Subject: RFR: 8306941: Open source several datatransfer and dnd AWT tests Message-ID: Open sourcing few more tests: java/awt/datatransfer/MimeFormatsTest/MimeFormatsTest.java java/awt/datatransfer/RemoveFlavorListenerTest/RemoveFlavorListenerTest.java java/awt/dnd/AutoscrollStopTest/AutoscrollStopTest.java java/awt/dnd/ButtonReleaseTest/ButtonReleaseTest.java Testing looks good. ------------- Commit messages: - initial Changes: https://git.openjdk.org/jdk/pull/13836/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13836&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306941 Stats: 831 lines in 4 files changed: 831 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13836.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13836/head:pull/13836 PR: https://git.openjdk.org/jdk/pull/13836 From kizune at openjdk.org Fri May 5 17:16:16 2023 From: kizune at openjdk.org (Alexander Zuev) Date: Fri, 5 May 2023 17:16:16 GMT Subject: RFR: JDK-8307381: Open Source JFrame, JIF related Swing Tests [v2] In-Reply-To: <_2YqwfjaUIo1OEtvF8BqCgZtaGoaElJ2e9hzEa4dRdQ=.7459421d-d19a-4829-a39c-c25c0de16c26@github.com> References: <_2YqwfjaUIo1OEtvF8BqCgZtaGoaElJ2e9hzEa4dRdQ=.7459421d-d19a-4829-a39c-c25c0de16c26@github.com> Message-ID: On Thu, 4 May 2023 20:27:48 GMT, Harshitha Onkar wrote: >> Open sourced the following JFrame, JIF related Swing tests. >> >> >> test/jdk/javax/swing/JFrame/bug4101444.java >> test/jdk/javax/swing/JFrame/bug4208018.java >> test/jdk/javax/swing/JInternalFrame/bug4308938.java >> test/jdk/javax/swing/JInternalFrame/bug4320889.java >> test/jdk/javax/swing/JTextField/bug4300552.java >> test/jdk/javax/swing/JToggleButton/bug4277049.java >> >> >> CI testing looks good. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > removed extra space Looks good. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13787#pullrequestreview-1415161254 From prr at openjdk.org Fri May 5 17:28:14 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 5 May 2023 17:28:14 GMT Subject: RFR: JDK-8307301: Update HarfBuzz to 7.2.0 In-Reply-To: References: Message-ID: On Fri, 5 May 2023 16:40:57 GMT, Harshitha Onkar wrote: > Harfbuzz updated from 7.0.1 to 7.2.0. > > Files changed - > > - harfbuzz.md file updated > - 1 newly added source file - hb-ot-var-cvar-table.hh > - 73 modified source files > > > Following testing was carried for the update and works as expected. > > 1. Client CI Testing > 2. TextLayout related tests > 3. Font2DTest in TextLayout mode > 4. Manual Testing of Arabic, Hebrew, Thai, Indic languages on TextLayout. (Mac, Windows and Linux) LGTM ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13835#pullrequestreview-1415178214 From prr at openjdk.org Fri May 5 17:32:19 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 5 May 2023 17:32:19 GMT Subject: RFR: 8306941: Open source several datatransfer and dnd AWT tests In-Reply-To: References: Message-ID: On Fri, 5 May 2023 16:54:20 GMT, Alexander Zvegintsev wrote: > Open sourcing few more tests: > > > java/awt/datatransfer/MimeFormatsTest/MimeFormatsTest.java > java/awt/datatransfer/RemoveFlavorListenerTest/RemoveFlavorListenerTest.java > java/awt/dnd/AutoscrollStopTest/AutoscrollStopTest.java > java/awt/dnd/ButtonReleaseTest/ButtonReleaseTest.java > > > Testing looks good. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13836#pullrequestreview-1415182834 From prr at openjdk.org Fri May 5 17:33:43 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 5 May 2023 17:33:43 GMT Subject: RFR: 8280031: Deprecate GTK2 for removal In-Reply-To: References: Message-ID: On Fri, 5 May 2023 15:21:14 GMT, Alexander Zvegintsev wrote: > GTK3 has been the default for several years now. GTK2 is now only available by specifying it with the jdk.gtk.version system property. With the announcement of the GTK 4 release in December 2020, the GTK 2 toolkit has reached its end of life. > > It is time to deprecate it for removal. > > Since there's no associated API, we just print a deprecation message once when trying to load gtk2. > > CSR: https://bugs.openjdk.org/browse/JDK-8307481 Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13834#pullrequestreview-1415184242 From honkar at openjdk.org Fri May 5 17:36:46 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 5 May 2023 17:36:46 GMT Subject: Integrated: JDK-8307301: Update HarfBuzz to 7.2.0 In-Reply-To: References: Message-ID: On Fri, 5 May 2023 16:40:57 GMT, Harshitha Onkar wrote: > Harfbuzz updated from 7.0.1 to 7.2.0. > > Files changed - > > - harfbuzz.md file updated > - 1 newly added source file - hb-ot-var-cvar-table.hh > - 73 modified source files > > > Following testing was carried for the update and works as expected. > > 1. Client CI Testing > 2. TextLayout related tests > 3. Font2DTest in TextLayout mode > 4. Manual Testing of Arabic, Hebrew, Thai, Indic languages on TextLayout. (Mac, Windows and Linux) This pull request has now been integrated. Changeset: d8b230c3 Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/d8b230c384c47cc2bdc28d0849859d58a6a52eae Stats: 2679 lines in 75 files changed: 1972 ins; 424 del; 283 mod 8307301: Update HarfBuzz to 7.2.0 Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13835 From prr at openjdk.org Fri May 5 17:38:16 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 5 May 2023 17:38:16 GMT Subject: RFR: 8307145: windowsaccessbridge.dll is missing 4 critical methods in its C API In-Reply-To: References: <3n_rUEMgKOYJOL4dt9nR_cm__hPAWcLEGf24ManahQ4=.5a72810c-997d-4b38-a021-d5886a26bfbd@github.com> <4JoRRn8Ma2zhZDRAPTe5q2u42_ZR-PF96LYRXM1vxtc=.086f0bf3-da69-4f07-b6e5-f43c5c3a1577@github.com> Message-ID: On Fri, 5 May 2023 15:04:36 GMT, Julian Waters wrote: > > FWIW, this is what dumpbin displays for these entries: > > ``` > > 1 2 0000351C addAccessibilityEventNotification = ?addAccessibilityEventNotification at WinAccessBridge@@QEAAX_J at Z (public: void __cdecl WinAccessBridge::addAccessibilityEventNotification(__int64)) > > 2 4 00003628 addJavaEventNotification = ?addJavaEventNotification at WinAccessBridge@@QEAAX_J at Z (public: void __cdecl WinAccessBridge::addJavaEventNotification(__int64)) > > 3 42 00006D94 removeAccessibilityEventNotification = ?removeAccessibilityEventNotification at WinAccessBridge@@QEAAX_J at Z (public: void __cdecl WinAccessBridge::removeAccessibilityEventNotification(__int64)) > > 4 44 00006EA0 removeJavaEventNotification = ?removeJavaEventNotification at WinAccessBridge@@QEAAX_J at Z (public: void __cdecl WinAccessBridge::removeJavaEventNotification(__int64)) > > ``` > > > > > > > > > > > > > > > > > > > > > > > > There's no way to get a pointer to an instance of `WinAccessBridge` using the supported interface, and calling these methods with garbage value for `this` would likely crash. > > Dear lord, the Microsoft linker is truly cursed, through and through > > @prrace What sort of testing would need to be done for such a change? @azuev-java and @kumarabhi006 can help with review and testing of this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13734#issuecomment-1536570955 From prr at openjdk.org Fri May 5 17:41:28 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 5 May 2023 17:41:28 GMT Subject: RFR: 8307091: A few client tests intermittently throw ConcurrentModificationException [v2] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 05:25:55 GMT, Tejesh R wrote: >> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java line 365: >> >>> 363: >>> 364: if (start >= 0 && end > start) { >>> 365: List listStart_OldSize = new Vector<>(fileCache.subList(start, oldSize)); >> >> Why Vector was used instead of ArrayList ? > > Nothing specific reason why I choose vector apart from the main object is of Vector type and since in this context (where both the objects are not shared) both Vector/Arraylist comparison remains same. Does Arraylist comparison has any advantage here? I already looked at this and Vector is what this class uses already and there's no reason to be different and definitely no reason to change the rest. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13783#discussion_r1186348473 From dnguyen at openjdk.org Fri May 5 17:48:29 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 5 May 2023 17:48:29 GMT Subject: RFR: 8307130: Open source few Swing JMenu tests Message-ID: Open source few Swing JMenu tests ------------- Commit messages: - Initial test add Changes: https://git.openjdk.org/jdk/pull/13839/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13839&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307130 Stats: 272 lines in 4 files changed: 272 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13839/head:pull/13839 PR: https://git.openjdk.org/jdk/pull/13839 From prr at openjdk.org Fri May 5 18:00:18 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 5 May 2023 18:00:18 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests In-Reply-To: References: Message-ID: On Fri, 5 May 2023 09:54:36 GMT, Tejesh R wrote: > Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. test/jdk/java/awt/Panel/SetForegroundTest.java line 33: > 31: import java.awt.Color; > 32: > 33: import javax.swing.JWindow; Would be nice to have an empty line here test/jdk/java/awt/Panel/SetForegroundTest.java line 51: > 49: } finally { > 50: EventQueue.invokeAndWait(() -> { > 51: if(jwindow != null) { if( -> if ( test/jdk/java/awt/Scrollbar/PageIncrementTest.java line 39: > 37: > 38: public static void main(String[] args) throws Exception { > 39: EventQueue.invokeAndWait(() -> { Not sure why this test needs to run on EDT. It is just a unit test and doesn't create a Window/Frame. test/jdk/java/awt/Scrollbar/ScrollbarKeyControlTest.java line 61: > 59: System.out.println("This test is for XAWT only."); > 60: return; > 61: } This is largely pointless since you have requires os==linux. Perhaps its from when we had MToolkit. If you keep it, then I'd make it just check the "os.name" and not the toolkit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1186359997 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1186361163 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1186363103 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1186365441 From aivanov at openjdk.org Fri May 5 18:05:23 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 5 May 2023 18:05:23 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v4] In-Reply-To: References: Message-ID: On Wed, 3 May 2023 11:00:36 GMT, Prasanta Sadhukhan wrote: >> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. >> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. >> Fixed by implementing the equality and hashCode method for CSS.FontSize class. >> >> All jtreg/jck tests are ok > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > More Attrbutes added Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2539: > 2537: return val instanceof CSS.BorderStyle border && style.equals(border.style); > 2538: } > 2539: // CSS.Values are static, don't archive it. Suggestion: } // CSS.Values are static, don't archive it. A blank line between a method body and a field. src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2675: > 2673: return val instanceof CSS.LengthValue lu && span == lu.span; > 2674: } > 2675: /** If true, span is a percentage value, and that to determine Suggestion: } /** If true, span is a percentage value, and that to determine A blank line between a method body and a field. src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2897: > 2895: @Override > 2896: public int hashCode() { > 2897: return Float.hashCode(horizontalPosition); For better hashing, `verticalPosition` should also be taken into account. ------------- PR Review: https://git.openjdk.org/jdk/pull/13405#pullrequestreview-1415214777 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1186364746 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1186365254 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1186366897 From aivanov at openjdk.org Fri May 5 18:05:25 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 5 May 2023 18:05:25 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v2] In-Reply-To: <0gOhTUXPHgGwkGUPT-I8JNKvQWQcXCfenFMFRRWv-mE=.5e796740-d480-4190-b0bb-45770e248aee@github.com> References: <6AMf-eKADne9JGixe0AxYWuSCpoT0zPLMSVJ32hg8LU=.77ff4752-a702-4dad-bf80-e44cd91985f0@github.com> <0gOhTUXPHgGwkGUPT-I8JNKvQWQcXCfenFMFRRWv-mE=.5e796740-d480-4190-b0bb-45770e248aee@github.com> Message-ID: <8if6uLQ3dd2fZy89oTBqe_kc0A1gheaAqFm3zEza98A=.b86e6eb8-a5cc-4ca6-89ad-dec95ce9c6ef@github.com> On Wed, 3 May 2023 21:14:25 GMT, Phil Race wrote: >> I'm pretty sure the test will still pass because Java compiler interns strings. You have to explicitly create a new instance of the String to make the test fail. >> >> In real applications, attributes are parsed from a style sheet and therefore the identity test won't pass. > > yes this needs to be changed. > Also needs to be changed at line 2034. The following test still fails. private static void testFontFamilyCSS() { StyleSheet ss = new StyleSheet(); AttributeSet a = ss.getDeclaration("font-family: sans-serif"); AttributeSet b = ss.getDeclaration("font-family: sans-serif"); // Verify a.isEqual(b) } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1186360256 From rmahajan at openjdk.org Fri May 5 18:07:33 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 5 May 2023 18:07:33 GMT Subject: Integrated: 6176679: Application freezes when copying an animated gif image to the system clipboard In-Reply-To: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> References: <6MbLCIPjS6OC7o15dsHD_n1zKVYiu-9Kk5ekg11U8vY=.d4b79c4f-6e8e-4dc6-a0ff-dd9bc9020fc8@github.com> Message-ID: On Mon, 10 Apr 2023 21:32:30 GMT, Rajat Mahajan wrote: > **Problem:** > > On pressing the Copy button we keep waiting in AWT-EventQueue thread in reconstruct() function as we detect that we have missing information for the animated image since we are copying single frame at a time. > Due to this infinite wait the application freezes. > > **Proposed Fix:** > > There are conditions in the reconstruct() function that avoid entering the wait() code if we have some error reading the image , etc. So, I added the condition to avoid entering the wait() code if we are copying single frame at a time. This sounded logical to me since if we have incomplete information(single frame) about the animated image we shouldn?t keep waiting, as it leads to infinite wait. > After this change I see the GIF image being correctly copied and animated. > > > **Testing:** > > Added a test for this (bug6176679.java) and tested locally on my Windows machine and on mach5. This pull request has now been integrated. Changeset: 6c71859a Author: Rajat Mahajan Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/6c71859ac240c788364169422e726f8f5443bf75 Stats: 183 lines in 2 files changed: 170 ins; 8 del; 5 mod 6176679: Application freezes when copying an animated gif image to the system clipboard Reviewed-by: aivanov, dmarkov ------------- PR: https://git.openjdk.org/jdk/pull/13414 From prr at openjdk.org Fri May 5 18:12:19 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 5 May 2023 18:12:19 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests In-Reply-To: References: Message-ID: On Fri, 5 May 2023 04:56:22 GMT, Abhishek Kumar wrote: > This PR is to open source JMenuItem related swing tests. test/jdk/javax/swing/JMenuItem/bug4304129.java line 47: > 45: public static void main(String args[]) throws Exception { > 46: bug4304129 test = new bug4304129(); > 47: test.init(); I don't see why we need an instance here. The body of init() can be moved into main() and mnemonic and accelerator made static test/jdk/javax/swing/JMenuItem/bug4839464.java line 79: > 77: public static JButton changeShortDescButton; > 78: > 79: public JMenuItem item; it seems a bit odd that this and some below are instance vars and the ones above are static Should you make them all static ?.. and then you don't need an instance of the test class either Or make them all instance .. either way ... I also find it odd that this test creates TWO Robots - one AWT Robot and one JRobot. Can you consolidate these ? test/jdk/javax/swing/JMenuItem/bug4966168.java line 46: > 44: public static void main(String args[]) throws Exception { > 45: bug4966168 test = new bug4966168(); > 46: test.init(); No need I can see for the instance. Collapse init() into main() ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1186370032 PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1186374563 PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1186375045 From prr at openjdk.org Fri May 5 18:14:16 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 5 May 2023 18:14:16 GMT Subject: RFR: 8307130: Open source few Swing JMenu tests In-Reply-To: References: Message-ID: <7LOMUGDqiphqiz5dnsNfBUcilPhNAV6JiNg_bGIqp6U=.9e9844a7-606f-471a-8480-a31c4ae0ac09@github.com> On Fri, 5 May 2023 17:41:26 GMT, Damon Nguyen wrote: > Open source few Swing JMenu tests Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13839#pullrequestreview-1415239602 From honkar at openjdk.org Fri May 5 18:16:30 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 5 May 2023 18:16:30 GMT Subject: Integrated: JDK-8307381: Open Source JFrame, JIF related Swing Tests In-Reply-To: References: Message-ID: <3otPI2CbiR8X5PE91HEWenbG8-EzQdJ-m7Wq-Of_0mE=.89db6f2a-d686-48a0-98ef-8aafb0d27d28@github.com> On Wed, 3 May 2023 20:58:00 GMT, Harshitha Onkar wrote: > Open sourced the following JFrame, JIF related Swing tests. > > > test/jdk/javax/swing/JFrame/bug4101444.java > test/jdk/javax/swing/JFrame/bug4208018.java > test/jdk/javax/swing/JInternalFrame/bug4308938.java > test/jdk/javax/swing/JInternalFrame/bug4320889.java > test/jdk/javax/swing/JTextField/bug4300552.java > test/jdk/javax/swing/JToggleButton/bug4277049.java > > > CI testing looks good. This pull request has now been integrated. Changeset: 4386d42d Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/4386d42d31af9042121581cd3fd4d5a7cf8961e6 Stats: 354 lines in 6 files changed: 354 ins; 0 del; 0 mod 8307381: Open Source JFrame, JIF related Swing Tests Reviewed-by: dnguyen, kizune ------------- PR: https://git.openjdk.org/jdk/pull/13787 From achung at openjdk.org Fri May 5 18:35:05 2023 From: achung at openjdk.org (Alisen Chung) Date: Fri, 5 May 2023 18:35:05 GMT Subject: RFR: JDK-8307083: Open source some drag and drop tests 3 [v2] In-Reply-To: References: Message-ID: > moving tests to open Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/java/awt/dnd/MissedDragEnterTest.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13764/files - new: https://git.openjdk.org/jdk/pull/13764/files/849b0013..b99982a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13764&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13764&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13764/head:pull/13764 PR: https://git.openjdk.org/jdk/pull/13764 From azvegint at openjdk.org Fri May 5 20:19:26 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 5 May 2023 20:19:26 GMT Subject: Integrated: 8280031: Deprecate GTK2 for removal In-Reply-To: References: Message-ID: On Fri, 5 May 2023 15:21:14 GMT, Alexander Zvegintsev wrote: > GTK3 has been the default for several years now. GTK2 is now only available by specifying it with the jdk.gtk.version system property. With the announcement of the GTK 4 release in December 2020, the GTK 2 toolkit has reached its end of life. > > It is time to deprecate it for removal. > > Since there's no associated API, we just print a deprecation message once when trying to load gtk2. > > CSR: https://bugs.openjdk.org/browse/JDK-8307481 This pull request has now been integrated. Changeset: 7d58978f Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/7d58978f62bf333f256115d6592706d70144ad15 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod 8280031: Deprecate GTK2 for removal Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13834 From erikj at openjdk.org Fri May 5 20:46:22 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 5 May 2023 20:46:22 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7] In-Reply-To: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> References: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> Message-ID: On Fri, 5 May 2023 16:52:22 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace error in make/StaticJvmLibsImage.gmk. With this solution, the build will produce a different static-libs bundle and image depending on the make target called, but the output name is exactly the same. That isn't ok. If you run one target after the other, the behavior becomes strange and unpredictable. If these are different deliverables, they need to be that all the way through, with a separate image and bundle with their own make targets. If we go with two separate deliverables, then to me it makes more sense that "static-libs-image" is the complete image with all the static libs and if graal needs a specialized subset of this, then that's something graal specific. The graal-builder-image is already meant just for their consumption (which is a combination of the jdk-image and the current static-libs-image). Having graal builds having to change the target they call is inconvenient for them, but for us to be forced to maintain unintuitive build targets is also bad. All of that said, I think we can get away with a smaller subset of targets and deliverables. AFAIK, graal needs the combined `graal-builder-image` as input to their build anyway, so they should not have any dependency on what the target `static-libs-image` produces. Given that I propose the following behavior: `make static-libs-image` produces `images/static-libs` with all .a (including libjvm.a). `make static-libs-graal-image` produces `images/static-libs-graal` with all .a except libjvm.a. `make graal-builder-image` produces `images/graal-builder-image` like today, but depends on and uses `static-libs-graal-image` instead of `static-libs-image`. `make static-libs-bundles` depends on and uses `static-libs-image` like today, so will contain libjvm.a, which is new behavior. Further I would like to suggest that libjvm.a gets put in the variant subdir under lib, just like libjvm.so does today (e.g. lib/server/libjvm.a). That way you can support building libjvm.a for all variants without worry. It will also get libjvm.a out of the way to cause less trouble for a graal build that uses the static-libs-bundles as input. This goes against what I suggested before, to just use JVM_VARIANT_MAIN, but I think this makes for a cleaner long term solution given the goals of the hermetic java effort. ------------- PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1415436469 From dnguyen at openjdk.org Fri May 5 20:57:33 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 5 May 2023 20:57:33 GMT Subject: RFR: 8307165: java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java timed out [v4] In-Reply-To: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> References: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> Message-ID: > When converting this test to be applicable to be open sourced, changes were made. I reverted some of these changes to get the test stable again. Now it passes when run on various OS's 100x. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Make panels volatile. Move waitForIdle ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13761/files - new: https://git.openjdk.org/jdk/pull/13761/files/34c649b0..5af93fcd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13761&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13761&range=02-03 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13761.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13761/head:pull/13761 PR: https://git.openjdk.org/jdk/pull/13761 From achung at openjdk.org Fri May 5 21:11:35 2023 From: achung at openjdk.org (Alisen Chung) Date: Fri, 5 May 2023 21:11:35 GMT Subject: RFR: 8306881: Update FreeType to 2.13.0 Message-ID: update freetype version to 2.13, all tests passed ------------- Commit messages: - fixed whitespace errors - removed extra copyright line from md file - fixed spacing in md file - updated freetype.md - updated config files - added dependencies for freetype - update freetype.md - revert freetype.md - init commit Changes: https://git.openjdk.org/jdk/pull/13841/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13841&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306881 Stats: 3614 lines in 284 files changed: 1610 ins; 690 del; 1314 mod Patch: https://git.openjdk.org/jdk/pull/13841.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13841/head:pull/13841 PR: https://git.openjdk.org/jdk/pull/13841 From prr at openjdk.org Fri May 5 21:38:14 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 5 May 2023 21:38:14 GMT Subject: RFR: 8306881: Update FreeType to 2.13.0 In-Reply-To: References: Message-ID: On Fri, 5 May 2023 18:28:38 GMT, Alisen Chung wrote: > update freetype version to 2.13, all tests passed Can you also confirm that you compiled this using the option discussed in UPDATING.txt, ie When updating specify --with-freetype=bundled to test builds to expose build issues. This is important because presently on Linux the build defaults to linking against the system library and does not attempt to compile the sources. src/java.desktop/share/native/libfreetype/include/freetype/config/ftmodule.h line 18: > 16: FT_USE_MODULE( FT_Driver_ClassRec, cff_driver_class ) > 17: FT_USE_MODULE( FT_Driver_ClassRec, t1cid_driver_class ) > 18: //FT_USE_MODULE( FT_Driver_ClassRec, pfr_driver_class ) if you add back the spaces the diff for this file should go away. ------------- PR Review: https://git.openjdk.org/jdk/pull/13841#pullrequestreview-1415478442 PR Review Comment: https://git.openjdk.org/jdk/pull/13841#discussion_r1186513249 From jjg at openjdk.org Fri May 5 22:22:14 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 5 May 2023 22:22:14 GMT Subject: RFR: JDK-8305593: Add @spec tags in java.desktop In-Reply-To: References: Message-ID: On Wed, 3 May 2023 20:51:15 GMT, Phil Race wrote: >> This work is primarily about adding `@spec` tags, in a semi-automated fashion, using a custom utility that scans comments in the public API, looking for `href`s to "well-known" sites hosting external specifications. While "mostly automated", I did manually cleanup the references by line-wrapping as appropriate. >> >> It is out of scope at this time to cleanup up the underlying `href`s, although we should look at cleaning up those links later, identifying the latest/preferred URL for the appropriate version of the spec document, which may or may not be the latest overall version of the spec. (For example, the client docs reference HTML 3.2, and should not reference anything more recent.). This cleanup can be done later and needs to be done in conjunction with the relevant teams, and probably not as a semi-automated update. Such cleanup should be somewhat easier once we have tagged the affected comments with the relevant `@spec` tags. >> >> I note that once we have completed the addition of the `@spec` tags, we will, re-enable the new "External Specifications" page, which cross-references where each individual external specification is mentioned in the overall API documentation. > > Sorry, but no matter how many times I try, it seems wrong to even for some short amount of time to have @spec point to one place and the javadoc point to another. They should always be consistent. > If it is out of scope to update the javadoc, then the new spec tag should just match the existing javadoc. For the `rfc-editor.org` that's going to be hard, insofar as there are strong opinions (voiced in an earlier round of review) about using references to the old sites. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13360#discussion_r1186534416 From jjg at openjdk.org Fri May 5 22:22:17 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 5 May 2023 22:22:17 GMT Subject: RFR: JDK-8305593: Add @spec tags in java.desktop In-Reply-To: References: Message-ID: On Fri, 7 Apr 2023 01:36:37 GMT, Phil Race wrote: >> Please review a docs-only change to add `@spec` tags into `java.desktop` public API files > > src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 227: > >> 225: * @spec https://www.rfc-editor.org/info/rfc1951 >> 226: * RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 >> 227: */ > > OK. So why are you preferring this rfc-editor.org site ? > Seems we should get that cleared up before I look further Because we were strongly recommended to do so, in an earlier round of review. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13360#discussion_r1186534179 From jjg at openjdk.org Fri May 5 22:26:17 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 5 May 2023 22:26:17 GMT Subject: RFR: JDK-8305593: Add @spec tags in java.desktop In-Reply-To: References: Message-ID: On Fri, 5 May 2023 22:19:38 GMT, Jonathan Gibbons wrote: >> Sorry, but no matter how many times I try, it seems wrong to even for some short amount of time to have @spec point to one place and the javadoc point to another. They should always be consistent. >> If it is out of scope to update the javadoc, then the new spec tag should just match the existing javadoc. > > For the `rfc-editor.org` that's going to be hard, insofar as there are strong opinions (voiced in an earlier round of review) about using references to the old sites. I see just 18 references matching `href=....ietf.org` so I guess I can manually update those for you. $ grep -r 'href=[^ ]*ietf.org' open/src/java.desktop open/src/java.desktop/share/classes/sun/awt/image/PNGImageDecoder.java: See RFC2083 for details. */ open/src/java.desktop/share/classes/java/awt/Desktop.java: * href="http://www.ietf.org/rfc/rfc2368.txt">The mailto URL open/src/java.desktop/share/classes/java/awt/peer/DesktopPeer.java: * RFC2368: The mailto open/src/java.desktop/share/classes/javax/print/attribute/standard/Compression.java: * RFC 1952. open/src/java.desktop/share/classes/javax/print/attribute/standard/MediaSizeName.java: * RFC 2911 open/src/java.desktop/share/classes/javax/print/attribute/standard/Fidelity.java: * RFC 2911 Section 15.1 for a open/src/java.desktop/share/classes/javax/print/attribute/standard/package-info.java: * RFC 2911 for more open/src/java.desktop/share/classes/javax/print/DocFlavor.java: * RFC 2045 and open/src/java.desktop/share/classes/javax/print/DocFlavor.java: * RFC 2046) that specifies open/src/java.desktop/share/classes/javax/print/DocFlavor.java: * RFC 2046, which says the open/src/java.desktop/share/classes/javax/print/DocFlavor.java: * open/src/java.desktop/share/classes/javax/print/package-info.java: * RFC 2911 Internet Printing open/src/java.desktop/share/classes/javax/print/MimeType.java: * RFC 2045 and open/src/java.desktop/share/classes/javax/print/MimeType.java: * RFC 2046. A MIME type open/src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java: * @see DEFLATE specification open/src/java.desktop/share/classes/javax/imageio/plugins/tiff/FaxTIFFTagSet.java: * TIFF-F (RFC 2036) file. open/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html: open/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html: $ grep -r 'href=[^ ]*ietf.org' open/src/java.desktop | wc -l 18 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13360#discussion_r1186535685 From prr at openjdk.org Fri May 5 22:37:17 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 5 May 2023 22:37:17 GMT Subject: RFR: JDK-8305593: Add @spec tags in java.desktop In-Reply-To: References: Message-ID: On Fri, 5 May 2023 22:19:03 GMT, Jonathan Gibbons wrote: >> src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 227: >> >>> 225: * @spec https://www.rfc-editor.org/info/rfc1951 >>> 226: * RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 >>> 227: */ >> >> OK. So why are you preferring this rfc-editor.org site ? >> Seems we should get that cleared up before I look further > > Because we were strongly recommended to do so, in an earlier round of review. I have no idea who that person is with the strong opinions, and hence no idea of his standing to assert the opinion. So I'd be reluctant to follow his suggestion without more info. But they still should be the same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13360#discussion_r1186539637 From dnguyen at openjdk.org Sat May 6 00:20:16 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Sat, 6 May 2023 00:20:16 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests In-Reply-To: References: Message-ID: On Fri, 5 May 2023 04:56:22 GMT, Abhishek Kumar wrote: > This PR is to open source JMenuItem related swing tests. test/jdk/javax/swing/JMenuItem/bug4839464.java line 29: > 27: @summary Shortcoming in the way JMenuItem handles 'propertyChange()' events. > 28: @library ../../regtesthelpers > 29: @build Util JRobot I see Util is added but I don't see any Util methods used. Is this needed? Also, did you try running this test in mach5 after moving it to open? I think you get an error with this ```regtesthelpers``` path since you removed the individual directories for each of these tests and placed them directly into the ```JMenuItem``` dir. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1186566265 From honkar at openjdk.org Sat May 6 00:35:20 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 6 May 2023 00:35:20 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests In-Reply-To: References: Message-ID: On Fri, 5 May 2023 04:56:22 GMT, Abhishek Kumar wrote: > This PR is to open source JMenuItem related swing tests. test/jdk/javax/swing/JMenuItem/bug4839464.java line 220: > 218: // Check mnemonics > 219: int tmpInt = item.getMnemonic(); > 220: robo.clickMouseOn(changeMnemonicButton); @DamonGuy Util's JRobot is used here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1186568838 From honkar at openjdk.org Sat May 6 00:42:20 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 6 May 2023 00:42:20 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests In-Reply-To: References: Message-ID: On Sat, 6 May 2023 00:17:01 GMT, Damon Nguyen wrote: >> This PR is to open source JMenuItem related swing tests. > > test/jdk/javax/swing/JMenuItem/bug4839464.java line 29: > >> 27: @summary Shortcoming in the way JMenuItem handles 'propertyChange()' events. >> 28: @library ../../regtesthelpers >> 29: @build Util JRobot > > I see Util is added but I don't see any Util methods used. Is this needed? > > Also, did you try running this test after moving it to open? I think you get an error with this ```regtesthelpers``` path since you removed the individual directories for each of these tests and placed them directly into the ```JMenuItem``` dir. @kumarabhi006 Yes, it should be `@library ../regtesthelpers` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1186570185 From dnguyen at openjdk.org Sat May 6 00:50:33 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Sat, 6 May 2023 00:50:33 GMT Subject: RFR: 8307130: Open source few Swing JMenu tests [v2] In-Reply-To: References: Message-ID: > Open source few Swing JMenu tests Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Add Util. Change helper path ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13839/files - new: https://git.openjdk.org/jdk/pull/13839/files/08d0cda7..1d2ccd19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13839&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13839&range=00-01 Stats: 21 lines in 1 file changed: 19 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13839/head:pull/13839 PR: https://git.openjdk.org/jdk/pull/13839 From jiefu at openjdk.org Sat May 6 01:27:41 2023 From: jiefu at openjdk.org (Jie Fu) Date: Sat, 6 May 2023 01:27:41 GMT Subject: RFR: 8307569: Build with gcc8 is broken after JDK-8307301 Message-ID: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> The fix disables expansion-to-defined warning for gcc. Thanks. ------------- Commit messages: - 8307569: Build with gcc8 is broken after JDK-8307301 Changes: https://git.openjdk.org/jdk/pull/13850/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13850&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307569 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13850.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13850/head:pull/13850 PR: https://git.openjdk.org/jdk/pull/13850 From jiefu at openjdk.org Sat May 6 01:41:11 2023 From: jiefu at openjdk.org (Jie Fu) Date: Sat, 6 May 2023 01:41:11 GMT Subject: RFR: 8307569: Build with gcc8 is broken after JDK-8307301 [v2] In-Reply-To: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> References: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> Message-ID: > The fix disables expansion-to-defined warning for gcc. > Thanks. Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Add comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13850/files - new: https://git.openjdk.org/jdk/pull/13850/files/99d77204..064271e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13850&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13850&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13850.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13850/head:pull/13850 PR: https://git.openjdk.org/jdk/pull/13850 From jiefu at openjdk.org Sat May 6 01:45:12 2023 From: jiefu at openjdk.org (Jie Fu) Date: Sat, 6 May 2023 01:45:12 GMT Subject: RFR: 8307569: Build with gcc8 is broken after JDK-8307301 [v2] In-Reply-To: References: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> Message-ID: On Sat, 6 May 2023 01:41:11 GMT, Jie Fu wrote: >> The fix disables expansion-to-defined warning for gcc. >> Thanks. > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Add comment It failed with gcc8 & gcc9, but passed with gcc10+. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13850#issuecomment-1536971053 From azvegint at openjdk.org Sat May 6 02:19:28 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Sat, 6 May 2023 02:19:28 GMT Subject: Integrated: 8306941: Open source several datatransfer and dnd AWT tests In-Reply-To: References: Message-ID: On Fri, 5 May 2023 16:54:20 GMT, Alexander Zvegintsev wrote: > Open sourcing few more tests: > > > java/awt/datatransfer/MimeFormatsTest/MimeFormatsTest.java > java/awt/datatransfer/RemoveFlavorListenerTest/RemoveFlavorListenerTest.java > java/awt/dnd/AutoscrollStopTest/AutoscrollStopTest.java > java/awt/dnd/ButtonReleaseTest/ButtonReleaseTest.java > > > Testing looks good. This pull request has now been integrated. Changeset: 3d3eaed9 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/3d3eaed9133dbe728ca8e00a626d33f7e35ba9ff Stats: 831 lines in 4 files changed: 831 ins; 0 del; 0 mod 8306941: Open source several datatransfer and dnd AWT tests Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13836 From achung at openjdk.org Sat May 6 03:14:32 2023 From: achung at openjdk.org (Alisen Chung) Date: Sat, 6 May 2023 03:14:32 GMT Subject: RFR: 8306881: Update FreeType to 2.13.0 [v2] In-Reply-To: References: Message-ID: <5maRLT6sj8N_1WNBlIkHsRHP8zLmcmgZkgdQB1xvjJY=.cbb41bfc-bcbb-431c-8d1a-b89905c7e08f@github.com> > update freetype version to 2.13, all tests passed Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: readd spaces to comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13841/files - new: https://git.openjdk.org/jdk/pull/13841/files/6c08c796..568ebd0f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13841&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13841&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13841.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13841/head:pull/13841 PR: https://git.openjdk.org/jdk/pull/13841 From duke at openjdk.org Mon May 8 01:38:22 2023 From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=) Date: Mon, 8 May 2023 01:38:22 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v2] In-Reply-To: References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> Message-ID: On Thu, 16 Mar 2023 08:33:35 GMT, ??? wrote: >> Candidat box can moving with caret on windows version. Someone must wrote codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. Why it doesn't work, is the key problem. >> >> 1, I wrote a example for linux: >> https://github.com/quantum6/X11InputMethod >> >> I tried all parameters to test and as my research: >> If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret. >> If you use XIMPreeditNothing, it works. >> All examples use XIMPreeditCallbacks to initiate input method and candidate box can't moving. So I understand why he didn't commit the codes. >> >> 2, I traced the route of transfering caret coordites on windows version, then add codes for linux. >> 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested for a long time, it works OK. >> 4, I am not sure for AIX( no environment). >> >> >> JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea >> Type: Bug >> Component: client-libs >> Sub-Component: java.awt:i18n >> Affected Version: 8,9,15,16 >> Priority: P3 >> Status: Open >> Resolution: Unresolved >> OS: linux >> CPU: x86_64 > > ??? has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit: > > 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea There are several bugs same to this. I hope this code can be integrated ASAP. Good luck! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1537619523 From sgehwolf at openjdk.org Mon May 8 08:52:27 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 8 May 2023 08:52:27 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7] In-Reply-To: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> References: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> Message-ID: On Fri, 5 May 2023 16:52:22 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace error in make/StaticJvmLibsImage.gmk. Seems fine to me, but I'm not an expert in on the build files. Thanks for the implementing the suggestion. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1416396939 From sgehwolf at openjdk.org Mon May 8 09:00:22 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 8 May 2023 09:00:22 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7] In-Reply-To: References: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> Message-ID: <2BVvV9m8bI-UzZXpX1GEPwoStZ6pHZBn4JuAMRQk978=.54246fe4-57b8-4372-bfc4-6b63823fa9a2@github.com> On Fri, 5 May 2023 20:43:41 GMT, Erik Joelsson wrote: > All of that said, I think we can get away with a smaller subset of targets and deliverables. AFAIK, graal needs the combined `graal-builder-image` as input to their build anyway, so they should not have any dependency on what the target `static-libs-image` produces. Given that I propose the following behavior: > > `make static-libs-image` produces `images/static-libs` with all .a (including libjvm.a). `make static-libs-graal-image` produces `images/static-libs-graal` with all .a except libjvm.a. `make graal-builder-image` produces `images/graal-builder-image` like today, but depends on and uses `static-libs-graal-image` instead of `static-libs-image`. `make static-libs-bundles` depends on and uses `static-libs-image` like today, so will contain libjvm.a, which is new behavior. Sure, that should work too as long as there is a way to a) build the static libs only needed for graal some way b) keep `graal-builder-image` working as it does today. FWIW, we use `a)` at adoptium so as to be able to have a combination to build mandrel from. Not all users will want to have JDK + static libs so only the ones needing them should need to download them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1538008209 From abhiscxk at openjdk.org Mon May 8 09:33:40 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 8 May 2023 09:33:40 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v2] In-Reply-To: References: Message-ID: > This PR is to open source JMenuItem related swing tests. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Review comment update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13822/files - new: https://git.openjdk.org/jdk/pull/13822/files/ce55aebe..172ae128 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13822&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13822&range=00-01 Stats: 204 lines in 4 files changed: 61 ins; 56 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/13822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13822/head:pull/13822 PR: https://git.openjdk.org/jdk/pull/13822 From abhiscxk at openjdk.org Mon May 8 09:33:43 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 8 May 2023 09:33:43 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v2] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 18:03:12 GMT, Phil Race wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment update > > test/jdk/javax/swing/JMenuItem/bug4304129.java line 47: > >> 45: public static void main(String args[]) throws Exception { >> 46: bug4304129 test = new bug4304129(); >> 47: test.init(); > > I don't see why we need an instance here. > The body of init() can be moved into main() and mnemonic and accelerator made static Updated. > test/jdk/javax/swing/JMenuItem/bug4839464.java line 79: > >> 77: public static JButton changeShortDescButton; >> 78: >> 79: public JMenuItem item; > > it seems a bit odd that this and some below are instance vars and the ones above are static > > Should you make them all static ?.. and then you don't need an instance of the test class either > Or make them all instance .. either way ... > > I also find it odd that this test creates TWO Robots - one AWT Robot and one JRobot. > Can you consolidate these ? Updated. > test/jdk/javax/swing/JMenuItem/bug4966168.java line 46: > >> 44: public static void main(String args[]) throws Exception { >> 45: bug4966168 test = new bug4966168(); >> 46: test.init(); > > No need I can see for the instance. Collapse init() into main() Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1187232377 PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1187232672 PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1187232953 From abhiscxk at openjdk.org Mon May 8 09:33:44 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 8 May 2023 09:33:44 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v2] In-Reply-To: References: Message-ID: <1FxCaqch79WSpXwnBqYKm8Jyw7D26smmwIVopqsa1AQ=.2f866488-d590-4ebf-aaf8-731db6718a8e@github.com> On Sat, 6 May 2023 00:17:01 GMT, Damon Nguyen wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment update > > test/jdk/javax/swing/JMenuItem/bug4839464.java line 29: > >> 27: @summary Shortcoming in the way JMenuItem handles 'propertyChange()' events. >> 28: @library ../../regtesthelpers >> 29: @build Util JRobot > > I see Util is added but I don't see any Util methods used. Is this needed? > > Also, did you try running this test after moving it to open? I think you get an error with this ```regtesthelpers``` path since you removed the individual directories for each of these tests and placed them directly into the ```JMenuItem``` dir. @DamonGuy @honkar-jdk Thanks for pointing out. I missed to run in open. Updated the tests and these tags are removed as they are of no longer use. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1187233885 From mbaesken at openjdk.org Mon May 8 10:38:27 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 May 2023 10:38:27 GMT Subject: RFR: JDK-8307604: gcc12 based Alpine build broken build after JDK-8307301 Message-ID: After the harfbuzz 7.2 update we run into /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, | ^~~~~~~~~~ /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; | ^~~~~~~~~~~~ /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, | ^~~~~~~~~~ /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; We use gcc12 on Alpine. Switching off this 'warning as error' fixes the issue. ------------- Commit messages: - JDK-8307604 Changes: https://git.openjdk.org/jdk/pull/13859/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13859&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307604 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13859.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13859/head:pull/13859 PR: https://git.openjdk.org/jdk/pull/13859 From mbaesken at openjdk.org Mon May 8 10:52:32 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 May 2023 10:52:32 GMT Subject: RFR: JDK-8307603: [AIX] Broken build after JDK-8307301 Message-ID: <28ESZhtKLtHIOVrIa-4pUrzhV13kSu6Fkg87C27NPhI=.212b653f-b9f2-40f2-b5c4-37c86f2003fb@github.com> The AIX build is broken after [JDK-8307301](https://bugs.openjdk.org/browse/JDK-8307301) which updated harfbuzz to 7.2 . This was expected because an older AIX workaround was removed. Bringing back the AIX workaround solves the issue. ------------- Commit messages: - JDK-8307603 Changes: https://git.openjdk.org/jdk/pull/13861/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13861&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307603 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13861.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13861/head:pull/13861 PR: https://git.openjdk.org/jdk/pull/13861 From lucy at openjdk.org Mon May 8 11:38:14 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Mon, 8 May 2023 11:38:14 GMT Subject: RFR: JDK-8307604: gcc12 based Alpine build broken build after JDK-8307301 In-Reply-To: References: Message-ID: <12Hjj2DVxLGHSB-LcyczzLrqrD3gvH1RyTM3A-JPAvg=.da0c013c-cdd8-4399-9c08-186aa9e10b06@github.com> On Mon, 8 May 2023 10:29:56 GMT, Matthias Baesken wrote: > After the harfbuzz 7.2 update we run into > > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > | ^~~~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > > We use gcc12 on Alpine. > Switching off this 'warning as error' fixes the issue. LGTM. Disabling the warning is OK for now. Issue should be fixed by HarfBuzz. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13859#pullrequestreview-1416631184 From mdoerr at openjdk.org Mon May 8 12:14:29 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 8 May 2023 12:14:29 GMT Subject: RFR: JDK-8307603: [AIX] Broken build after JDK-8307301 In-Reply-To: <28ESZhtKLtHIOVrIa-4pUrzhV13kSu6Fkg87C27NPhI=.212b653f-b9f2-40f2-b5c4-37c86f2003fb@github.com> References: <28ESZhtKLtHIOVrIa-4pUrzhV13kSu6Fkg87C27NPhI=.212b653f-b9f2-40f2-b5c4-37c86f2003fb@github.com> Message-ID: On Mon, 8 May 2023 10:45:00 GMT, Matthias Baesken wrote: > The AIX build is broken after [JDK-8307301](https://bugs.openjdk.org/browse/JDK-8307301) which updated harfbuzz to 7.2 . > This was expected because an older AIX workaround was removed. > Bringing back the AIX workaround solves the issue. Looks good and trivial. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13861#pullrequestreview-1416680724 From mbaesken at openjdk.org Mon May 8 12:27:31 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 May 2023 12:27:31 GMT Subject: RFR: JDK-8307603: [AIX] Broken build after JDK-8307301 In-Reply-To: <28ESZhtKLtHIOVrIa-4pUrzhV13kSu6Fkg87C27NPhI=.212b653f-b9f2-40f2-b5c4-37c86f2003fb@github.com> References: <28ESZhtKLtHIOVrIa-4pUrzhV13kSu6Fkg87C27NPhI=.212b653f-b9f2-40f2-b5c4-37c86f2003fb@github.com> Message-ID: <-IjnYBuMpbuUgytriuR2cphMgyNYGpU5RXmW81eI5oU=.c0c17772-a12c-40d1-83e2-7a1e9d5c0b05@github.com> On Mon, 8 May 2023 10:45:00 GMT, Matthias Baesken wrote: > The AIX build is broken after [JDK-8307301](https://bugs.openjdk.org/browse/JDK-8307301) which updated harfbuzz to 7.2 . > This was expected because an older AIX workaround was removed. > Bringing back the AIX workaround solves the issue. Hi Martin, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13861#issuecomment-1538272404 From mbaesken at openjdk.org Mon May 8 12:27:32 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 May 2023 12:27:32 GMT Subject: Integrated: JDK-8307603: [AIX] Broken build after JDK-8307301 In-Reply-To: <28ESZhtKLtHIOVrIa-4pUrzhV13kSu6Fkg87C27NPhI=.212b653f-b9f2-40f2-b5c4-37c86f2003fb@github.com> References: <28ESZhtKLtHIOVrIa-4pUrzhV13kSu6Fkg87C27NPhI=.212b653f-b9f2-40f2-b5c4-37c86f2003fb@github.com> Message-ID: On Mon, 8 May 2023 10:45:00 GMT, Matthias Baesken wrote: > The AIX build is broken after [JDK-8307301](https://bugs.openjdk.org/browse/JDK-8307301) which updated harfbuzz to 7.2 . > This was expected because an older AIX workaround was removed. > Bringing back the AIX workaround solves the issue. This pull request has now been integrated. Changeset: bb3e44d8 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/bb3e44d8b604b4e3facc4f49f625cc0b7ff2abd7 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8307603: [AIX] Broken build after JDK-8307301 Reviewed-by: mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/13861 From mdoerr at openjdk.org Mon May 8 13:26:16 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 8 May 2023 13:26:16 GMT Subject: RFR: JDK-8307604: gcc12 based Alpine build broken build after JDK-8307301 In-Reply-To: References: Message-ID: On Mon, 8 May 2023 10:29:56 GMT, Matthias Baesken wrote: > After the harfbuzz 7.2 update we run into > > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > | ^~~~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > > We use gcc12 on Alpine. > Switching off this 'warning as error' fixes the issue. It's always unfortunate if we have to disable warnings, but I'm not aware of a better solution. Changing the harfbuzz code should be done upstream (in the harfbuzz repo). ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13859#pullrequestreview-1416794665 From erikj at openjdk.org Mon May 8 13:32:14 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 May 2023 13:32:14 GMT Subject: RFR: 8307569: Build with gcc8 is broken after JDK-8307301 [v2] In-Reply-To: References: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> Message-ID: On Sat, 6 May 2023 01:41:11 GMT, Jie Fu wrote: >> The fix disables expansion-to-defined warning for gcc. >> Thanks. > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Add comment Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13850#pullrequestreview-1416808334 From jiefu at openjdk.org Mon May 8 13:41:16 2023 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 8 May 2023 13:41:16 GMT Subject: RFR: 8307569: Build with gcc8 is broken after JDK-8307301 [v2] In-Reply-To: References: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> Message-ID: <2Ogud9_skvVWZMLtBHwOhycSrV5PINikC0pJ3qI7X58=.13d0fc69-8f19-4519-9daa-1941aacc2a7e@github.com> On Mon, 8 May 2023 13:29:26 GMT, Erik Joelsson wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment > > Marked as reviewed by erikj (Reviewer). Thanks @erikj79 for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13850#issuecomment-1538378087 From erikj at openjdk.org Mon May 8 13:56:22 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 May 2023 13:56:22 GMT Subject: RFR: JDK-8307604: gcc12 based Alpine build broken build after JDK-8307301 In-Reply-To: References: Message-ID: On Mon, 8 May 2023 10:29:56 GMT, Matthias Baesken wrote: > After the harfbuzz 7.2 update we run into > > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > | ^~~~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > > We use gcc12 on Alpine. > Switching off this 'warning as error' fixes the issue. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13859#pullrequestreview-1416851881 From jiefu at openjdk.org Mon May 8 14:02:34 2023 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 8 May 2023 14:02:34 GMT Subject: Integrated: 8307569: Build with gcc8 is broken after JDK-8307301 In-Reply-To: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> References: <4Q1rajZAC5iFfiSOvXZvftLEliJc4nkVA_OStjQV-P4=.78709cff-a5c7-4fb7-adf9-603a7aac9db4@github.com> Message-ID: On Sat, 6 May 2023 01:14:50 GMT, Jie Fu wrote: > The fix disables expansion-to-defined warning for gcc. > Thanks. This pull request has now been integrated. Changeset: 64c09628 Author: Jie Fu URL: https://git.openjdk.org/jdk/commit/64c09628664fd19c281723f15bf677c52e360acd Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8307569: Build with gcc8 is broken after JDK-8307301 Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/13850 From mbaesken at openjdk.org Mon May 8 14:07:15 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 May 2023 14:07:15 GMT Subject: RFR: JDK-8307604: gcc12 based Alpine build broken build after JDK-8307301 In-Reply-To: References: Message-ID: On Mon, 8 May 2023 10:29:56 GMT, Matthias Baesken wrote: > After the harfbuzz 7.2 update we run into > > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > | ^~~~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > > We use gcc12 on Alpine. > Switching off this 'warning as error' fixes the issue. Hi Erik, Lucy and Martin , thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13859#issuecomment-1538417029 From mbaesken at openjdk.org Mon May 8 14:19:30 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 8 May 2023 14:19:30 GMT Subject: Integrated: JDK-8307604: gcc12 based Alpine build broken build after JDK-8307301 In-Reply-To: References: Message-ID: On Mon, 8 May 2023 10:29:56 GMT, Matthias Baesken wrote: > After the harfbuzz 7.2 update we run into > > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > | ^~~~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8: error: offset '4' outside bounds of constant string [-Werror=array-bounds] > 281 | bool get_points (hb_font_t *font, const accelerator_t &glyf_accelerator, > | ^~~~~~~~~~ > /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/hb-static.cc:45:16: note: '_hb_NullPool' declared here > 45 | uint64_t const _hb_NullPool[(HB_NULL_POOL_SIZE + sizeof (uint64_t) - 1) / sizeof (uint64_t)] = {}; > > We use gcc12 on Alpine. > Switching off this 'warning as error' fixes the issue. This pull request has now been integrated. Changeset: d2e0e534 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/d2e0e534d7e391dd633fb9ff671900f8060b6d49 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8307604: gcc12 based Alpine build broken build after JDK-8307301 Reviewed-by: lucy, mdoerr, erikj ------------- PR: https://git.openjdk.org/jdk/pull/13859 From aivanov at openjdk.org Mon May 8 15:52:23 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 8 May 2023 15:52:23 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 12:58:58 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > Noticed this test case not verifying all the cases which is intended. Modified it for improving the coverage for 3 type of popups (menu, context menu and combobox). > > Evaluating conditions: > 1. Not enough space for showing popup downwards(default layout), it should show upwards > 2. Window starts from negative position, Popup should show on visible area > > For achieving this following areas are modified > - Updated isPopupOnScreen by adding Additional checks (like the position of combobox popup is always verified) > - Menu creation made as function and reused for all menu creation. > - Updated ComboPopupCheckListener class and modified its popupMenuWillBecomeInvisible function. Made it as generic and it is capable to evaluate any combo box's position if this class set as its listener. > - This test case is not intended for multi monitor setup so added a check for identifying monitor, else error out. > - Updated CTRL_MASK to CTRL_DOWN_MASK for removing depreciation warnings and removed some other warnings. > > Please review this > > Regards, > Renjith. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13578#pullrequestreview-1417058142 From dnguyen at openjdk.org Mon May 8 16:26:15 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 8 May 2023 16:26:15 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 09:33:40 GMT, Abhishek Kumar wrote: >> This PR is to open source JMenuItem related swing tests. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update Marked as reviewed by dnguyen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13822#pullrequestreview-1417112202 From dnguyen at openjdk.org Mon May 8 16:26:17 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 8 May 2023 16:26:17 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v2] In-Reply-To: References: Message-ID: On Sat, 6 May 2023 00:31:37 GMT, Harshitha Onkar wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment update > > test/jdk/javax/swing/JMenuItem/bug4839464.java line 220: > >> 218: // Check mnemonics >> 219: int tmpInt = item.getMnemonic(); >> 220: robo.clickMouseOn(changeMnemonicButton); > > @DamonGuy Util's JRobot is used here. Which part is a Util method? I see a JRobot method. Or is Util and JRobot linked somehow? My understanding is that they're separate since they're separate in regtesthelpers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1187638323 From djelinski at openjdk.org Mon May 8 17:36:47 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 8 May 2023 17:36:47 GMT Subject: RFR: 8305321: Remove unused exports in java.desktop [v2] In-Reply-To: <5iIFg0d_PiJrYfcyLUbZmxZPfu9iuN5aOqxPpsWvt_I=.732a59c0-ec31-4a7b-a257-49a3f7c4f467@github.com> References: <5iIFg0d_PiJrYfcyLUbZmxZPfu9iuN5aOqxPpsWvt_I=.732a59c0-ec31-4a7b-a257-49a3f7c4f467@github.com> Message-ID: > Please review this patch that removes a number of unused exports from java.desktop native libraries. > > In most cases I removed JNIEXPORT from methods and variables that are only used within a single shared library. Other than that: > - removed `getSunFontIDs` that was reportedly used by rasterizer; as far as I could tell, rasterizer project is dead now, but if that's incorrect I can restore that export. > - removed `colorValueID` in X11Color; that field was not used. > - removed `J2dTraceInit` from header file. That method is only used internally by `J2dTraceImpl`. > > The methods `Transform_GetInfo` and `Transform_transform` are declared in GraphicsPrimitiveMgr, but are only used in TransformHelper. Let me know if I should move them to where they are used. > > The method `img_makePalette`, currently located in `share/native/libawt/awt/image/cvutils/img_colors.c`, is only used by `unix/native/common/awt/X11Color.c`; it could be moved to the same directory to avoid exporting the method from libawt. The files `img_colors.[ch]` do not have any references to other files in `cvutils`. > > Manually verified that the exports are no longer present after these changes. Tier1-3 and client libs tests still pass. Daniel Jeli?ski 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 since the last revision: - Merge remote-tracking branch 'origin' into desktop-exports - Make J2dTraceInit static - Remove unnecessary exports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13261/files - new: https://git.openjdk.org/jdk/pull/13261/files/5f255b6d..02b46a5c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13261&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13261&range=00-01 Stats: 337960 lines in 3525 files changed: 280898 ins; 34663 del; 22399 mod Patch: https://git.openjdk.org/jdk/pull/13261.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13261/head:pull/13261 PR: https://git.openjdk.org/jdk/pull/13261 From dnguyen at openjdk.org Mon May 8 17:59:39 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 8 May 2023 17:59:39 GMT Subject: Integrated: 8307165: java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java timed out In-Reply-To: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> References: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> Message-ID: <9sOTColuktrL7YTosPPs4jWhSSE6U9OTHz_6XZb5aD0=.13adc646-6095-41e9-ba59-8d1235f570cd@github.com> On Tue, 2 May 2023 20:46:00 GMT, Damon Nguyen wrote: > When converting this test to be applicable to be open sourced, changes were made. I reverted some of these changes to get the test stable again. Now it passes when run on various OS's 100x. This pull request has now been integrated. Changeset: 14df5c13 Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/14df5c130e5bf5139e3e2ef6d7b9d64883d94d18 Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod 8307165: java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java timed out Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13761 From tr at openjdk.org Mon May 8 18:05:59 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 8 May 2023 18:05:59 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v2] In-Reply-To: References: Message-ID: <3j4se4PxZQeOAEGlftu1DglKSWYQ_9cjIisP3ygOoI0=.5ecf40ed-ed05-4b62-9145-2cd13eb4785c@github.com> > Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13828/files - new: https://git.openjdk.org/jdk/pull/13828/files/e396cbfa..e7d0a3ac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13828&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13828&range=00-01 Stats: 49 lines in 3 files changed: 1 ins; 7 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/13828.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13828/head:pull/13828 PR: https://git.openjdk.org/jdk/pull/13828 From serb at openjdk.org Mon May 8 18:26:16 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 8 May 2023 18:26:16 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Tue, 2 May 2023 14:59:11 GMT, Alexey Ivanov wrote: > It may be useful to be able to run Java on previous versions though, yet it's not a priority. Then probably it is better to add a fallback since that method was added to the win 10 after GA, and it does not exist in the early version. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1187749971 From serb at openjdk.org Mon May 8 18:29:28 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 8 May 2023 18:29:28 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Tue, 2 May 2023 15:02:37 GMT, Alexey Ivanov wrote: >> src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 280: >> >>> 278: readLock.lock(); >>> 279: try { >>> 280: return getPoint(getTheme(widget, defaultDPI), part, state, property); >> >> Why does everything else use defaultDPI, is it possible that some values depend on the DPI? > >> Why does everything else use defaultDPI, is it possible that some values depend on the DPI? > > Because Swing's user space coordinates use the default 96dpi. Some values do depend on the DPI, yet layout code still uses the default DPI. Then that layout code will be broken if layout will be calculated on already visible component, I guess it should take into account the GC where the component is located. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1187753707 From rmahajan at openjdk.org Mon May 8 18:33:22 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Mon, 8 May 2023 18:33:22 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Mon, 8 May 2023 18:26:37 GMT, Sergey Bylokhov wrote: >>> Why does everything else use defaultDPI, is it possible that some values depend on the DPI? >> >> Because Swing's user space coordinates use the default 96dpi. Some values do depend on the DPI, yet layout code still uses the default DPI. > > Then that layout code will be broken if layout will be calculated on already visible component, I guess it should take into account the GC where the component is located. What is GC ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1187757249 From serb at openjdk.org Mon May 8 18:38:32 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 8 May 2023 18:38:32 GMT Subject: RFR: JDK-8307128: Open source some drag and drop tests 4 In-Reply-To: References: Message-ID: On Tue, 2 May 2023 22:09:18 GMT, Alisen Chung wrote: > added DnD tests test/jdk/java/awt/dnd/MouseExitGestureTriggerTest.java line 107: > 105: Thread.sleep(RECOGNITION_TIMEOUT); > 106: > 107: if (recognized) { This field is set on EDT, and used here on main w/o synchronization. test/jdk/java/awt/dnd/MozillaDnDTest.java line 177: > 175: public void start() { > 176: // Solaris/Linux-only test > 177: if (System.getProperty("os.name").startsWith("Windows")) { Can we use OSInfo here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13765#discussion_r1187757373 PR Review Comment: https://git.openjdk.org/jdk/pull/13765#discussion_r1187758000 From serb at openjdk.org Mon May 8 18:40:25 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 8 May 2023 18:40:25 GMT Subject: RFR: JDK-8307083: Open source some drag and drop tests 3 [v2] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 18:35:05 GMT, Alisen Chung wrote: >> moving tests to open > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/java/awt/dnd/MissedDragEnterTest.java > > Co-authored-by: Andrey Turbanov test/jdk/java/awt/dnd/MissedDragEnterTest.java line 250: > 248: > 249: public boolean getResult() { > 250: return passed; Does we use this field on EDT and main threads? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13764#discussion_r1187762718 From achung at openjdk.org Mon May 8 18:41:36 2023 From: achung at openjdk.org (Alisen Chung) Date: Mon, 8 May 2023 18:41:36 GMT Subject: RFR: 8307130: Open source few Swing JMenu tests [v2] In-Reply-To: References: Message-ID: On Sat, 6 May 2023 00:50:33 GMT, Damon Nguyen wrote: >> Open source few Swing JMenu tests > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Add Util. Change helper path test/jdk/javax/swing/JMenu/bug5013739.java line 85: > 83: robo.delay(1000); > 84: } finally { > 85: SwingUtilities.invokeAndWait(() -> mainFrame.dispose()); probably doesn't matter, but should this check if mainFrame != null? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13839#discussion_r1187762034 From aivanov at openjdk.org Mon May 8 18:44:14 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 8 May 2023 18:44:14 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Mon, 8 May 2023 18:30:36 GMT, Rajat Mahajan wrote: > What is GC ? I guess Graphics Configuration. > Then that layout code will be broken if layout will be calculated on already visible component, I guess it should take into account the GC where the component is located. It works fine to the best of Rajat's and my testing because the layout doesn't change. The ?icons? don't scale progressively, Windows returns the same size for many DPI values, Swing scales the pixels up, this fact is taken into account when rendering the theme image to avoid additional transformations. Changing the preferred size dynamically based on the current DPI of the monitor could be a better way in the long term. Dropping `CachedPainter` from the DPI-aware rendering path of the themes is also on the table. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1187767163 From serb at openjdk.org Mon May 8 18:45:22 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 8 May 2023 18:45:22 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: On Fri, 5 May 2023 14:58:15 GMT, Alexander Zvegintsev wrote: > It seems that the current robot API is not suitable for this. Can we just reset the token when we create a new instance of Robot? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1538859204 From aivanov at openjdk.org Mon May 8 18:49:25 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 8 May 2023 18:49:25 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Mon, 8 May 2023 18:22:31 GMT, Sergey Bylokhov wrote: > > It may be useful to be able to run Java on previous versions though, yet it's not a priority. > > Then probably it is better to add a fallback since that method was added to the win 10 after GA, and it does not exist in the early version. But the earlier versions of Windows 10 are already unsupported, including the one where the `OpenThemeDataForDpi` function was added. If required, the fallback could be implemented under a new bug. Anyway, I don't have a strong opinion on this matter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1187775491 From dnguyen at openjdk.org Mon May 8 18:58:38 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 8 May 2023 18:58:38 GMT Subject: RFR: 8307130: Open source few Swing JMenu tests [v3] In-Reply-To: References: Message-ID: > Open source few Swing JMenu tests Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Add null check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13839/files - new: https://git.openjdk.org/jdk/pull/13839/files/1d2ccd19..d7dbe614 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13839&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13839&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13839/head:pull/13839 PR: https://git.openjdk.org/jdk/pull/13839 From dnguyen at openjdk.org Mon May 8 18:58:40 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 8 May 2023 18:58:40 GMT Subject: RFR: 8307130: Open source few Swing JMenu tests [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 18:36:08 GMT, Alisen Chung wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Add Util. Change helper path > > test/jdk/javax/swing/JMenu/bug5013739.java line 85: > >> 83: robo.delay(1000); >> 84: } finally { >> 85: SwingUtilities.invokeAndWait(() -> mainFrame.dispose()); > > probably doesn't matter, but should this check if mainFrame != null? I agree it shouldn't matter here. I added it anyway ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13839#discussion_r1187780486 From jiangli at openjdk.org Mon May 8 19:48:23 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 8 May 2023 19:48:23 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7] In-Reply-To: <2BVvV9m8bI-UzZXpX1GEPwoStZ6pHZBn4JuAMRQk978=.54246fe4-57b8-4372-bfc4-6b63823fa9a2@github.com> References: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> <2BVvV9m8bI-UzZXpX1GEPwoStZ6pHZBn4JuAMRQk978=.54246fe4-57b8-4372-bfc4-6b63823fa9a2@github.com> Message-ID: On Mon, 8 May 2023 08:57:37 GMT, Severin Gehwolf wrote: > > All of that said, I think we can get away with a smaller subset of targets and deliverables. AFAIK, graal needs the combined `graal-builder-image` as input to their build anyway, so they should not have any dependency on what the target `static-libs-image` produces. Given that I propose the following behavior: > > `make static-libs-image` produces `images/static-libs` with all .a (including libjvm.a). `make static-libs-graal-image` produces `images/static-libs-graal` with all .a except libjvm.a. `make graal-builder-image` produces `images/graal-builder-image` like today, but depends on and uses `static-libs-graal-image` instead of `static-libs-image`. `make static-libs-bundles` depends on and uses `static-libs-image` like today, so will contain libjvm.a, which is new behavior. > > Sure, that should work too as long as there is a way to a) build the static libs only needed for graal some way b) keep `graal-builder-image` working as it does today. FWIW, we use `a)` at adoptium so as to be able to have a combination to build mandrel from. Not all users will want to have JDK + static libs so only the ones needing them should need to download them. Thanks @erikj79 @jerboaa. We can go with what @erikj79 suggested then. I'll revise the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1538945606 From dnguyen at openjdk.org Mon May 8 19:56:19 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 8 May 2023 19:56:19 GMT Subject: RFR: 8306881: Update FreeType to 2.13.0 [v2] In-Reply-To: <5maRLT6sj8N_1WNBlIkHsRHP8zLmcmgZkgdQB1xvjJY=.cbb41bfc-bcbb-431c-8d1a-b89905c7e08f@github.com> References: <5maRLT6sj8N_1WNBlIkHsRHP8zLmcmgZkgdQB1xvjJY=.cbb41bfc-bcbb-431c-8d1a-b89905c7e08f@github.com> Message-ID: On Sat, 6 May 2023 03:14:32 GMT, Alisen Chung wrote: >> update freetype version to 2.13, all tests passed > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > readd spaces to comments md file overall looks fine to me so far src/java.desktop/share/native/libfreetype/include/freetype/internal/ftmmtypes.h line 18: > 16: * understand and accept it fully. > 17: * > 18: */ Is this the only new file being added? ------------- PR Review: https://git.openjdk.org/jdk/pull/13841#pullrequestreview-1417413875 PR Review Comment: https://git.openjdk.org/jdk/pull/13841#discussion_r1187833271 From achung at openjdk.org Mon May 8 20:37:44 2023 From: achung at openjdk.org (Alisen Chung) Date: Mon, 8 May 2023 20:37:44 GMT Subject: RFR: 8307297: Move some DnD tests to open [v3] In-Reply-To: References: Message-ID: > Adding some DnD tests Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: fix space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13756/files - new: https://git.openjdk.org/jdk/pull/13756/files/c2451e28..7d514e47 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13756&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13756&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13756/head:pull/13756 PR: https://git.openjdk.org/jdk/pull/13756 From jiangli at openjdk.org Mon May 8 21:00:24 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 8 May 2023 21:00:24 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7] In-Reply-To: References: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> Message-ID: <0wRYu-_MAO2LH1Xgl-icgILa9rL6PnDEsZv4sjCpY6c=.54e81c63-ccd8-43ad-88cf-e16ba0452cdd@github.com> On Fri, 5 May 2023 20:43:41 GMT, Erik Joelsson wrote: > Further I would like to suggest that libjvm.a gets put in the variant subdir under lib, just like libjvm.so does today (e.g. `lib/server/libjvm.a`). That way you can support building libjvm.a for all variants without worry. It will also get libjvm.a out of the way to cause less trouble for a graal build that uses the static-libs-bundles as input. This goes against what I suggested before, to just use `JVM_VARIANT_MAIN`, but I think this makes for a cleaner long term solution given the goals of the hermetic java effort. There are some complications related to `jvm.cfg` and `libjvm.so` path runtime handling for JVM variants support, with the JDK traditional/dynamic build. With JDK static support, the usage of `libjvm` is fully determined at build time, runtime can avoid the complications and associated overhead with accessing `jvm.cfg` and determining `libjvm` path. At the final static image build time users need to know the sub-directory containing `libjvm.a`, if we go with the suggestion. That adds a small complication. However, from broader point of view there are probably more benefits to do so. I'll change the PR, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1539037862 From dnguyen at openjdk.org Mon May 8 22:33:23 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 8 May 2023 22:33:23 GMT Subject: Integrated: 8307130: Open source few Swing JMenu tests In-Reply-To: References: Message-ID: <7cKgH28k0yXLSeoSqj1yx5Puls47GdJFNqGs7_ZPu2A=.efe6b4e7-f307-40a5-9aa7-92ba42aa8770@github.com> On Fri, 5 May 2023 17:41:26 GMT, Damon Nguyen wrote: > Open source few Swing JMenu tests This pull request has now been integrated. Changeset: d9052b94 Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/d9052b946682d1c0f2629455d73fe4e6b95b29db Stats: 293 lines in 4 files changed: 293 ins; 0 del; 0 mod 8307130: Open source few Swing JMenu tests Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13839 From rmahajan at openjdk.org Mon May 8 22:43:12 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Mon, 8 May 2023 22:43:12 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: > Problem: > > Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: > > - Scrawly ticks in checkboxes; > - Wrong circle relations in selected radio buttons. > > Root-cause: > We open theme on AWT Toolkit Window which always has Primary Monitor DPI. > Due to this when the app window goes to Secondary Screen with different DPI UI buttons > appear incorrectly rendered. > Following is a list proposed changes to fix this issue. > > > Proposed Fix with Summary of changes: > > 1. Open a new Theme Handle per the DPI of the Screen where the App window is. > --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. > window is. > > 2. GetPartSize() of icons returns size based on standard size = 96 DPI. > --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. > > 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. > -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. > > 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. > --> This helps make sure that for .25s scaling we get better rendering. > This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. > > As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. > > > Testing: > > Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. > > ___________________________________ > Monitor 1 | Monitor 2 > (Primary) | > | > 125% | 175% > 150% | 175% > 150% | 225% > 175% | 175% > 175% | 150% > 175% | 225% > _____________________ |_____________ > > Also tested on setup with scaling values of up-to 350%. Rajat Mahajan has updated the pull request incrementally with two additional commits since the last revision: - code cleanup as per suggestions from reviewers - code cleanup from suggestions in code review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13701/files - new: https://git.openjdk.org/jdk/pull/13701/files/62dc3acc..60839780 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=00-01 Stats: 65 lines in 3 files changed: 29 ins; 13 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/13701.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701 PR: https://git.openjdk.org/jdk/pull/13701 From serb at openjdk.org Mon May 8 23:36:19 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 8 May 2023 23:36:19 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Mon, 8 May 2023 18:41:45 GMT, Alexey Ivanov wrote: >> What is GC ? > >> What is GC ? > > I guess Graphics Configuration. > >> Then that layout code will be broken if layout will be calculated on already visible component, I guess it should take into account the GC where the component is located. > > It works fine to the best of Rajat's and my testing because the layout doesn't change. The ?icons? don't scale progressively, Windows returns the same size for many DPI values, Swing scales the pixels up, this fact is taken into account when rendering the theme image to avoid additional transformations. > > Changing the preferred size dynamically based on the current DPI of the monitor could be a better way in the long term. Dropping `CachedPainter` from the DPI-aware rendering path of the themes is also on the table. We already changed the preferred size dynamically for most of the components, since the size depends on the fonts and the fonts depends on the GC, see: https://hg.openjdk.org/jdk/jdk11/rev/55a43beaa529 https://hg.openjdk.org/jdk/jdk/rev/ea50ef230511 https://github.com/openjdk/jdk/commit/11aadc9d98d364b91114c028c7e2eff8de2f2bf0 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1187985627 From serb at openjdk.org Mon May 8 23:36:17 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 8 May 2023 23:36:17 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Thu, 4 May 2023 19:35:32 GMT, Rajat Mahajan wrote: >> src/java.desktop/share/classes/sun/swing/CachedPainter.java line 318: >> >>> 316: public Image getResolutionVariant(double destWidth, double destHeight) { >>> 317: int w = (int) Math.floor(destWidth + 0.5); >>> 318: int h = (int) Math.floor(destHeight + 0.5); >> >> Isn't it what `Region.clipRound` does? > > No, Region.clipRound does something little different than what I intend to do in > this code . > It works same as my code for 0.25 and 0.75 case. But not for 0.5 case. > For example in case of destwidth and destHeight = 19.5, > for my current code I see them rounded to 20, while with clipRound it is > rounded to 19. I guess it should do the same rounding the component do. If the size of the component is 19.5 and we round it to 20, then the image should use the same round logic. BTW why 19 is better than 20 here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1187981265 From serb at openjdk.org Mon May 8 23:38:15 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 8 May 2023 23:38:15 GMT Subject: RFR: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland In-Reply-To: References: Message-ID: On Fri, 5 May 2023 12:27:04 GMT, Alexander Zvegintsev wrote: > On Linux systems, we rely on XGrabPointer (X11 API) to capture mouse input and dismiss popup menus on mouse clicks outside the popup menu. > Unfortunately, on Linux systems using the [Wayland](https://wayland.freedesktop.org/) session this only works inside [XWayland(Wayland's X11 server implementation)](https://wayland.freedesktop.org/xserver.html). > This means if a user clicks on a part of the screen not controlled by XWayland (e.g. window decorations, other non X11 applications) the popup menu will not be hidden. > > As a workaround, we can hide this menu when the parent popup menu window loses focus. > However, it does have its drawbacks, which should be described in the documentation.The focus does not change when clicking on the header of its own parent window or on non-focusable windows, .e.g., empty space in system dock, so in this case the popup menu is not hidden. > > Third-party applications use a similar approach. > > I also have doubts about the need to change the documentation, as I can't find where it is described that the popup menu should be hidden when clicked outside the menu. > > CSR: https://bugs.openjdk.org/browse/JDK-8307529 src/java.desktop/share/classes/java/awt/PopupMenu.java line 46: > 44: * call {@code show} on that {@code PopupMenu}. > 45: * > 46: * @implNote On Linux systems using Wayland, the popup menu may not be dismissed I guess the XWayland is affected, but implementation of the toolkit for Wayland will not have this issue? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13830#discussion_r1187986406 From psadhukhan at openjdk.org Tue May 9 03:24:32 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 9 May 2023 03:24:32 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v5] In-Reply-To: References: Message-ID: > Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. > In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. > Fixed by implementing the equality and hashCode method for CSS.FontSize class. > > All jtreg/jck tests are ok Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13405/files - new: https://git.openjdk.org/jdk/pull/13405/files/2bc265cd..5219a8cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=03-04 Stats: 16 lines in 1 file changed: 11 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13405/head:pull/13405 PR: https://git.openjdk.org/jdk/pull/13405 From psadhukhan at openjdk.org Tue May 9 03:28:23 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 9 May 2023 03:28:23 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v2] In-Reply-To: <8if6uLQ3dd2fZy89oTBqe_kc0A1gheaAqFm3zEza98A=.b86e6eb8-a5cc-4ca6-89ad-dec95ce9c6ef@github.com> References: <6AMf-eKADne9JGixe0AxYWuSCpoT0zPLMSVJ32hg8LU=.77ff4752-a702-4dad-bf80-e44cd91985f0@github.com> <0gOhTUXPHgGwkGUPT-I8JNKvQWQcXCfenFMFRRWv-mE=.5e796740-d480-4190-b0bb-45770e248aee@github.com> <8if6uLQ3dd2fZy89oTBqe_kc0A1gheaAqFm3zEza98A=.b86e6eb8-a5cc-4ca6-89ad-dec95ce9c6ef@github.com> Message-ID: On Fri, 5 May 2023 17:50:54 GMT, Alexey Ivanov wrote: >> yes this needs to be changed. >> Also needs to be changed at line 2034. > > The following test still fails. > > > private static void testFontFamilyCSS() { > StyleSheet ss = new StyleSheet(); > > AttributeSet a = ss.getDeclaration("font-family: sans-serif"); > AttributeSet b = ss.getDeclaration("font-family: sans-serif"); > // Verify a.isEqual(b) > } String comparison changed. Also, I am not able to see this test fail in latest iteration.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1188075885 From psadhukhan at openjdk.org Tue May 9 03:51:27 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 9 May 2023 03:51:27 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v6] In-Reply-To: References: Message-ID: > Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. > In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. > Fixed by implementing the equality and hashCode method for CSS.FontSize class. > > All jtreg/jck tests are ok Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13405/files - new: https://git.openjdk.org/jdk/pull/13405/files/5219a8cd..4036b7c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=04-05 Stats: 73 lines in 1 file changed: 15 ins; 48 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13405/head:pull/13405 PR: https://git.openjdk.org/jdk/pull/13405 From psadhukhan at openjdk.org Tue May 9 03:51:30 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 9 May 2023 03:51:30 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v4] In-Reply-To: <8KEx3YjVgXqUW8_qds0xJj4ArHuJycwwyJNuSu2IGWY=.abf970be-b5cb-4954-8163-5113b73699f1@github.com> References: <8KEx3YjVgXqUW8_qds0xJj4ArHuJycwwyJNuSu2IGWY=.abf970be-b5cb-4954-8163-5113b73699f1@github.com> Message-ID: On Thu, 4 May 2023 12:42:14 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> More Attrbutes added > > test/jdk/javax/swing/text/html/CSS/CSSAttributeEqualityBug.java line 119: > >> 117: System.out.println("b = " + b); >> 118: throw new RuntimeException("CSS.Attribute.Color a is not equal to b"); >> 119: } > > Does it make sense to introduce a new method which compares the two attributes sets `a` and `b`, prints messages and throws the exception? You'll need to pass the CSS attribute name to it. The code will be cleaner. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1188088524 From psadhukhan at openjdk.org Tue May 9 06:44:20 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 9 May 2023 06:44:20 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v7] In-Reply-To: References: Message-ID: > Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. > In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. > Fixed by implementing the equality and hashCode method for CSS.FontSize class. > > All jtreg/jck tests are ok Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: hashCode fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13405/files - new: https://git.openjdk.org/jdk/pull/13405/files/4036b7c5..717d1a1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=05-06 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13405/head:pull/13405 PR: https://git.openjdk.org/jdk/pull/13405 From psadhukhan at openjdk.org Tue May 9 06:44:23 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 9 May 2023 06:44:23 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v4] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 17:59:25 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> More Attrbutes added > > src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2897: > >> 2895: @Override >> 2896: public int hashCode() { >> 2897: return Float.hashCode(horizontalPosition); > > For better hashing, `verticalPosition` should also be taken into account. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1188199148 From angus.macaulay at ge.com Tue May 9 11:22:36 2023 From: angus.macaulay at ge.com (Macaulay, Angus J (GE Digital)) Date: Tue, 9 May 2023 11:22:36 +0000 Subject: JDK-830-1616 - Drag & maximize to another monitor places window incorrectly (Windows) Message-ID: This looks a useful fix. Will it be backported to JDK-17 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3833 bytes Desc: not available URL: From azvegint at openjdk.org Tue May 9 14:37:24 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 May 2023 14:37:24 GMT Subject: RFR: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland In-Reply-To: References: Message-ID: On Mon, 8 May 2023 23:35:19 GMT, Sergey Bylokhov wrote: >> On Linux systems, we rely on XGrabPointer (X11 API) to capture mouse input and dismiss popup menus on mouse clicks outside the popup menu. >> Unfortunately, on Linux systems using the [Wayland](https://wayland.freedesktop.org/) session this only works inside [XWayland(Wayland's X11 server implementation)](https://wayland.freedesktop.org/xserver.html). >> This means if a user clicks on a part of the screen not controlled by XWayland (e.g. window decorations, other non X11 applications) the popup menu will not be hidden. >> >> As a workaround, we can hide this menu when the parent popup menu window loses focus. >> However, it does have its drawbacks, which should be described in the documentation.The focus does not change when clicking on the header of its own parent window or on non-focusable windows, .e.g., empty space in system dock, so in this case the popup menu is not hidden. >> >> Third-party applications use a similar approach. >> >> I also have doubts about the need to change the documentation, as I can't find where it is described that the popup menu should be hidden when clicked outside the menu. >> >> CSR: https://bugs.openjdk.org/browse/JDK-8307529 > > src/java.desktop/share/classes/java/awt/PopupMenu.java line 46: > >> 44: * call {@code show} on that {@code PopupMenu}. >> 45: * >> 46: * @implNote On Linux systems using Wayland, the popup menu may not be dismissed > > I guess the XWayland is affected, but implementation of the toolkit for Wayland will not have this issue? It should, and this is another point about not changing the documentation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13830#discussion_r1188704947 From azvegint at openjdk.org Tue May 9 14:40:18 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 May 2023 14:40:18 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: On Mon, 8 May 2023 18:41:56 GMT, Sergey Bylokhov wrote: > > It seems that the current robot API is not suitable for this. > > Can we just reset the token when we create a new instance of Robot? This will be a big problem for automated testing, as each test with the robot will require user confirmation(or even more than one, as some tests instantiate it several times). This is exactly what we are trying to avoid. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1540255849 From xuelei at openjdk.org Tue May 9 15:52:31 2023 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 9 May 2023 15:52:31 GMT Subject: Integrated: 8303830: update for deprecated sprintf for jdk.accessibility In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 18:20:47 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > May I have this update reviewed? > > The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the jdk.accessibility module. > > Thanks, > Xuelei This pull request has now been integrated. Changeset: 44fa12e7 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.org/jdk/commit/44fa12e7511a0b08999c1f1fb7da33bc6578b183 Stats: 42 lines in 7 files changed: 0 ins; 0 del; 42 mod 8303830: update for deprecated sprintf for jdk.accessibility Reviewed-by: kizune ------------- PR: https://git.openjdk.org/jdk/pull/12929 From dmarkov at openjdk.org Tue May 9 16:11:35 2023 From: dmarkov at openjdk.org (Dmitry Markov) Date: Tue, 9 May 2023 16:11:35 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 12:58:58 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > Noticed this test case not verifying all the cases which is intended. Modified it for improving the coverage for 3 type of popups (menu, context menu and combobox). > > Evaluating conditions: > 1. Not enough space for showing popup downwards(default layout), it should show upwards > 2. Window starts from negative position, Popup should show on visible area > > For achieving this following areas are modified > - Updated isPopupOnScreen by adding Additional checks (like the position of combobox popup is always verified) > - Menu creation made as function and reused for all menu creation. > - Updated ComboPopupCheckListener class and modified its popupMenuWillBecomeInvisible function. Made it as generic and it is capable to evaluate any combo box's position if this class set as its listener. > - This test case is not intended for multi monitor setup so added a check for identifying monitor, else error out. > - Updated CTRL_MASK to CTRL_DOWN_MASK for removing depreciation warnings and removed some other warnings. > > Please review this > > Regards, > Renjith. The new version of the test fails for me on macOS because CTRL + DOWN key combination is reserved by the operating system. It is necessary to disable "Application windows" system key shortcut to execute the test without failure. An interesting thing is that the old version of the test works fine even if "Application windows" system key shortcut is enabled. I would suggest documenting (probably at testing.md/wiki page) that "Application windows" key shortcut should be disabled prior testing. ------------- Changes requested by dmarkov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13578#pullrequestreview-1418993631 From prr at openjdk.org Tue May 9 17:14:32 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 9 May 2023 17:14:32 GMT Subject: RFR: JDK-8307128: Open source some drag and drop tests 4 In-Reply-To: References: Message-ID: On Mon, 8 May 2023 18:31:26 GMT, Sergey Bylokhov wrote: >> added DnD tests > > test/jdk/java/awt/dnd/MozillaDnDTest.java line 177: > >> 175: public void start() { >> 176: // Solaris/Linux-only test >> 177: if (System.getProperty("os.name").startsWith("Windows")) { > > Can we use OSInfo here? Unless a test already needs some other utils I prefer to avoid such minor dependencies which prevent you from running the test outside of jtreg. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13765#discussion_r1188903351 From serb at openjdk.org Tue May 9 17:45:27 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 9 May 2023 17:45:27 GMT Subject: RFR: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland In-Reply-To: References: Message-ID: On Tue, 9 May 2023 14:34:08 GMT, Alexander Zvegintsev wrote: >> src/java.desktop/share/classes/java/awt/PopupMenu.java line 46: >> >>> 44: * call {@code show} on that {@code PopupMenu}. >>> 45: * >>> 46: * @implNote On Linux systems using Wayland, the popup menu may not be dismissed >> >> I guess the XWayland is affected, but implementation of the toolkit for Wayland will not have this issue? > > It should, and this is another point about not changing the documentation. Then let's not update it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13830#discussion_r1188936947 From serb at openjdk.org Tue May 9 17:54:28 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 9 May 2023 17:54:28 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v2] In-Reply-To: <3j4se4PxZQeOAEGlftu1DglKSWYQ_9cjIisP3ygOoI0=.5ecf40ed-ed05-4b62-9145-2cd13eb4785c@github.com> References: <3j4se4PxZQeOAEGlftu1DglKSWYQ_9cjIisP3ygOoI0=.5ecf40ed-ed05-4b62-9145-2cd13eb4785c@github.com> Message-ID: On Mon, 8 May 2023 18:05:59 GMT, Tejesh R wrote: >> Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 102: > 100: robot.delay(500); > 101: > 102: if (!wasActionFired) { "wasActionFired" is set on EDT and used here on main - should use some synchronization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1188945850 From achung at openjdk.org Tue May 9 17:54:41 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 9 May 2023 17:54:41 GMT Subject: RFR: 8307299: Move more DnD tests to open [v4] In-Reply-To: References: Message-ID: > Added DnD tests Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: fix space, add method on EDT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13759/files - new: https://git.openjdk.org/jdk/pull/13759/files/09ceaf0a..0f5df266 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13759&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13759&range=02-03 Stats: 7 lines in 3 files changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13759.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13759/head:pull/13759 PR: https://git.openjdk.org/jdk/pull/13759 From azvegint at openjdk.org Tue May 9 18:01:32 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 May 2023 18:01:32 GMT Subject: RFR: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland [v2] In-Reply-To: References: Message-ID: <4XxvIZxo4wVodA35ut-cogY4caeGejWzX1j6sE-0rws=.2bdeac33-879b-47a7-8827-6425b6fe6fd6@github.com> On Tue, 9 May 2023 17:42:21 GMT, Sergey Bylokhov wrote: >> It should, and this is another point about not changing the documentation. > > Then let's not update it. Backed out doc changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13830#discussion_r1188950338 From azvegint at openjdk.org Tue May 9 18:01:31 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 May 2023 18:01:31 GMT Subject: RFR: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland [v2] In-Reply-To: References: Message-ID: > On Linux systems, we rely on XGrabPointer (X11 API) to capture mouse input and dismiss popup menus on mouse clicks outside the popup menu. > Unfortunately, on Linux systems using the [Wayland](https://wayland.freedesktop.org/) session this only works inside [XWayland(Wayland's X11 server implementation)](https://wayland.freedesktop.org/xserver.html). > This means if a user clicks on a part of the screen not controlled by XWayland (e.g. window decorations, other non X11 applications) the popup menu will not be hidden. > > As a workaround, we can hide this menu when the parent popup menu window loses focus. > However, it does have its drawbacks, which should be described in the documentation.The focus does not change when clicking on the header of its own parent window or on non-focusable windows, .e.g., empty space in system dock, so in this case the popup menu is not hidden. > > Third-party applications use a similar approach. > > I also have doubts about the need to change the documentation, as I can't find where it is described that the popup menu should be hidden when clicked outside the menu. > > CSR: https://bugs.openjdk.org/browse/JDK-8307529 Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: undo documentation changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13830/files - new: https://git.openjdk.org/jdk/pull/13830/files/ca4bc8b5..becb92d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13830&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13830&range=00-01 Stats: 8 lines in 2 files changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13830.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13830/head:pull/13830 PR: https://git.openjdk.org/jdk/pull/13830 From achung at openjdk.org Tue May 9 18:05:39 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 9 May 2023 18:05:39 GMT Subject: RFR: JDK-8307083: Open source some drag and drop tests 3 [v3] In-Reply-To: References: Message-ID: <1_BHtnvEe4SYe_MVg4gvkSHbpPTeoKrS2RWG1OGyrf0=.1365e6d4-c61d-41b7-b19d-b3584a8293d7@github.com> > moving tests to open Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JTREG_TEST_SPRINT3' of github.com:alisenchung/jdk into JTREG_TEST_SPRINT3 - moved check onto EDT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13764/files - new: https://git.openjdk.org/jdk/pull/13764/files/b99982a8..de4cfd7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13764&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13764&range=01-02 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13764/head:pull/13764 PR: https://git.openjdk.org/jdk/pull/13764 From achung at openjdk.org Tue May 9 18:14:40 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 9 May 2023 18:14:40 GMT Subject: RFR: JDK-8307128: Open source some drag and drop tests 4 [v2] In-Reply-To: References: Message-ID: > added DnD tests Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: - space - fix spacing, move check onto EDT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13765/files - new: https://git.openjdk.org/jdk/pull/13765/files/1c58b757..5adceab6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13765&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13765&range=00-01 Stats: 13 lines in 5 files changed: 2 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13765.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13765/head:pull/13765 PR: https://git.openjdk.org/jdk/pull/13765 From asemenov at openjdk.org Tue May 9 18:51:51 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Tue, 9 May 2023 18:51:51 GMT Subject: RFR: 8302687 Implement interfaces and shared code for announcement feature [v4] In-Reply-To: References: Message-ID: > This enhancement covers basic API and shared code that should be implemented for the Accessibility Announcement feature. > > CSR [JDK-8304499](https://bugs.openjdk.org/browse/JDK-8304499 "bugs.openjdk.org") > > @mrserb @prrace @azuev-java please review Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: update constans name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13001/files - new: https://git.openjdk.org/jdk/pull/13001/files/9d770ebb..a51d8a58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13001&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13001&range=02-03 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13001.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13001/head:pull/13001 PR: https://git.openjdk.org/jdk/pull/13001 From rmahajan at openjdk.org Tue May 9 18:59:26 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Tue, 9 May 2023 18:59:26 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Mon, 8 May 2023 23:22:52 GMT, Sergey Bylokhov wrote: >> No, Region.clipRound does something little different than what I intend to do in >> this code . >> It works same as my code for 0.25 and 0.75 case. But not for 0.5 case. >> For example in case of destwidth and destHeight = 19.5, >> for my current code I see them rounded to 20, while with clipRound it is >> rounded to 19. > > I guess it should do the same rounding the component do. If the size of the component is 19.5 and we round it to 20, then the image should use the same round logic. BTW why 19 is better than 20 here? So, I added this code specifically to have improved rendering for the 25% cases, like 125%, 225%, 325% as rendering was a little off for these scale values and empirically based on what we saw it looked better with this calculation. It is also important to note that windows is not consistent in what size it provides for a part(button) . For example for 150% it provides part size as 20 and we calculate it as 20 in above code. For 175% windows still provides 20 again (while we would expect higher value) and we calculate it as 23 and it works out good. But as I said earlier for 125% or 225% it works best with above code. The 20 vs 19 thing that I mentioned above was to just show that clipRound doesn't calculate it same was as my code and can have rendering repercussions as it is very sensitive to pixel variation , even 1 pixel variation causes rendering artifacts. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1189019091 From achung at openjdk.org Tue May 9 19:17:33 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 9 May 2023 19:17:33 GMT Subject: Integrated: JDK-8307128: Open source some drag and drop tests 4 In-Reply-To: References: Message-ID: <0O2BxBaBObP4p793bm8JLoOlqvmwlFFiZsLxWq-bWk4=.346f730f-ff92-46af-a18b-e36ec388f88a@github.com> On Tue, 2 May 2023 22:09:18 GMT, Alisen Chung wrote: > added DnD tests This pull request has now been integrated. Changeset: 98294242 Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/98294242a94c611e2a713c2d520e59dd873ae4a0 Stats: 1680 lines in 5 files changed: 1680 ins; 0 del; 0 mod 8307128: Open source some drag and drop tests 4 Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13765 From prr at openjdk.org Tue May 9 19:26:28 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 9 May 2023 19:26:28 GMT Subject: RFR: 8306881: Update FreeType to 2.13.0 [v2] In-Reply-To: <5maRLT6sj8N_1WNBlIkHsRHP8zLmcmgZkgdQB1xvjJY=.cbb41bfc-bcbb-431c-8d1a-b89905c7e08f@github.com> References: <5maRLT6sj8N_1WNBlIkHsRHP8zLmcmgZkgdQB1xvjJY=.cbb41bfc-bcbb-431c-8d1a-b89905c7e08f@github.com> Message-ID: On Sat, 6 May 2023 03:14:32 GMT, Alisen Chung wrote: >> update freetype version to 2.13, all tests passed > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > readd spaces to comments "I built jdk with option --with-freetype=bundled on macosx, linux, and windows without issues" OK - approving. "I built jdk with option --with-freetype=bundled on macosx, linux, and windows without issues" OK - approving. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13841#pullrequestreview-1419318619 PR Review: https://git.openjdk.org/jdk/pull/13841#pullrequestreview-1419318651 From achung at openjdk.org Tue May 9 19:26:29 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 9 May 2023 19:26:29 GMT Subject: RFR: 8306881: Update FreeType to 2.13.0 [v2] In-Reply-To: <5maRLT6sj8N_1WNBlIkHsRHP8zLmcmgZkgdQB1xvjJY=.cbb41bfc-bcbb-431c-8d1a-b89905c7e08f@github.com> References: <5maRLT6sj8N_1WNBlIkHsRHP8zLmcmgZkgdQB1xvjJY=.cbb41bfc-bcbb-431c-8d1a-b89905c7e08f@github.com> Message-ID: On Sat, 6 May 2023 03:14:32 GMT, Alisen Chung wrote: >> update freetype version to 2.13, all tests passed > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > readd spaces to comments I built jdk with option --with-freetype=bundled on macosx, linux, and windows without issues ------------- PR Comment: https://git.openjdk.org/jdk/pull/13841#issuecomment-1540766577 From achung at openjdk.org Tue May 9 19:26:30 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 9 May 2023 19:26:30 GMT Subject: RFR: 8306881: Update FreeType to 2.13.0 [v2] In-Reply-To: References: <5maRLT6sj8N_1WNBlIkHsRHP8zLmcmgZkgdQB1xvjJY=.cbb41bfc-bcbb-431c-8d1a-b89905c7e08f@github.com> Message-ID: On Mon, 8 May 2023 19:53:18 GMT, Damon Nguyen wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> readd spaces to comments > > src/java.desktop/share/native/libfreetype/include/freetype/internal/ftmmtypes.h line 18: > >> 16: * understand and accept it fully. >> 17: * >> 18: */ > > Is this the only new file being added? yea ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13841#discussion_r1189043120 From dnguyen at openjdk.org Tue May 9 19:29:27 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 9 May 2023 19:29:27 GMT Subject: RFR: 8306881: Update FreeType to 2.13.0 [v2] In-Reply-To: <5maRLT6sj8N_1WNBlIkHsRHP8zLmcmgZkgdQB1xvjJY=.cbb41bfc-bcbb-431c-8d1a-b89905c7e08f@github.com> References: <5maRLT6sj8N_1WNBlIkHsRHP8zLmcmgZkgdQB1xvjJY=.cbb41bfc-bcbb-431c-8d1a-b89905c7e08f@github.com> Message-ID: On Sat, 6 May 2023 03:14:32 GMT, Alisen Chung wrote: >> update freetype version to 2.13, all tests passed > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > readd spaces to comments Marked as reviewed by dnguyen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13841#pullrequestreview-1419324937 From achung at openjdk.org Tue May 9 19:34:32 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 9 May 2023 19:34:32 GMT Subject: Integrated: 8306881: Update FreeType to 2.13.0 In-Reply-To: References: Message-ID: On Fri, 5 May 2023 18:28:38 GMT, Alisen Chung wrote: > update freetype version to 2.13, all tests passed This pull request has now been integrated. Changeset: 723582c5 Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/723582c524c62ee73f7984a53b046f8832b23a7f Stats: 3606 lines in 283 files changed: 1610 ins; 690 del; 1306 mod 8306881: Update FreeType to 2.13.0 Reviewed-by: prr, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/13841 From achung at openjdk.org Tue May 9 19:40:14 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 9 May 2023 19:40:14 GMT Subject: RFR: 8307297: Move some DnD tests to open [v4] In-Reply-To: References: Message-ID: > Adding some DnD tests Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: update tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13756/files - new: https://git.openjdk.org/jdk/pull/13756/files/7d514e47..e1e0bc4d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13756&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13756&range=02-03 Stats: 93 lines in 2 files changed: 26 ins; 40 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/13756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13756/head:pull/13756 PR: https://git.openjdk.org/jdk/pull/13756 From azvegint at openjdk.org Tue May 9 19:54:36 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 May 2023 19:54:36 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification Message-ID: We need to relax the java.awt.Robot specification according to the latest operating system trends. This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures ------------- Commit messages: - update documentation - upd - update also for createScreenCapture - update based on a review comments - doc changes Changes: https://git.openjdk.org/jdk/pull/13809/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13809&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307779 Stats: 103 lines in 2 files changed: 99 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13809/head:pull/13809 PR: https://git.openjdk.org/jdk/pull/13809 From mkartashev at openjdk.org Tue May 9 19:54:40 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Tue, 9 May 2023 19:54:40 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification In-Reply-To: References: Message-ID: On Thu, 4 May 2023 16:26:47 GMT, Alexander Zvegintsev wrote: > We need to relax the java.awt.Robot specification according to the latest operating system trends. > This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. > > https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots > https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor > https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. > https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures LGTM, although I am not an OpenJDK reviewer. src/java.desktop/share/classes/java/awt/Robot.java line 407: > 405: *
> 406: * The pixel color may be black if permission to capture a particular screen > 407: * has not been granted. This seems to contradict with the "throws" description as it is not clear when black is returned and when SecurityException is thrown in response to the user denying screen capturing. src/java.desktop/share/classes/java/awt/Robot.java line 633: > 631: > 632: /** > 633: * Resets the stored screen data capture permission for a set of screens. Does "reset" here mean that the next attempt to capture screen pixels will require another permission? It's not clear what the effects of this "reset" are. Also, the part "for a set of screens" kind of implies that for some other set of screens the permission will not be reset, but how can one specify for which set of screens the permission is to be reset? Perhaps, simply "Revokes the stored permission to capture screen data. Subsequent calls to getPixelColor and createScreenCapture may request a new permission from the user on applicable platforms"? src/java.desktop/share/classes/java/awt/peer/RobotPeer.java line 133: > 131: /** > 132: * Resets the stored screen data capture permission for a set of screens. > 133: * Is a no-op if not supported by the platform. Same here as in `Robot.resetScreenCapturePermission()`. ------------- Marked as reviewed by mkartashev (no project role). PR Review: https://git.openjdk.org/jdk/pull/13809#pullrequestreview-1416293668 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1185735125 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1185873389 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1185875012 From prr at openjdk.org Tue May 9 19:54:42 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 9 May 2023 19:54:42 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification In-Reply-To: References: Message-ID: On Thu, 4 May 2023 16:26:47 GMT, Alexander Zvegintsev wrote: > We need to relax the java.awt.Robot specification according to the latest operating system trends. > This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. > > https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots > https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor > https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. > https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures Changes requested by prr (Reviewer). src/java.desktop/share/classes/java/awt/Robot.java line 79: > 77: * (e.g. interacting with window decorations, trying to change the > 78: * window stacking order with the mouse or keyboard shortcuts) > 79: * We won't be running in compatibility mode when we have a pure wayland port .. I think it would be nice if we could get this wording done in such a way that it applies to both .. and even covers the situation on macOS too. Also this sort of overlooks that we don't support wayland today and won't be able to do screen capture in "default" mode .. so its really tricky to know whether to introduce wording like this. Here's my first stab. This is pure SPEC, not "notes" or "impl" 
 * Platforms and desktop environments may impose restrictions or limitations
 * on the access required to implement all functionality in the Robot class.
 * For example
 * + preventing access to the contents of any part of a desktop or Window on the desktop that is not owned by the running application
 * + treating window decorations as non-owned content.
 * + ignoring or limiting specific requests to manipulate windows.
 * + ignoring or limiting specific requests for Robot generated (synthesized) events related to keyboard and mouse etc.
 * + requiring specific or global permissions to any access to window contents, even application owned content,
 *  or to perform even limited synthesizing of events.
 *
 * The Robot API specification requires that approvals for these be granted for full operation.
 * If they are not granted, the API will be degraded as discussed here.
 * Relevant specific API methods may document more specific limitations and requirements.

 *  Depending on the policies of the desktop environment, the approvals mentioned above may
      + be required every time
      + or persistent for the lifetime of an application,
      + or persistent across multiple user desktop sessions
      + be fine-grained permissions
      + be associated with a specific binary application, or a class of binary applications.

When such approvals need to given interactively, it may impede the normal operation of the
     application until approved,  and if approval is denied or not possible, or cannot be made persistent
     then it will degrade the functionality of this class and in turn any part of  the operation of the
     application which is dependent on it.
src/java.desktop/share/classes/java/awt/Robot.java line 399: > 397: * Returns the color of a pixel at the given screen coordinates. > 398: * > 399: * @implNote On Linux systems using Wayland, permission may be requested We need more than an implNote here. It needs to be spec. Also the words about system dialog don't belong. There may be other ways. And "may be black" ? That's not very useful. Either guarantee its black or say "unspecified". Is black guaranteed today if we fail to grab it ? But also it seems to contradict the SecurityException docs .. how do you get black if an exception is thrown ? src/java.desktop/share/classes/java/awt/Robot.java line 416: > 414: * @throws SecurityException if {@code readDisplayPixels} permission > 415: * is not granted, or user has denied screen capture for all > 416: * screens * SecurityException if (1) {@code readDisplayPixels} permission is not granted, or (2) user has denied screen capture for all screens (1) is the java SecurityManager scenario. Since that's not yet removed, we do need those words, so OK (2) Is there some subtlety about "ALL" screens ? Do you really mean all screens which are in the area being captured ? Does that also imply you can get a partial capture if it spans 2 screens and you only have permission for one of them ? I'm not sure how useful that is in the "screenCapture" case and its really odd for the single pixel capture .. which surely is only on one screen ? We do also need to think forward to a pure wayland scenario - any differences there. ? The word "Wayland" shouldn't appear in the spec My proposal - 
If the desktop environment requires that permissions be granted to
capture screen content, and the required permissions are not granted,
then a {@code SecurityException} may be thrown, or the contents of
the returned {@code BufferedImage} are undefined.

@apiNote:
It is recommended to avoid calling this method on the
AWT Event Dispatch Thread since screen capture may be a lengthy operation,
particularly if acquiring permissions is needed and involves user interaction.

@throws  SecurityException if {@code readDisplayPixels} permission
      *          is not granted, or user has denied screen capture for all
      *          required screens
==== I added the word REQUIRED here, since if we only need screen 1 contents, surely it doesn't matter if we don't have screen 2 permission ? src/java.desktop/share/classes/java/awt/Robot.java line 640: > 638: * a new permission from the user on applicable platforms. > 639: */ > 640: public void revokeScreenCapturePermission() { I do not understand why we need this method. Also we are separating spec. relaxation into this bug / PR which BTW means it needs a new bug ID. But this would be a new API, so it would need to go along with the code that implements it. Perhaps that's why you added the default method below .. but it isn't really the same thing. ------------- PR Review: https://git.openjdk.org/jdk/pull/13809#pullrequestreview-1417479332 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1187970612 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1187882524 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1187889861 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1187875121 From azvegint at openjdk.org Tue May 9 19:54:43 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 May 2023 19:54:43 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification In-Reply-To: References: Message-ID: On Mon, 8 May 2023 20:45:42 GMT, Phil Race wrote: > Is black guaranteed today if we fail to grab it ? Currently we are passing a java `pixelArray` it to native to fill it up with screen capture data. If we do not change this array(or part related to denied screen) it remains black. But I'll change it to "unspecified" > how do you get black if an exception is thrown ? Exception is thrown only if user has denied screen capture at all(does not grant permission to at least one screen). In the case where user is trying to retrieve pixels from a screen to which the user has not given access he'll get the black pixels. Alternatively, we can also give up on the SecurityException and not throw it at all in this case. > Is there some subtlety about "ALL" screens ? It is more like "the user has not allowed any of his screens to be captured." In fact, we may not throw out this exception and just provide black pixels(and call it "unspecified" behavior). > Do you really mean all screens which are in the area being captured ? > I added the word REQUIRED here, since if we only need screen 1 contents, surely it doesn't matter if we don't have screen 2 permission ? That's not exactly true. There are screens that the user may or may not have given permission to capture. This permission(specifically `restore_token`) is one at a single moment in time, not several separate permissions for each screen. This restore_token is associated with the permissions for specific screens. There is an area that the user wants to capture. The intersection of the capture area and the screens allowed for capture will have actual data from the screen, otherwise - black pixels. So if a user allows access only to screen A and then asks for pixels from screen B he will get black pixels. This is about the same when we have a single monitor and we capture an area outside of it (e.g. -100, -100, 50, 50) - we get a black square. > Does that also imply you can get a partial capture if it spans 2 screens and you only have permission for one of them ? Yes, the plan is to provide what we can and leave the other parts black. > We do also need to think forward to a pure wayland scenario - any differences there. ? As a screen capture - should work as it is. The only concern is the impossibility to specify and get the window coordinates. This way we won't know where the window we are displaying is located. It will affect the testing approach and we will have to add a method like `captureWindowContents` to check the window contents. > I do not understand why we need this method. We need it in order to be able to revoke the saved permission. For example, it may be necessary if the user has two monitors, but the user only allowed access to one of them. If he later decides to get a screen capture of two monitors, with the current implementation it will be impossible to do so without this method. Alternatively, we can replace it with a system property that says should we keep the permission or not. It is discussed here https://github.com/openjdk/jdk/pull/13803#issuecomment-1540255849 > it needs a new bug ID. done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1188820585 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1188920280 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1188828224 From azvegint at openjdk.org Tue May 9 19:54:44 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 May 2023 19:54:44 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification In-Reply-To: References: Message-ID: On Fri, 5 May 2023 06:22:31 GMT, Maxim Kartashev wrote: >> We need to relax the java.awt.Robot specification according to the latest operating system trends. >> This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. >> >> https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots >> https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor >> https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. >> https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures > > src/java.desktop/share/classes/java/awt/Robot.java line 407: > >> 405: *
>> 406: * The pixel color may be black if permission to capture a particular screen >> 407: * has not been granted. > > This seems to contradict with the "throws" description as it is not clear when black is returned and when SecurityException is thrown in response to the user denying screen capturing. Updated. > src/java.desktop/share/classes/java/awt/Robot.java line 633: > >> 631: >> 632: /** >> 633: * Resets the stored screen data capture permission for a set of screens. > > Does "reset" here mean that the next attempt to capture screen pixels will require another permission? It's not clear what the effects of this "reset" are. > > Also, the part "for a set of screens" kind of implies that for some other set of screens the permission will not be reset, but how can one specify for which set of screens the permission is to be reset? Perhaps, simply > "Revokes the stored permission to capture screen data. Subsequent calls to getPixelColor and createScreenCapture may request a new permission from the user on applicable platforms"? Yes, this sounds much better, updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1186212568 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1186212219 From azvegint at openjdk.org Tue May 9 20:18:18 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 May 2023 20:18:18 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification In-Reply-To: References: Message-ID: On Tue, 9 May 2023 16:05:15 GMT, Alexander Zvegintsev wrote: >> src/java.desktop/share/classes/java/awt/Robot.java line 640: >> >>> 638: * a new permission from the user on applicable platforms. >>> 639: */ >>> 640: public void revokeScreenCapturePermission() { >> >> I do not understand why we need this method. >> Also we are separating spec. relaxation into this bug / PR >> which BTW means it needs a new bug ID. >> But this would be a new API, so it would need to go along with the code that implements it. >> Perhaps that's why you added the default method below .. but it isn't really the same thing. > >> I do not understand why we need this method. > > We need it in order to be able to revoke the saved permission. > > For example, it may be necessary if the user has two monitors, but the user only allowed access to one of them. > If he later decides to get a screen capture of two monitors, with the current implementation it will be impossible to do so without this method. > > Alternatively, we can replace it with a system property that says should we keep the permission or not. > It is discussed here https://github.com/openjdk/jdk/pull/13803#issuecomment-1540255849 > >> it needs a new bug ID. > > done Updated according to your comments. I still left `revokeScreenCapturePermission` here for now, so that its documentation can be easily compared and aligned with the other documentation changes. After finalization it will be moved to #13803 (if we decide to keep the method) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1189089254 From prr at openjdk.org Tue May 9 20:46:31 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 9 May 2023 20:46:31 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 14:35:46 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow a screen capture for all screens or some of them. For screens without permission there will be a black image. >> + If the user wishes to change their mind about the screens allowed to be captured, the user should use the new `Robot#resetScreenCapturePermission` method >> >> Also added several system properties: >> `awt.robot.screencastEnabled` false by default, uses the ScreenCast API if true >> `awt.robot.screencastDebug` false by default, prints some debug information if true >> >> For convenience, this change is divided into two commits: >> 1. added [pipewire headers](https://gitlab.freedesktop.org/pipewire/pipewire/) that are needed for the build >> 2. main changes >> >> Changes in the documentation are in a separate draft PR (#13809) also for convenience. >> >> At the moment, the planned supported systems are Ubuntu 22.04+, the latest Oracle Linux 9.1 and RHEL 9.1 has some issues with restore_token support. > > Alexander Zvegintsev has updated the pull request incrementally with three additional commits since the last revision: > > - update, based on review comments > - remove wayland detection > - BUILD_LIBPIPEWIRE_HEADER_DIRS -> LIBPIPEWIRE_HEADER_DIRS I'm thinking about the re-set API "If the user wishes to change their mind about the screens allowed to be captured, the user should use the new Robot#resetScreenCapturePermission method" Well the "user" is hosed unless the app calls this every time ... or provides UI for it .. I want to work through the scenarios and how much of it is specific to the behaviours of the API you are using and so forth. Since you use the Preferences API for saving the token, if you keyed it off the Robot class rather than the internal API class then anyone using the Preferences API could delete the token, couldn't they ? And we presumably can store alongside the token, info about the screens attached at the time we obtained the token ? Can you point (here in the implementation review) to the exact native functions that popup up the dialog ? I'm still trying to find my way through that code. Is it opaque to the caller (us) what the user actually approved ? I can't imagine why we would need to reset "we have all permissions" to "we have no permissions" so I'm supposing the issue is when they didn't grant permissions .. but if they "deny" permissions that's surely different than "this token is no longer valid" ? The first time we need a permission for the screencast API there is a dialog. The user makes some choices and we then choose to save a token so that the user isn't prompted again. We must at least know though that they approved SOMETHING but we don't know what ? Or do we ? If they DENY, would we save that ? Interesting question because if we don't save something we'll keep spamming them until they approve :-) Next time, what happens if for some reaon the token is no longer valid ? And what might make it invalid ? If the user denied screen 2, or added screen 2 later, would that not result in an invalid token and we'd know to ask again ? No reset needed ? Also I can't figure out if "validating" the token can cause the dialog as a side effect or if there's some API we explicitly call to request a new token. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1540864851 From jiangli at openjdk.org Tue May 9 21:34:43 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 9 May 2023 21:34:43 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v8] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS: - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk. - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS). - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/ directory. - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/2cb786ab..cf317d36 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=06-07 Stats: 107 lines in 5 files changed: 32 ins; 60 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From duke at openjdk.org Tue May 9 21:42:35 2023 From: duke at openjdk.org (Jonathan S. Fisher) Date: Tue, 9 May 2023 21:42:35 GMT Subject: RFR: 8071693: Introspector ignores default interface methods [v8] In-Reply-To: References: <-IveXtSUwnUGB0A-Jt-G7nKcaWbI82sbLwj18HeWV9A=.05d1d113-bd5f-414c-8906-4d8dc2a08d4b@github.com> Message-ID: On Tue, 25 Apr 2023 18:52:16 GMT, Archie Cobbs wrote: >> The `Introspector` class was never updated to include `default` methods inherited from interfaces. >> >> This patch attempts to fix that omission. > > Archie Cobbs 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 13 additional commits since the last revision: > > - Whitespace cleanups suggested by review. > - Merge branch 'master' into JDK-8071693 > - Jam lines into 80 columns. > - Add more scenarios to the regression test. > - Add braces around if clause. > - Add comment describing what IGNORABLE_INTERFACES is for. > - Put braces around single-line "if" statement clauses in test. > - Merge branch 'master' into JDK-8071693 > - Verify static method is not mistakenly identified as property getter. > - Use Modifier.isAbstract() convenience method instead of bit masking test. > - ... and 3 more: https://git.openjdk.org/jdk/compare/08436342...b92726a9 Hello, If I backported this to JDK17 LTS, would there be any chance of acceptance? Open Source work often goes unthanked, so I do wish to express my gratitude for fixing this. Unfortunately it does create headaches in JDK17 as an entire class of methods are getting missed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13544#issuecomment-1540815854 From jiangli at openjdk.org Tue May 9 21:46:42 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 9 May 2023 21:46:42 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v9] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Fix whitspace errors. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/cf317d36..d30b3e34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Tue May 9 21:47:32 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 9 May 2023 21:47:32 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v7] In-Reply-To: References: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com> <2BVvV9m8bI-UzZXpX1GEPwoStZ6pHZBn4JuAMRQk978=.54246fe4-57b8-4372-bfc4-6b63823fa9a2@github.com> Message-ID: On Mon, 8 May 2023 19:45:18 GMT, Jiangli Zhou wrote: > > > All of that said, I think we can get away with a smaller subset of targets and deliverables. AFAIK, graal needs the combined `graal-builder-image` as input to their build anyway, so they should not have any dependency on what the target `static-libs-image` produces. Given that I propose the following behavior: > > > `make static-libs-image` produces `images/static-libs` with all .a (including libjvm.a). `make static-libs-graal-image` produces `images/static-libs-graal` with all .a except libjvm.a. `make graal-builder-image` produces `images/graal-builder-image` like today, but depends on and uses `static-libs-graal-image` instead of `static-libs-image`. `make static-libs-bundles` depends on and uses `static-libs-image` like today, so will contain libjvm.a, which is new behavior. > > > > > > Sure, that should work too as long as there is a way to a) build the static libs only needed for graal some way b) keep `graal-builder-image` working as it does today. FWIW, we use `a)` at adoptium so as to be able to have a combination to build mandrel from. Not all users will want to have JDK + static libs so only the ones needing them should need to download them. > > Thanks @erikj79 @jerboaa. We can go with what @erikj79 suggested then. I'll revise the PR. @erikj79 and @jerboaa please please review the updated version, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1540931243 From azvegint at openjdk.org Tue May 9 22:12:15 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 May 2023 22:12:15 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 20:43:13 GMT, Phil Race wrote: > I want to work through the scenarios and how much of it is specific to the behaviours of the API you are using and so forth. Since you use the Preferences API for saving the token, if you keyed it off the Robot class rather than the internal API class then anyone using the Preferences API could delete the token, couldn't they ? Right now it can be read with a simple call: `System.out.println(Preferences.userRoot().node("/sun/awt/screencast").get("restoreToken", ""));` (modification is also simple). Moving to Robot doesn't change anything in this regard. So anyone can delete it. > And we presumably can store alongside the token, info about the screens attached at the time we obtained the token ? We can try to do that and switch it depending on the area requested, but I tried to keep it simple. > Can you point (here in the implementation review) to the exact native functions that popup up the dialog ? I'm still trying to find my way through that code. Is it opaque to the caller (us) what the user actually approved ? (It is collapsed by the github in the review, so links are to the branch) basically if you [didn't provide a correct token or no token at all](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L530-L537) to [SelectSources call](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L539-L546) it will prompt with dialog right after [the Start call](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L677-L685) > I can't imagine why we would need to reset "we have all permissions" to "we have no permissions" so I'm supposing the issue is when they didn't grant permissions .. but if they "deny" permissions that's surely different than "this token is no longer valid" ? It is not for the "we have all permissions" case, it is for the case when we only have a permission to some screens. So it won't hurt. > The first time we need a permission for the screencast API there is a dialog. The user makes some choices and we then choose to save a token so that the user isn't prompted again. We must at least know though that they approved SOMETHING but we don't know what ? Or do we ? No we don't. We receive the response [callbackScreenCastStart](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L586-L591) as a separate streams for each allowed display. Based on this response we [building a list of **available** displays](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L73). So denied screens will not be there. At this point we can compare this result with the screens got from X11 API(won't be compatible with Wayland, where we also want to reuse it later) or with Wayland(+1 dependency at this point). > If they DENY, would we save that ? Interesting question because if we don't save something we'll keep spamming them until they approve :-) The [DENY case](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L586-L591) propagated to java and we are throwing the security exception. > Next time, what happens if for some reaon the token is no longer valid ? It just prompts a permission request again. > And what might make it invalid ? Adding or removing a display for example. > If the user denied screen 2, or added screen 2 later, would that not result in an invalid token and we'd know to ask again ? No reset needed ? Also I can't figure out if "validating" the token can cause the dialog as a side effect or if there's some API we explicitly call to request a new token. Let me elaborate how this `restore_token` works: We may or may not provide the `restore_token` while calling `SelectSources`. If the token provided is not valid (we have no control over this, it's checked on the system side), the permission prompt will appear. Later, after granting permissions, the `restore_token` is returned by [Start](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.Start) callback. We should [update](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L593-L611) it, as it may not be the same as we provided before. When we are calling the `resetScreenCapturePermission` we are not actually revoking the token from the system, we are just doesn't add it to the `SelectSources` call. (but, if needed, we can provide it later and it should work). So whenever we don't provide a valid token, we get a confirmation prompt. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1540951957 From erikj at openjdk.org Tue May 9 22:17:18 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 9 May 2023 22:17:18 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v9] In-Reply-To: References: Message-ID: <8-kD9iBw0LboYiC_RJnaHZdxySrxXG15ENceHPSt2qo=.8d0beed0-409d-4ba9-9b3e-bbb1cedceb6b@github.com> On Tue, 9 May 2023 21:46:42 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitspace errors. I think you also need to make a change to `GraalBuilderImage.gmk` and the target in `Main.gmk` that calls it. Otherwise this looks pretty good to me. make/Main.gmk line 1281: > 1279: all-bundles: product-bundles test-bundles docs-bundles static-libs-bundles > 1280: > 1281: ALL_TARGETS += buildtools hotspot hotspot-libs hotspot-static-libs hotspot-gensrc gensrc gendata \ Can you add a newline to try to keep line length in check here. No need to reformat the whole block, just don't let random lines shoot way over 80. ------------- PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1419519027 PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1189176422 From jiangli at openjdk.org Tue May 9 23:06:23 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 9 May 2023 23:06:23 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v10] In-Reply-To: References: Message-ID: <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com> > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Address comments from @erikj79: - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. - Split the long line at 1281 in Main.gmk. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/d30b3e34..45dd2a00 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=08-09 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Tue May 9 23:08:27 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 9 May 2023 23:08:27 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v9] In-Reply-To: <8-kD9iBw0LboYiC_RJnaHZdxySrxXG15ENceHPSt2qo=.8d0beed0-409d-4ba9-9b3e-bbb1cedceb6b@github.com> References: <8-kD9iBw0LboYiC_RJnaHZdxySrxXG15ENceHPSt2qo=.8d0beed0-409d-4ba9-9b3e-bbb1cedceb6b@github.com> Message-ID: On Tue, 9 May 2023 22:14:04 GMT, Erik Joelsson wrote: > I think you also need to make a change to `GraalBuilderImage.gmk` and the target in `Main.gmk` that calls it. Good catch! Fixed `GraalBuilderImage.gmk`, thanks! For the `graal-builder-image` target that uses `GraalBuilderImage.gmk`, it's already changed to use `static-libs-graal-image` as one of the DEPS. Please let me know if anything additional that I missed. > make/Main.gmk line 1281: > >> 1279: all-bundles: product-bundles test-bundles docs-bundles static-libs-bundles >> 1280: >> 1281: ALL_TARGETS += buildtools hotspot hotspot-libs hotspot-static-libs hotspot-gensrc gensrc gendata \ > > Can you add a newline to try to keep line length in check here. No need to reformat the whole block, just don't let random lines shoot way over 80. Done, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1540998009 PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1189206701 From psadhukhan at openjdk.org Wed May 10 04:44:24 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 May 2023 04:44:24 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification In-Reply-To: References: Message-ID: On Thu, 4 May 2023 16:26:47 GMT, Alexander Zvegintsev wrote: > We need to relax the java.awt.Robot specification according to the latest operating system trends. > This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. > > https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots > https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor > https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. > https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures src/java.desktop/share/classes/java/awt/Robot.java line 457: > 455: /** > 456: * Creates an image containing pixels read from the screen. This image does > 457: * not include the mouse cursor. We have seen in macOS specifically that absence of mouse cursor is not guaranteed and screen capture can contain mouse cursor, so I guess we should remove this line since we are updating the Robot specification now.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1189351240 From serb at openjdk.org Wed May 10 05:20:31 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 10 May 2023 05:20:31 GMT Subject: RFR: 8307165: java/awt/dnd/NoFormatsDropTest/NoFormatsDropTest.java timed out [v4] In-Reply-To: References: <7HBfuSIVyMXzu5Gu6hkXdYUEoUx_vxqioY01ypA96ZY=.3cc3ef6c-ba90-4385-b908-0694a24ac16d@github.com> Message-ID: On Fri, 5 May 2023 20:57:33 GMT, Damon Nguyen wrote: >> When converting this test to be applicable to be open sourced, changes were made. I reverted some of these changes to get the test stable again. Now it passes when run on various OS's 100x. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Make panels volatile. Move waitForIdle Can you please clarify how long the affected test was executed before the fix, it was slow or hung? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13761#issuecomment-1541366175 From sgehwolf at openjdk.org Wed May 10 09:08:21 2023 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 10 May 2023 09:08:21 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v10] In-Reply-To: <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com> References: <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com> Message-ID: On Tue, 9 May 2023 23:06:23 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Address comments from @erikj79: > - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. > - Split the long line at 1281 in Main.gmk. Looks fine to me. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1420136948 From erikj at openjdk.org Wed May 10 12:49:19 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 May 2023 12:49:19 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v10] In-Reply-To: <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com> References: <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com> Message-ID: <6FRecbkoJikA25hk24eO8JA_kIG2c1ie9DZ9-GYwMC4=.607ca420-7788-4574-aec4-5a47ae614238@github.com> On Tue, 9 May 2023 23:06:23 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Address comments from @erikj79: > - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. > - Split the long line at 1281 in Main.gmk. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1420562567 From kcr at openjdk.org Wed May 10 13:09:17 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 May 2023 13:09:17 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification In-Reply-To: References: Message-ID: On Thu, 4 May 2023 16:26:47 GMT, Alexander Zvegintsev wrote: > We need to relax the java.awt.Robot specification according to the latest operating system trends. > This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. > > https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots > https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor > https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. > https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures I left a few comments inline. src/java.desktop/share/classes/java/awt/Robot.java line 231: > 229: * @implNote the mouse pointer may not visually move on Linux systems > 230: * using Wayland, while the subsequent mousePress and mouseRelease > 231: * can be delivered to the correct location Since Wayland is an example, maybe say something more like this? "...may not visually move on some platforms, such as Linux systems using Wayland..." src/java.desktop/share/classes/java/awt/Robot.java line 431: > 429: * to capture screen content, and the required permissions are not granted, > 430: * then a {@code SecurityException} may be thrown, > 431: * or the content of the returned {@code Color} is undefined. Given that a `SecurityException` is only thrown on some platforms, is it worth throwing at all? Undefined colors can still occur, so I'm not sure I see much value in an exception. What do you envision that an application would do with the exception? ------------- PR Review: https://git.openjdk.org/jdk/pull/13809#pullrequestreview-1420578775 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1189868745 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1189875492 From kcr at openjdk.org Wed May 10 13:09:18 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 May 2023 13:09:18 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification In-Reply-To: References: Message-ID: <76rWeMMcbc_sYF_bGVrEBWNVSqHfElYb9sMT-9ZrY7o=.7f7663c6-045b-4167-9806-c75b87b7efd4@github.com> On Tue, 9 May 2023 20:14:56 GMT, Alexander Zvegintsev wrote: >>> I do not understand why we need this method. >> >> We need it in order to be able to revoke the saved permission. >> >> For example, it may be necessary if the user has two monitors, but the user only allowed access to one of them. >> If he later decides to get a screen capture of two monitors, with the current implementation it will be impossible to do so without this method. >> >> Alternatively, we can replace it with a system property that says should we keep the permission or not. >> It is discussed here https://github.com/openjdk/jdk/pull/13803#issuecomment-1540255849 >> >>> it needs a new bug ID. >> >> done > > Updated according to your comments. > I still left `revokeScreenCapturePermission` here for now, so that its documentation can be easily compared and aligned with the other documentation changes. > After finalization it will be moved to #13803 (if we decide to keep the method) I agree with Phil (and Sergey, who mentioned the same earlier). I'm not sure I see enough motivation for this method to justify adding it. It seems more like a workaround for an implementation quirk of Wayland to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1189882003 From azvegint at openjdk.org Wed May 10 13:56:56 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 10 May 2023 13:56:56 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v2] In-Reply-To: References: Message-ID: > We need to relax the java.awt.Robot specification according to the latest operating system trends. > This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. > > https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots > https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor > https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. > https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision: - rephrase wording about mouse pointer may not visually move - Remove mention of mouse cursor for screen capture ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13809/files - new: https://git.openjdk.org/jdk/pull/13809/files/4bbf519f..548d1824 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13809&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13809&range=00-01 Stats: 7 lines in 1 file changed: 1 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13809/head:pull/13809 PR: https://git.openjdk.org/jdk/pull/13809 From azvegint at openjdk.org Wed May 10 13:57:00 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 10 May 2023 13:57:00 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 12:54:37 GMT, Kevin Rushforth wrote: >> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision: >> >> - rephrase wording about mouse pointer may not visually move >> - Remove mention of mouse cursor for screen capture > > src/java.desktop/share/classes/java/awt/Robot.java line 231: > >> 229: * @implNote the mouse pointer may not visually move on Linux systems >> 230: * using Wayland, while the subsequent mousePress and mouseRelease >> 231: * can be delivered to the correct location > > Since Wayland is an example, maybe say something more like this? > > "...may not visually move on some platforms, such as Linux systems using Wayland..." Updated. Probably this can be covered by the line 80: `
  • ignoring or limiting specific requests for Robot generated (synthesized) events related to keyboard and mouse etc.
    • ` > src/java.desktop/share/classes/java/awt/Robot.java line 431: > >> 429: * to capture screen content, and the required permissions are not granted, >> 430: * then a {@code SecurityException} may be thrown, >> 431: * or the content of the returned {@code Color} is undefined. > > Given that a `SecurityException` is only thrown on some platforms, is it worth throwing at all? Undefined colors can still occur, so I'm not sure I see much value in an exception. What do you envision that an application would do with the exception? I agree, I'll try to come up with something less confusing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1189921904 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1189941047 From azvegint at openjdk.org Wed May 10 13:57:04 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 10 May 2023 13:57:04 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v2] In-Reply-To: References: Message-ID: <5FX05XLo8nEAzw-xkAJDGMuIajefzVA7mvCKM-Wd7SA=.a636fc67-2caa-4ae2-8797-f1c268a349c6@github.com> On Wed, 10 May 2023 04:40:31 GMT, Prasanta Sadhukhan wrote: >> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision: >> >> - rephrase wording about mouse pointer may not visually move >> - Remove mention of mouse cursor for screen capture > > src/java.desktop/share/classes/java/awt/Robot.java line 457: > >> 455: /** >> 456: * Creates an image containing pixels read from the screen. This image does >> 457: * not include the mouse cursor. > > We have seen in macOS specifically that absence of mouse cursor is not guaranteed and screen capture can contain mouse cursor, so I guess we should remove this line since we are updating the Robot specification now.. Sure, this is a good time to do it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1189924342 From dcubed at openjdk.org Wed May 10 14:39:23 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 10 May 2023 14:39:23 GMT Subject: RFR: 8307799: Newly added java/awt/dnd/MozillaDnDTest.java has invalid jtreg `@requires` clause Message-ID: <4WmbW9qc9T9akMYGD1PXHRHpMPiYIBfqLcuWtIx81Xk=.9ea51026-1bf5-461a-9589-d8f92d49770a@github.com> A trivial fix to adjust an `@requires` tag into the proper format. ------------- Commit messages: - Fix a bad copy-and-paste. - 8307799: Newly added java/awt/dnd/MozillaDnDTest.java has invalid jtreg `@requires` clause Changes: https://git.openjdk.org/jdk/pull/13906/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13906&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307799 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13906.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13906/head:pull/13906 PR: https://git.openjdk.org/jdk/pull/13906 From rriggs at openjdk.org Wed May 10 14:39:23 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 10 May 2023 14:39:23 GMT Subject: RFR: 8307799: Newly added java/awt/dnd/MozillaDnDTest.java has invalid jtreg `@requires` clause In-Reply-To: <4WmbW9qc9T9akMYGD1PXHRHpMPiYIBfqLcuWtIx81Xk=.9ea51026-1bf5-461a-9589-d8f92d49770a@github.com> References: <4WmbW9qc9T9akMYGD1PXHRHpMPiYIBfqLcuWtIx81Xk=.9ea51026-1bf5-461a-9589-d8f92d49770a@github.com> Message-ID: <_paRvolK9Sex0Szl7OBqAV8XdIv2qGGrW2shLKco-zs=.fe0d37b7-1157-4faa-92ca-ba9caa1d4132@github.com> On Wed, 10 May 2023 14:23:38 GMT, Daniel D. Daugherty wrote: > A trivial fix to adjust an `@requires` tag into the proper format. Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13906#pullrequestreview-1420776595 From azvegint at openjdk.org Wed May 10 14:39:24 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 10 May 2023 14:39:24 GMT Subject: RFR: 8307799: Newly added java/awt/dnd/MozillaDnDTest.java has invalid jtreg `@requires` clause In-Reply-To: <4WmbW9qc9T9akMYGD1PXHRHpMPiYIBfqLcuWtIx81Xk=.9ea51026-1bf5-461a-9589-d8f92d49770a@github.com> References: <4WmbW9qc9T9akMYGD1PXHRHpMPiYIBfqLcuWtIx81Xk=.9ea51026-1bf5-461a-9589-d8f92d49770a@github.com> Message-ID: On Wed, 10 May 2023 14:23:38 GMT, Daniel D. Daugherty wrote: > A trivial fix to adjust an `@requires` tag into the proper format. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13906#pullrequestreview-1420777471 From dcubed at openjdk.org Wed May 10 14:39:24 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 10 May 2023 14:39:24 GMT Subject: RFR: 8307799: Newly added java/awt/dnd/MozillaDnDTest.java has invalid jtreg `@requires` clause In-Reply-To: <_paRvolK9Sex0Szl7OBqAV8XdIv2qGGrW2shLKco-zs=.fe0d37b7-1157-4faa-92ca-ba9caa1d4132@github.com> References: <4WmbW9qc9T9akMYGD1PXHRHpMPiYIBfqLcuWtIx81Xk=.9ea51026-1bf5-461a-9589-d8f92d49770a@github.com> <_paRvolK9Sex0Szl7OBqAV8XdIv2qGGrW2shLKco-zs=.fe0d37b7-1157-4faa-92ca-ba9caa1d4132@github.com> Message-ID: On Wed, 10 May 2023 14:26:48 GMT, Roger Riggs wrote: >> A trivial fix to adjust an `@requires` tag into the proper format. > > Marked as reviewed by rriggs (Reviewer). @RogerRiggs and @azvegint - Thanks for the lightning fast reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13906#issuecomment-1542311143 From dcubed at openjdk.org Wed May 10 14:44:36 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 10 May 2023 14:44:36 GMT Subject: Integrated: 8307799: Newly added java/awt/dnd/MozillaDnDTest.java has invalid jtreg `@requires` clause In-Reply-To: <4WmbW9qc9T9akMYGD1PXHRHpMPiYIBfqLcuWtIx81Xk=.9ea51026-1bf5-461a-9589-d8f92d49770a@github.com> References: <4WmbW9qc9T9akMYGD1PXHRHpMPiYIBfqLcuWtIx81Xk=.9ea51026-1bf5-461a-9589-d8f92d49770a@github.com> Message-ID: On Wed, 10 May 2023 14:23:38 GMT, Daniel D. Daugherty wrote: > A trivial fix to adjust an `@requires` tag into the proper format. This pull request has now been integrated. Changeset: 1bca05ea Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/1bca05eace5c4622a1fd596f4ed196495a8801e4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8307799: Newly added java/awt/dnd/MozillaDnDTest.java has invalid jtreg `@requires` clause Reviewed-by: rriggs, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/13906 From jiangli at openjdk.org Wed May 10 15:15:29 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 May 2023 15:15:29 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com> References: <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com> Message-ID: On Wed, 3 May 2023 13:34:12 GMT, Erik Joelsson wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > The current target user of the .a libraries is GraalVM, so we should check with them that the changes to the contents of the `.a` files isn't impacting them in a bad way. @dougxc what do you think? Thanks a lot for the multiple iterations of the discussions and reviews in this PR thread. All the input, especially https://github.com/openjdk/jdk/pull/13768#pullrequestreview-1415436469 from @erikj79 helped shaped this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542387929 From jiangli at openjdk.org Wed May 10 16:23:06 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 May 2023 16:23:06 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v11] In-Reply-To: References: Message-ID: <8XdK5PaDhcdKRH67l1erHK0jLMDfo6Gz5qJxN53pGXg=.db58f51d-b5c0-4744-827b-9c74dd6cd9ec@github.com> > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS Jiangli Zhou 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 12 additional commits since the last revision: - Merge branch 'master' into JDK-8307194 - Address comments from @erikj79: - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. - Split the long line at 1281 in Main.gmk. - Fix whitspace errors. - Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS: - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk. - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS). - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/ directory. - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets. - Fix whitespace error in make/StaticJvmLibsImage.gmk. - - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw: - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a. - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a. - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib. - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now: - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk. - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk. - Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input. - Update make/StaticLibsImage.gmk thanks Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - Update make/StaticLibsImage.gmk Thanks Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - Update based on @erikj79 review comments and suggestions: - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk. - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk. - ... and 2 more: https://git.openjdk.org/jdk/compare/84938550...36526d4f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/45dd2a00..36526d4f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=09-10 Stats: 44134 lines in 1102 files changed: 31678 ins; 5168 del; 7288 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Wed May 10 17:13:13 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 May 2023 17:13:13 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v12] In-Reply-To: References: Message-ID: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS Jiangli Zhou 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 13 additional commits since the last revision: - Merge branch 'master' into JDK-8307194 - Merge branch 'master' into JDK-8307194 - Address comments from @erikj79: - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. - Split the long line at 1281 in Main.gmk. - Fix whitspace errors. - Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS: - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk. - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS). - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/ directory. - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets. - Fix whitespace error in make/StaticJvmLibsImage.gmk. - - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw: - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a. - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a. - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib. - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now: - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk. - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk. - Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input. - Update make/StaticLibsImage.gmk thanks Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - Update make/StaticLibsImage.gmk Thanks Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - ... and 3 more: https://git.openjdk.org/jdk/compare/54e2bacc...ba2e9ce6 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13768/files - new: https://git.openjdk.org/jdk/pull/13768/files/36526d4f..ba2e9ce6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=10-11 Stats: 125 lines in 7 files changed: 26 ins; 96 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768 PR: https://git.openjdk.org/jdk/pull/13768 From jiangli at openjdk.org Wed May 10 17:29:32 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 May 2023 17:29:32 GMT Subject: Integrated: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: Message-ID: On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote: > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS This pull request has now been integrated. Changeset: 1964954d Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/1964954da9ac1d020e0b5ba35893f475d86ec909 Stats: 178 lines in 8 files changed: 127 ins; 34 del; 17 mod 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries Reviewed-by: erikj, sgehwolf ------------- PR: https://git.openjdk.org/jdk/pull/13768 From dnguyen at openjdk.org Wed May 10 17:42:19 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 10 May 2023 17:42:19 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v2] In-Reply-To: <3j4se4PxZQeOAEGlftu1DglKSWYQ_9cjIisP3ygOoI0=.5ecf40ed-ed05-4b62-9145-2cd13eb4785c@github.com> References: <3j4se4PxZQeOAEGlftu1DglKSWYQ_9cjIisP3ygOoI0=.5ecf40ed-ed05-4b62-9145-2cd13eb4785c@github.com> Message-ID: On Mon, 8 May 2023 18:05:59 GMT, Tejesh R wrote: >> Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Changes requested by dnguyen (Committer). test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 24: > 22: */ > 23: /* > 24: @test Separate these comment blocks with a newline test/jdk/java/awt/Robot/RobotMoveMultiscreen.java line 24: > 22: */ > 23: /* > 24: @test Same. Needs newline test/jdk/java/awt/Robot/RobotMoveMultiscreen.java line 81: > 79: robot.waitForIdle(); > 80: > 81: if(testCondition == false) { Space after "if" ------------- PR Review: https://git.openjdk.org/jdk/pull/13828#pullrequestreview-1421027876 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1190162788 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1190164290 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1190165280 From serb at openjdk.org Wed May 10 17:43:24 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 10 May 2023 17:43:24 GMT Subject: RFR: JDK-8307083: Open source some drag and drop tests 3 [v3] In-Reply-To: <1_BHtnvEe4SYe_MVg4gvkSHbpPTeoKrS2RWG1OGyrf0=.1365e6d4-c61d-41b7-b19d-b3584a8293d7@github.com> References: <1_BHtnvEe4SYe_MVg4gvkSHbpPTeoKrS2RWG1OGyrf0=.1365e6d4-c61d-41b7-b19d-b3584a8293d7@github.com> Message-ID: <5_Ftkefi2DmVwYiTgGbeUQ4fzGp44jDNG3-ODaM5RTg=.604227db-9872-49f0-b71f-c7b681bab994@github.com> On Tue, 9 May 2023 18:05:39 GMT, Alisen Chung wrote: >> moving tests to open > > Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'JTREG_TEST_SPRINT3' of github.com:alisenchung/jdk into JTREG_TEST_SPRINT3 > - moved check onto EDT Looks fine, please confirm that mach5 is green. ------------- Marked as reviewed by serb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13764#pullrequestreview-1421115644 From serb at openjdk.org Wed May 10 17:44:29 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 10 May 2023 17:44:29 GMT Subject: RFR: 8307299: Move more DnD tests to open [v4] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 17:54:41 GMT, Alisen Chung wrote: >> Added DnD tests > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > fix space, add method on EDT test/jdk/java/awt/dnd/DropTargetingTest.java line 256: > 254: } > 255: > 256: public boolean getStatus() { This method(and probably some others) are not used? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13759#discussion_r1190222473 From serb at openjdk.org Wed May 10 17:48:24 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 10 May 2023 17:48:24 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com> On Tue, 9 May 2023 18:56:49 GMT, Rajat Mahajan wrote: >So, I added this code specifically to have improved rendering for the 25% cases, like 125%, 225%, 325% as rendering was a little off f But why it looks off if the clipRound is used? Does that size scales worse or does it cut the image at some direction? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1190225617 From achung at openjdk.org Wed May 10 18:48:51 2023 From: achung at openjdk.org (Alisen Chung) Date: Wed, 10 May 2023 18:48:51 GMT Subject: RFR: 8307297: Move some DnD tests to open [v5] In-Reply-To: References: Message-ID: > Adding some DnD tests Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: fixing timeouts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13756/files - new: https://git.openjdk.org/jdk/pull/13756/files/e1e0bc4d..1292a6a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13756&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13756&range=03-04 Stats: 11 lines in 2 files changed: 4 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13756/head:pull/13756 PR: https://git.openjdk.org/jdk/pull/13756 From prr at openjdk.org Wed May 10 19:35:51 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 10 May 2023 19:35:51 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 13:56:56 GMT, Alexander Zvegintsev wrote: >> We need to relax the java.awt.Robot specification according to the latest operating system trends. >> This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. >> >> https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots >> https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor >> https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. >> https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures > > Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision: > > - rephrase wording about mouse pointer may not visually move > - Remove mention of mouse cursor for screen capture Changes requested by prr (Reviewer). src/java.desktop/share/classes/java/awt/Robot.java line 229: > 227: /** > 228: * Moves mouse pointer to given screen coordinates. > 229: * @implNote the mouse pointer may not visually move on some platforms, This doesn't seem to be an implNote in the way that the JEP intends since it has nothing to do with anything we did in our implementation. I think it would have to be just spec, in which case I am not sure we should call out Linux+Wayland See https://openjdk.org/jeps/8068562 "Implementation Notes. This section contains informative notes about the implementation, such as advice to implementors, or performance characteristics that are specific to the implementation in this class of this version of the JDK. The information in this section is subject to change from release to release. These characteristics are also allowed to vary across platforms, vendors, and versions." src/java.desktop/share/classes/java/awt/Robot.java line 466: > 464: * The {@link #revokeScreenCapturePermission()} can be used to revoke > 465: * a previously granted permission. > 466: *

    I would like to completely separate any decision on adding revokeScreenCapturePermission from this spec. relaxation. So we should remove the reference to it here into a separate PR about adding that API although I'm still not convinced we should add it. src/java.desktop/share/classes/java/awt/Robot.java line 478: > 476: * @throws SecurityException if {@code readDisplayPixels} permission > 477: * is not granted, or user has not allowed any of his screens > 478: * to be captured. "user" -> "the user" "his" -> gender neutral "their". Or maybe better ", or access to the screen is denied by the desktop environment" ------------- PR Review: https://git.openjdk.org/jdk/pull/13809#pullrequestreview-1421248176 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1190309310 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1190314116 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1190316198 From prr at openjdk.org Wed May 10 19:35:53 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 10 May 2023 19:35:53 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 13:48:20 GMT, Alexander Zvegintsev wrote: >> src/java.desktop/share/classes/java/awt/Robot.java line 431: >> >>> 429: * to capture screen content, and the required permissions are not granted, >>> 430: * then a {@code SecurityException} may be thrown, >>> 431: * or the content of the returned {@code Color} is undefined. >> >> Given that a `SecurityException` is only thrown on some platforms, is it worth throwing at all? Undefined colors can still occur, so I'm not sure I see much value in an exception. What do you envision that an application would do with the exception? > > I agree, I'll try to come up with something less confusing. If there's no exception, how does the application know the colours aren't valid ? I think throwing the exception should be preferred behaviour and undefined colours would be just if we had no way to detect that there was a problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1190311693 From prr at openjdk.org Wed May 10 19:35:53 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 10 May 2023 19:35:53 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v2] In-Reply-To: <76rWeMMcbc_sYF_bGVrEBWNVSqHfElYb9sMT-9ZrY7o=.7f7663c6-045b-4167-9806-c75b87b7efd4@github.com> References: <76rWeMMcbc_sYF_bGVrEBWNVSqHfElYb9sMT-9ZrY7o=.7f7663c6-045b-4167-9806-c75b87b7efd4@github.com> Message-ID: On Wed, 10 May 2023 13:04:42 GMT, Kevin Rushforth wrote: >> Updated according to your comments. >> I still left `revokeScreenCapturePermission` here for now, so that its documentation can be easily compared and aligned with the other documentation changes. >> After finalization it will be moved to #13803 (if we decide to keep the method) > > I agree with Phil (and Sergey, who mentioned the same earlier). I'm not sure I see enough motivation for this method to justify adding it. It seems more like a workaround for an implementation quirk of Wayland to me. Like I wrote elsewhere, I am not sure how the app would know when to call this. And it is easy enough to use the preferences API to clear this out whilst we think more on this. BTW "reset" or "clear" might be better than "revoke" .. for all we know the current token denies access anyway and what we really mean is more like those other suggestions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1190318644 From abhiscxk at openjdk.org Wed May 10 20:08:42 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 10 May 2023 20:08:42 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 09:33:40 GMT, Abhishek Kumar wrote: >> This PR is to open source JMenuItem related swing tests. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update @prrace Please review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13822#issuecomment-1542740825 From erikj at openjdk.org Wed May 10 20:28:06 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 May 2023 20:28:06 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v12] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 17:13:13 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou 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 13 additional commits since the last revision: > > - Merge branch 'master' into JDK-8307194 > - Merge branch 'master' into JDK-8307194 > - Address comments from @erikj79: > - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. > - Split the long line at 1281 in Main.gmk. > - Fix whitspace errors. > - Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS: > > - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk. > > - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS). > - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/ directory. > > - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets. > - Fix whitespace error in make/StaticJvmLibsImage.gmk. > - - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw: > - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a. > - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a. > - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib. > - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now: > - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk. > - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk. > - Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input. > - Update make/StaticLibsIm... This change caused all our builds but Linux to fail. Did you verify on other platforms than Linux at all? I see you have GHA turned off. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542764704 From honkar at openjdk.org Wed May 10 20:33:41 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 10 May 2023 20:33:41 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 09:33:40 GMT, Abhishek Kumar wrote: >> This PR is to open source JMenuItem related swing tests. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update Marked as reviewed by honkar (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13822#pullrequestreview-1421335911 From jiangli at openjdk.org Wed May 10 20:41:56 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 May 2023 20:41:56 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v12] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 20:24:30 GMT, Erik Joelsson wrote: > This change caused all our builds but Linux to fail. Did you verify on other platforms than Linux at all? I see you have GHA turned off. Sorry about the issue. There were failed workflows after I merged with the latest JDK master this morning. I canceled the workflow and tried a rerun, which didn't work. I retried with a new commit with merging again. And noticed the GHA was off after merging with the latest master, but didn't know what caused it. The last night tests in the workflow (before merging with the master) were successful. So I proceeded with integration. Please let me know if we should back out or fix forward ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542779168 From honkar at openjdk.org Wed May 10 20:47:46 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 10 May 2023 20:47:46 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v2] In-Reply-To: References: Message-ID: <1rViBdv1WMeXJXXSm6Y7-HaSrP59FR6I5fcWrA8J2ts=.321e4c68-8c85-4997-981f-7ded99ad9439@github.com> On Mon, 8 May 2023 09:33:40 GMT, Abhishek Kumar wrote: >> This PR is to open source JMenuItem related swing tests. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update test/jdk/javax/swing/JMenuItem/bug4839464.java line 68: > 66: public static KeyStroke ks2 = > 67: KeyStroke.getKeyStroke(KeyEvent.VK_F1, > 68: KeyEvent.CTRL_MASK); Since SHIFT_MASK and CTRK_MASK are deprecated, you can use the new extended modifier constants here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1190378262 From honkar at openjdk.org Wed May 10 20:57:45 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 10 May 2023 20:57:45 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v2] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 16:23:09 GMT, Damon Nguyen wrote: >> test/jdk/javax/swing/JMenuItem/bug4839464.java line 220: >> >>> 218: // Check mnemonics >>> 219: int tmpInt = item.getMnemonic(); >>> 220: robo.clickMouseOn(changeMnemonicButton); >> >> @DamonGuy Util's JRobot is used here. > > Which part is a Util method? I see a JRobot method. Or is Util and JRobot linked somehow? My understanding is that they're separate since they're separate in regtesthelpers. @DamonGuy 'clickMouseOn()'. Earlier this test had a AWT Robot and JRobot. It has been changed recently to use AWT Robot only. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1190385701 From azvegint at openjdk.org Wed May 10 20:59:11 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 10 May 2023 20:59:11 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v3] In-Reply-To: References: Message-ID: > We need to relax the java.awt.Robot specification according to the latest operating system trends. > This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. > > https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots > https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor > https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. > https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision: - corrections - remove revokeScreenCapturePermission ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13809/files - new: https://git.openjdk.org/jdk/pull/13809/files/548d1824..cc192e9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13809&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13809&range=01-02 Stats: 36 lines in 2 files changed: 0 ins; 30 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13809/head:pull/13809 PR: https://git.openjdk.org/jdk/pull/13809 From azvegint at openjdk.org Wed May 10 20:59:12 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 10 May 2023 20:59:12 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 19:20:48 GMT, Phil Race wrote: >> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision: >> >> - rephrase wording about mouse pointer may not visually move >> - Remove mention of mouse cursor for screen capture > > src/java.desktop/share/classes/java/awt/Robot.java line 229: > >> 227: /** >> 228: * Moves mouse pointer to given screen coordinates. >> 229: * @implNote the mouse pointer may not visually move on some platforms, > > This doesn't seem to be an implNote in the way that the JEP > intends since it has nothing to do with anything we did in our implementation. I think it would have to be just spec, in which case I am not sure we should call out Linux+Wayland > > See https://openjdk.org/jeps/8068562 > > "Implementation Notes. This section contains informative notes about the implementation, such as advice to implementors, or performance characteristics that are specific to the implementation in this class of this version of the JDK. The information in this section is subject to change from release to release. These characteristics are also allowed to vary across platforms, vendors, and versions." Updated. > src/java.desktop/share/classes/java/awt/Robot.java line 466: > >> 464: * The {@link #revokeScreenCapturePermission()} can be used to revoke >> 465: * a previously granted permission. >> 466: *

    > > I would like to completely separate any decision on adding revokeScreenCapturePermission from > this spec. relaxation. > So we should remove the reference to it here into a separate PR about adding that API although I'm still not convinced we should add it. Removed from this PR > src/java.desktop/share/classes/java/awt/Robot.java line 478: > >> 476: * @throws SecurityException if {@code readDisplayPixels} permission >> 477: * is not granted, or user has not allowed any of his screens >> 478: * to be captured. > > "user" -> "the user" > "his" -> gender neutral "their". > Or maybe better ", or access to the screen is denied by the desktop environment" Updated to the former for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1190370654 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1190370807 PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1190374866 From erikj at openjdk.org Wed May 10 21:04:54 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 May 2023 21:04:54 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v12] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 20:38:50 GMT, Jiangli Zhou wrote: > > This change caused all our builds but Linux to fail. Did you verify on other platforms than Linux at all? I see you have GHA turned off. > > Sorry about the issue. There were failed workflows after I merged with the latest JDK master this morning. I canceled the workflow and tried a rerun, which didn't work. I retried with a new commit with merging again. And noticed the GHA was off after merging with the latest master, but didn't know what caused it. The last night tests in the workflow (before merging with the master) were successful. So I proceeded with integration. > > Please let me know if we should back out or fix forward ... Dan is already backing out in https://github.com/openjdk/jdk/pull/13918, so we have plenty of time to figure out the issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542805621 From dnguyen at openjdk.org Wed May 10 21:08:43 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 10 May 2023 21:08:43 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 20:54:26 GMT, Harshitha Onkar wrote: >> Which part is a Util method? I see a JRobot method. Or is Util and JRobot linked somehow? My understanding is that they're separate since they're separate in regtesthelpers. > > @DamonGuy 'clickMouseOn()'. Earlier this test had a AWT Robot and JRobot. It has been changed recently to use AWT Robot only. Gotcha. Just for my understanding, does JRobot depend on Util? `clickMouseOn` is in JRobot and I thought Util and JRobot were separate since they're java files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1190395065 From jiangli at openjdk.org Wed May 10 21:16:57 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 10 May 2023 21:16:57 GMT Subject: RFR: 8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v12] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 17:13:13 GMT, Jiangli Zhou wrote: >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > > Jiangli Zhou 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 13 additional commits since the last revision: > > - Merge branch 'master' into JDK-8307194 > - Merge branch 'master' into JDK-8307194 > - Address comments from @erikj79: > - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk. > - Split the long line at 1281 in Main.gmk. > - Fix whitspace errors. > - Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS: > > - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk. > > - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS). > - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/ directory. > > - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets. > - Fix whitespace error in make/StaticJvmLibsImage.gmk. > - - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw: > - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a. > - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a. > - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib. > - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now: > - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk. > - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk. > - Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input. > - Update make/StaticLibsIm... > > > This change caused all our builds but Linux to fail. Did you verify on other platforms than Linux at all? I see you have GHA turned off. > > > > > > Sorry about the issue. There were failed workflows after I merged with the latest JDK master this morning. I canceled the workflow and tried a rerun, which didn't work. I retried with a new commit with merging again. And noticed the GHA was off after merging with the latest master, but didn't know what caused it. The last night tests in the workflow (before merging with the master) were successful. So I proceeded with integration. > > Please let me know if we should back out or fix forward ... > > Dan is already backing out in #13918, so we have plenty of time to figure out the issues. Ok, thanks! Sorry about the build failure again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542817870 From prr at openjdk.org Wed May 10 21:37:42 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 10 May 2023 21:37:42 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v3] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 19:23:39 GMT, Phil Race wrote: >> I agree, I'll try to come up with something less confusing. > > If there's no exception, how does the application know the colours aren't valid ? > I think throwing the exception should be preferred behaviour and undefined colours would be just if we had no way to detect that there was a problem. BTW in the implementation PR, Alexander wrote The [DENY case](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L586-L591) propagated to java and we are throwing the security exception. So I interpret this as there is a use case for the exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1190414990 From prr at openjdk.org Wed May 10 22:02:42 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 10 May 2023 22:02:42 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 22:09:26 GMT, Alexander Zvegintsev wrote: > > I want to work through the scenarios and how much of it is specific to the behaviours of the API you are using and so forth. Since you use the Preferences API for saving the token, if you keyed it off the Robot class rather than the internal API class then anyone using the Preferences API could delete the token, couldn't they ? > > Right now it can be read with a simple call: `System.out.println(Preferences.userRoot().node("/sun/awt/screencast").get("restoreToken", ""));` (modification is also simple). > > Moving to Robot doesn't change anything in this regard. So anyone can delete it. I was thinking it better to make it an API class, but we can discuss later when we are sure we want the API at all. > > And we presumably can store alongside the token, info about the screens attached at the time we obtained the token ? > > We can try to do that and switch it depending on the area requested, but I tried to keep it simple. If it can avoid the need for dialogs in some additional cases, its worth it, but we can add this later, correct ? But it may be worth doing now - see comments below. > > > Can you point (here in the implementation review) to the exact native functions that popup up the dialog ? I'm still trying to find my way through that code. Is it opaque to the caller (us) what the user actually approved ? > > (It is collapsed by the github in the review, so links are to the branch) > > basically if you [didn't provide a correct token or no token at all](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L530-L537) to [SelectSources call](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L539-L546) it will prompt with dialog right after [the Start call](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L677-L685) > > > I can't imagine why we would need to reset "we have all permissions" to "we have no permissions" so I'm supposing the issue is when they didn't grant permissions .. but if they "deny" permissions that's surely different than "this token is no longer valid" ? > > It is not for the "we have all permissions" case, it is for the case when we only have a permission to some screens. So it won't hurt. But how does the app know when to call it ? > > > The first time we need a permission for the screencast API there is a dialog. The user makes some choices and we then choose to save a token so that the user isn't prompted again. We must at least know though that they approved SOMETHING but we don't know what ? Or do we ? > > No we don't. > > We receive the response [callbackScreenCastStart](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L586-L591) as a separate streams for each allowed display. > > Based on this response we [building a list of **available** displays](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L73). So denied screens will not be there. OK, so to make sure I understand, you use the token to see if you can obtain a stream for all connected displays. If any "fail" you know the user didn't approve that. So we can do this every time right ? And in conjunction with knowing which screen[s] were connected when we captured the token we know the situation changed and so we know it is appropriate to ignore the stored token - causing the user to be re-prompted. And even if the screens have changed if we already have the token we need for THIS screen capture we know whether we already have the permission we need. And if we do then we just use it and don't cause a user re-prompt. At this point I think we've done everything that "revoke" was needed for. Then [if I have everything right] the only open question is whether when permissions to the required screen or screens was previously denied, do we re-prompt ? My take is that we do not "store" a token that denies access. So next time the app is run they will be re-prompted. But we *probably* don't want to keep re-prompting within this running instance of the JDK. BTW "the app" means "any app that can find this token, doesn't it" ? This is probably what we want, and this is also how the Apple permissions work .. but maybe non-intuitive to users who don't know that both App A and App B are written in Java. I don't propose doing anything here, since if we tied it to a specific "class" then it would not work very well for 500 individual regression tests that each need robot :-) > > At this point we can compare this result with the screens got from X11 API(won't be compatible with Wayland, where we also want to reuse it later) or with Wayland(+1 dependency at this point). > > > If they DENY, would we save that ? Interesting question because if we don't save something we'll keep spamming them until they approve :-) > > The [DENY case](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L586-L591) propagated to java and we are throwing the security exception. > > > Next time, what happens if for some reaon the token is no longer valid ? > > It just prompts a permission request again. > > > And what might make it invalid ? > > Adding or removing a display for example. > > > If the user denied screen 2, or added screen 2 later, would that not result in an invalid token and we'd know to ask again ? No reset needed ? Also I can't figure out if "validating" the token can cause the dialog as a side effect or if there's some API we explicitly call to request a new token. > > Let me elaborate how this `restore_token` works: > > We may or may not provide the `restore_token` while calling `SelectSources`. > > If the token provided is not valid (we have no control over this, it's checked on the system side), the permission prompt will appear. > > Later, after granting permissions, the `restore_token` is returned by [Start](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.Start) callback. We should [update](https://github.com/azvegint/jdk/blob/482471df61490120590bc49886f76dc99c3d7dd8/src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c#L593-L611) it, as it may not be the same as we provided before. > > When we are calling the `resetScreenCapturePermission` we are not actually revoking the token from the system, we are just doesn't add it to the `SelectSources` call. (but, if needed, we can provide it later and it should work). I think most people reading the API would interpret it as "rm , not "don't use the token". And since its not tied to a particular invocation of Robot screen capture APIs it means that if you then call System.exit(0) right afterwards, so no new token is captured, it didn't do what you thought it did. Also if we follow the suggested policy of not storing tokens which don't grant permission then we'd also not over-write it in that case. > > So whenever we don't provide a valid token, we get a confirmation prompt. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1542866062 From tr at openjdk.org Thu May 11 05:27:52 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 11 May 2023 05:27:52 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v3] In-Reply-To: References: Message-ID: > Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. Tejesh R has updated the pull request incrementally with two additional commits since the last revision: - Updated based on review comments - Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13828/files - new: https://git.openjdk.org/jdk/pull/13828/files/e7d0a3ac..1ba7c25f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13828&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13828&range=01-02 Stats: 8 lines in 3 files changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13828.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13828/head:pull/13828 PR: https://git.openjdk.org/jdk/pull/13828 From tr at openjdk.org Thu May 11 05:27:54 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 11 May 2023 05:27:54 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v2] In-Reply-To: References: <3j4se4PxZQeOAEGlftu1DglKSWYQ_9cjIisP3ygOoI0=.5ecf40ed-ed05-4b62-9145-2cd13eb4785c@github.com> Message-ID: On Wed, 10 May 2023 16:41:55 GMT, Damon Nguyen wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/java/awt/Robot/RobotMoveMultiscreen.java line 81: > >> 79: robot.waitForIdle(); >> 80: >> 81: if(testCondition == false) { > > Space after "if" Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1190647136 From abhiscxk at openjdk.org Thu May 11 06:20:56 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 May 2023 06:20:56 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v3] In-Reply-To: References: Message-ID: <5uQiVadygsurc4POBOeykfRP4bunkfc7ybBUqtwlIOg=.0d065ee6-d13c-40a4-abbb-eabf9abce9c9@github.com> > This PR is to open source JMenuItem related swing tests. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Shift and Control mask modified ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13822/files - new: https://git.openjdk.org/jdk/pull/13822/files/172ae128..2db3db78 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13822&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13822&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13822/head:pull/13822 PR: https://git.openjdk.org/jdk/pull/13822 From psadhukhan at openjdk.org Thu May 11 06:39:42 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 11 May 2023 06:39:42 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v3] In-Reply-To: <5uQiVadygsurc4POBOeykfRP4bunkfc7ybBUqtwlIOg=.0d065ee6-d13c-40a4-abbb-eabf9abce9c9@github.com> References: <5uQiVadygsurc4POBOeykfRP4bunkfc7ybBUqtwlIOg=.0d065ee6-d13c-40a4-abbb-eabf9abce9c9@github.com> Message-ID: On Thu, 11 May 2023 06:20:56 GMT, Abhishek Kumar wrote: >> This PR is to open source JMenuItem related swing tests. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Shift and Control mask modified test/jdk/javax/swing/JMenuItem/bug4966168.java line 26: > 24: /* @test > 25: @bug 4966168 > 26: @summary JInternalFrame not serializable in Motif & GTK L&F I dont see the test being tested for Motif & GTK which are not default L&F...Probably we should iterate for all L&F just to be sure.. Also, all `throw new Error` should ideally be changed to `throw new RuntimeException` for all tests in this PR.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1190698651 From tr at openjdk.org Thu May 11 08:22:10 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 11 May 2023 08:22:10 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v7] In-Reply-To: References: Message-ID: > Open source few AWT ScrollPane related tests. Tejesh R has updated the pull request incrementally with two additional commits since the last revision: - Updated based on review comments - Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13621/files - new: https://git.openjdk.org/jdk/pull/13621/files/922bb902..32cc2acd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=05-06 Stats: 128 lines in 5 files changed: 33 ins; 40 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/13621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621 PR: https://git.openjdk.org/jdk/pull/13621 From tr at openjdk.org Thu May 11 08:22:10 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 11 May 2023 08:22:10 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v6] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 12:34:19 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed whitespace error > > test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 87: > >> 85: }); >> 86: >> 87: Thread.sleep(5000); > > Sleeping for 5 seconds could be too much. > > It would be great to ensure the updated test reproduces the problem that was fixed by [JDK-4342129](https://bugs.openjdk.org/browse/JDK-4342129) in 1.3.0 and 1.4.0. Otherwise, these 5 seconds could be a waste of time. I guess 1 second will be just fine. Updating it to 1 sec. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1190800258 From abhiscxk at openjdk.org Thu May 11 08:47:42 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 May 2023 08:47:42 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v3] In-Reply-To: References: <5uQiVadygsurc4POBOeykfRP4bunkfc7ybBUqtwlIOg=.0d065ee6-d13c-40a4-abbb-eabf9abce9c9@github.com> Message-ID: On Thu, 11 May 2023 06:37:22 GMT, Prasanta Sadhukhan wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Shift and Control mask modified > > test/jdk/javax/swing/JMenuItem/bug4966168.java line 26: > >> 24: /* @test >> 25: @bug 4966168 >> 26: @summary JInternalFrame not serializable in Motif & GTK L&F > > I dont see the test being tested for Motif & GTK which are not default L&F...Probably we should iterate for all L&F just to be sure.. > Also, all `throw new Error` should ideally be changed to `throw new RuntimeException` for all tests in this PR.. After modifying the test to run in all L&F, CI failure observed for linux and linux-aarch machine with the exception `javax.swing.UnsupportedLookAndFeelException: [GTK look and feel - com.sun.java.swing.plaf.gtk.GTKLookAndFeel] not supported on this platform`. On my local machine (Oracle Linux) test passed for all LAFs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1190842678 From psadhukhan at openjdk.org Thu May 11 09:23:45 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 11 May 2023 09:23:45 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v3] In-Reply-To: References: <5uQiVadygsurc4POBOeykfRP4bunkfc7ybBUqtwlIOg=.0d065ee6-d13c-40a4-abbb-eabf9abce9c9@github.com> Message-ID: On Thu, 11 May 2023 08:45:09 GMT, Abhishek Kumar wrote: >> test/jdk/javax/swing/JMenuItem/bug4966168.java line 26: >> >>> 24: /* @test >>> 25: @bug 4966168 >>> 26: @summary JInternalFrame not serializable in Motif & GTK L&F >> >> I dont see the test being tested for Motif & GTK which are not default L&F...Probably we should iterate for all L&F just to be sure.. >> Also, all `throw new Error` should ideally be changed to `throw new RuntimeException` for all tests in this PR.. > > After modifying the test to run in all L&F, CI failure observed for linux and linux-aarch machine with the exception > `javax.swing.UnsupportedLookAndFeelException: [GTK look and feel - com.sun.java.swing.plaf.gtk.GTKLookAndFeel] not supported on this platform`. > > On my local machine (Oracle Linux) test passed for all LAFs. It probably needs headful tag for that. Also, you should `continue` for UnsupportedLookAndFeelException...and not fail, just print a message and continue to next L&F ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1190886666 From abhiscxk at openjdk.org Thu May 11 10:02:03 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 May 2023 10:02:03 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v4] In-Reply-To: References: Message-ID: > This PR is to open source JMenuItem related swing tests. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Check for all LAFs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13822/files - new: https://git.openjdk.org/jdk/pull/13822/files/2db3db78..c286563c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13822&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13822&range=02-03 Stats: 18 lines in 2 files changed: 10 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13822/head:pull/13822 PR: https://git.openjdk.org/jdk/pull/13822 From abhiscxk at openjdk.org Thu May 11 10:02:05 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 May 2023 10:02:05 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v3] In-Reply-To: References: <5uQiVadygsurc4POBOeykfRP4bunkfc7ybBUqtwlIOg=.0d065ee6-d13c-40a4-abbb-eabf9abce9c9@github.com> Message-ID: <-ddgZzTepu5NVxJ4JQo67LP27oVbBh1n5WgFW8hdx0s=.2a0a245b-72c7-44f2-833e-04b566edcf18@github.com> On Thu, 11 May 2023 09:20:28 GMT, Prasanta Sadhukhan wrote: >> After modifying the test to run in all L&F, CI failure observed for linux and linux-aarch machine with the exception >> `javax.swing.UnsupportedLookAndFeelException: [GTK look and feel - com.sun.java.swing.plaf.gtk.GTKLookAndFeel] not supported on this platform`. >> >> On my local machine (Oracle Linux) test passed for all LAFs. > > It probably needs headful tag for that. > Also, you should `continue` for UnsupportedLookAndFeelException...and not fail, just print a message and continue to next L&F Updated for all LAFs. CI is green now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1190930252 From psadhukhan at openjdk.org Thu May 11 10:08:47 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 11 May 2023 10:08:47 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v4] In-Reply-To: References: Message-ID: <6vrx5lctoSK1drtFCulhZo1saWM5-DWi82gMwjD0ygY=.95dffad4-3595-4027-ad00-0a8d508c7087@github.com> On Thu, 11 May 2023 10:02:03 GMT, Abhishek Kumar wrote: >> This PR is to open source JMenuItem related swing tests. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Check for all LAFs test/jdk/javax/swing/JMenuItem/bug4966168.java line 63: > 61: } catch (Exception e) { > 62: System.out.println("Look and Feel not set: " + laf.getClassName()); > 63: continue; It should be only for UnsupportedLookAndFeelException...other Exception should fail the test.. test/jdk/javax/swing/JMenuItem/bug4966168.java line 70: > 68: } catch (Exception e) { > 69: throw new RuntimeException(e); > 70: } guess no need of try-catch..if there are exceptions, let it fail with original Exception ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1190941968 PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1190942016 From abhiscxk at openjdk.org Thu May 11 10:25:48 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 May 2023 10:25:48 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v5] In-Reply-To: References: Message-ID: > This PR is to open source JMenuItem related swing tests. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Review comment update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13822/files - new: https://git.openjdk.org/jdk/pull/13822/files/c286563c..0ae07169 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13822&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13822&range=03-04 Stats: 7 lines in 1 file changed: 1 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13822/head:pull/13822 PR: https://git.openjdk.org/jdk/pull/13822 From abhiscxk at openjdk.org Thu May 11 10:25:51 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 11 May 2023 10:25:51 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v4] In-Reply-To: <6vrx5lctoSK1drtFCulhZo1saWM5-DWi82gMwjD0ygY=.95dffad4-3595-4027-ad00-0a8d508c7087@github.com> References: <6vrx5lctoSK1drtFCulhZo1saWM5-DWi82gMwjD0ygY=.95dffad4-3595-4027-ad00-0a8d508c7087@github.com> Message-ID: On Thu, 11 May 2023 10:05:48 GMT, Prasanta Sadhukhan wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Check for all LAFs > > test/jdk/javax/swing/JMenuItem/bug4966168.java line 63: > >> 61: } catch (Exception e) { >> 62: System.out.println("Look and Feel not set: " + laf.getClassName()); >> 63: continue; > > It should be only for UnsupportedLookAndFeelException...other Exception should fail the test.. Updated. > test/jdk/javax/swing/JMenuItem/bug4966168.java line 70: > >> 68: } catch (Exception e) { >> 69: throw new RuntimeException(e); >> 70: } > > guess no need of try-catch..if there are exceptions, let it fail with original Exception Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1190959049 PR Review Comment: https://git.openjdk.org/jdk/pull/13822#discussion_r1190959161 From psadhukhan at openjdk.org Thu May 11 11:35:52 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 11 May 2023 11:35:52 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v5] In-Reply-To: References: Message-ID: <4uORLaAk3cCmz3LpHz17lr_fVcBR9cFfs4WdY5EHzbE=.a14518cc-14c7-4e45-b50c-33a74b3e38dd@github.com> On Thu, 11 May 2023 10:25:48 GMT, Abhishek Kumar wrote: >> This PR is to open source JMenuItem related swing tests. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13822#pullrequestreview-1422376694 From duke at openjdk.org Thu May 11 13:12:42 2023 From: duke at openjdk.org (Ravi Gupta) Date: Thu, 11 May 2023 13:12:42 GMT Subject: RFR: 8307325: Verify the focus owner when non focused windows requesting focus In-Reply-To: References: Message-ID: <2XsNOMnLOWOczfZuWIU_SH95BYy2LFH3TlnDmmVzHmQ=.86918127-8e9f-48c3-a7ea-87d3288f48ea@github.com> On Thu, 4 May 2023 05:41:43 GMT, Ravi Gupta wrote: > Write a test Check, when the top level Window is not the focused Window requesting for focus and becoming the Focus Owner for any Component in that Window checking the following > > 1.The Component is the Focus Owner and the Window becomes the focused Window If the platform supports cross requesting focus > across Windows. > 2.The request is remembered and be granted when the Window is later focused If the platform does not support requesting focus > across Windows. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. Any volunteers for a review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13790#issuecomment-1543980669 From azvegint at openjdk.org Thu May 11 14:16:46 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 11 May 2023 14:16:46 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 21:59:37 GMT, Phil Race wrote: > > It is not for the "we have all permissions" case, it is for the case when we only have a permission to some screens. So it won't hurt. > > But how does the app know when to call it ? Right now it doesn't know. If the user is not satisfied with the result, he can "reset" it. But it seems to be a weak position. > OK, so to make sure I understand, you use the token to see if you can obtain a stream for all connected displays. If any "fail" you know the user didn't approve that. > > So we can do this every time right ? And in conjunction with knowing which screen[s] were connected when we captured the token we know the situation changed and so we know it is appropriate to ignore the stored token - causing the user to be re-prompted. > > And even if the screens have changed if we already have the token we need for THIS screen capture we know whether we already have the permission we need. And if we do then we just use it and don't cause a user re-prompt. > > At this point I think we've done everything that "revoke" was needed for. The problem is how to relate the tokens to the screens. We don't have some universal id that says that the display we saved earlier is this current display. There is an opaque id of stream: https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.Start Stream properties include: id s Opaque identifier. **Will be unique for this stream and local to this session**. Will persist with future sessions, if they are restored using a restore token. This property was added in version 4 of this interface. Optional. But it didn't help much, as it local to the session(each token - different session), token looks like `0`, `1`, etc We can match the stream layout to the screen layout in the system, but it has its flaws: Let's say we have following layout of screens in system, displays have the same resolution(e.g. 1920*1080): ![image](https://github.com/openjdk/jdk/assets/77687766/92047fe4-ee31-4ae2-9327-c6d6516a34e9) Screen capture permission is granted for `A` and denied for `B`. 1. On a first run we are capturing screen area at `(100, 100, 100, 100)`. 2. We match an acquired `restore_token` to the screen at `(0,0,1920,1080)` 3. User decided to change screens to following layout: ![image](https://github.com/openjdk/jdk/assets/77687766/b68febd1-01f9-4528-a65c-aefa53d3b61a) 4. we are capturing screen area at `(100, 100, 100, 100)` again 5. Oh, we have a `restore_token` for the `(0,0,1920,1080)` screen, let's reuse it. 6. Ouch, we got black pixels because the token was issued for display `A` and it is now `(1920,0,1920,1080)` > Then [if I have everything right] the only open question is whether when permissions to the required screen or screens was previously denied, do we re-prompt ? My take is that we do not "store" a token that denies access. So next time the app is run they will be re-prompted. But we _probably_ don't want to keep re-prompting within this running instance of the JDK. > > BTW "the app" means "any app that can find this token, doesn't it" ? Yes, it is currently shared between Java applications for the same user. > Also if we follow the suggested policy of not storing tokens which don't grant permission then we'd also not over-write it in that case. Currently we only overwrite tokens when we get a new one from the system. In the full DENY case, we do not receive any token. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1544062418 From duke at openjdk.org Thu May 11 14:32:59 2023 From: duke at openjdk.org (duke) Date: Thu, 11 May 2023 14:32:59 GMT Subject: Withdrawn: JDK-8299052: ViewportOverlapping test fails intermittently on Win10 & Win11 In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 23:25:30 GMT, Harshitha Onkar wrote: > ViewportOverlapping was failing intermittently on Windows (Win10 & 11). Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class (OverlappingTestBase) to stabilize the test. > > Additionally added awt & swings tests to exclusiveAccess.dir in TEST.ROOT. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11747 From duke at openjdk.org Thu May 11 14:38:43 2023 From: duke at openjdk.org (lawrence.andrews) Date: Thu, 11 May 2023 14:38:43 GMT Subject: RFR: 8307325: Verify the focus owner when non focused windows requesting focus In-Reply-To: References: Message-ID: On Thu, 4 May 2023 05:41:43 GMT, Ravi Gupta wrote: > Write a test Check, when the top level Window is not the focused Window requesting for focus and becoming the Focus Owner for any Component in that Window checking the following > > 1.The Component is the Focus Owner and the Window becomes the focused Window If the platform supports cross requesting focus > across Windows. > 2.The request is remembered and be granted when the Window is later focused If the platform does not support requesting focus > across Windows. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. test/jdk/java/awt/Focus/CrossFocusRequestTest/CrossFocusRequestTest.java line 52: > 50: private volatile static Button button; > 51: private volatile static TextField textField; > 52: private volatile static int waitTimeout = 1000; Add final keyword since value does not change ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13790#discussion_r1191271215 From duke at openjdk.org Thu May 11 14:42:47 2023 From: duke at openjdk.org (lawrence.andrews) Date: Thu, 11 May 2023 14:42:47 GMT Subject: RFR: 8305427: Write a test Check whether focus changes as expected when requestFocus is used to traverse randomly around the window [v5] In-Reply-To: References: Message-ID: On Thu, 4 May 2023 09:56:18 GMT, Ravi Gupta wrote: >> This testcase Checking whether the Component becoming the Focus Owner and FocusEvent.FOCUS_GAINED will be received by the Component when the focus is requested on the component using requestFocus. >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision: > > code modified LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/13293#issuecomment-1544111847 From honkar at openjdk.org Thu May 11 15:28:51 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 11 May 2023 15:28:51 GMT Subject: RFR: 8306996: Open source Swing MenuItem related tests [v5] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 10:25:48 GMT, Abhishek Kumar wrote: >> This PR is to open source JMenuItem related swing tests. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update Marked as reviewed by honkar (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13822#pullrequestreview-1422879561 From aivanov at openjdk.org Thu May 11 16:52:25 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 11 May 2023 16:52:25 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java In-Reply-To: References: Message-ID: On Tue, 9 May 2023 16:08:22 GMT, Dmitry Markov wrote: > The new version of the test fails for me on macOS because CTRL + DOWN key combination is reserved by the operating system. It is necessary to disable "Application windows" system key shortcut to execute the test without failure. Yes, it's known. It is recommended to disable all system shortcuts for running client tests, see [the requirements on the wiki](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements#AutomatedclientGUItestingsystemsetuprequirements-macOS-SpecificSystemsetupnotes), which may be unfeasible for a system one uses day-to-day. > An interesting thing is that the old version of the test works fine even if "Application windows" system key shortcut is enabled. It's because the old test didn't open that popup or didn't check its position, I can't remember for sure. > I would suggest documenting (probably at testing.md/wiki page) that "Application windows" key shortcut should be disabled prior testing. It is already documented per the comment above. Do you also suggest changing the key stroke to another combination? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13578#issuecomment-1544334844 From dmarkov at openjdk.org Thu May 11 17:19:43 2023 From: dmarkov at openjdk.org (Dmitry Markov) Date: Thu, 11 May 2023 17:19:43 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 12:58:58 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > Noticed this test case not verifying all the cases which is intended. Modified it for improving the coverage for 3 type of popups (menu, context menu and combobox). > > Evaluating conditions: > 1. Not enough space for showing popup downwards(default layout), it should show upwards > 2. Window starts from negative position, Popup should show on visible area > > For achieving this following areas are modified > - Updated isPopupOnScreen by adding Additional checks (like the position of combobox popup is always verified) > - Menu creation made as function and reused for all menu creation. > - Updated ComboPopupCheckListener class and modified its popupMenuWillBecomeInvisible function. Made it as generic and it is capable to evaluate any combo box's position if this class set as its listener. > - This test case is not intended for multi monitor setup so added a check for identifying monitor, else error out. > - Updated CTRL_MASK to CTRL_DOWN_MASK for removing depreciation warnings and removed some other warnings. > > Please review this > > Regards, > Renjith. Marked as reviewed by dmarkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13578#pullrequestreview-1423094247 From dmarkov at openjdk.org Thu May 11 17:19:45 2023 From: dmarkov at openjdk.org (Dmitry Markov) Date: Thu, 11 May 2023 17:19:45 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java In-Reply-To: References: Message-ID: On Thu, 11 May 2023 16:50:00 GMT, Alexey Ivanov wrote: > > The new version of the test fails for me on macOS because CTRL + DOWN key combination is reserved by the operating system. It is necessary to disable "Application windows" system key shortcut to execute the test without failure. > > Yes, it's known. It is recommended to disable all system shortcuts for running client tests, see [the requirements on the wiki](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements#AutomatedclientGUItestingsystemsetuprequirements-macOS-SpecificSystemsetupnotes), which may be unfeasible for a system one uses day-to-day. > > > An interesting thing is that the old version of the test works fine even if "Application windows" system key shortcut is enabled. > > It's because the old test didn't open that popup or didn't check its position, I can't remember for sure. > > > I would suggest documenting (probably at testing.md/wiki page) that "Application windows" key shortcut should be disabled prior testing. > > It is already documented per the comment above. > > Do you also suggest changing the key stroke to another combination? Ah, I see. The previous version didn't cover all cases. It is up to author either to change the key stroke to another one or stay it as is. I am fine with the current version ------------- PR Comment: https://git.openjdk.org/jdk/pull/13578#issuecomment-1544387352 From jlu at openjdk.org Thu May 11 20:21:57 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 May 2023 20:21:57 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: > This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. > > In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Convert the merged master changes to UTF-8 - Merge master and fix conflicts - Close streams when finished loading into props - Adjust CF test to read in with UTF-8 to fix failing test - Reconvert CS.properties to UTF-8 - Revert all changes to CurrencySymbols.properties - Bug6204853 should not be converted - Copyright year for CompileProperties - Redo translation for CS.properties - Spot convert CurrencySymbols.properties - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a ------------- Changes: https://git.openjdk.org/jdk/pull/12726/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=05 Stats: 28877 lines in 493 files changed: 14 ins; 1 del; 28862 mod Patch: https://git.openjdk.org/jdk/pull/12726.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12726/head:pull/12726 PR: https://git.openjdk.org/jdk/pull/12726 From jlu at openjdk.org Thu May 11 21:39:50 2023 From: jlu at openjdk.org (Justin Lu) Date: Thu, 11 May 2023 21:39:50 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: On Thu, 11 May 2023 20:21:57 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. > > Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Convert the merged master changes to UTF-8 > - Merge master and fix conflicts > - Close streams when finished loading into props > - Adjust CF test to read in with UTF-8 to fix failing test > - Reconvert CS.properties to UTF-8 > - Revert all changes to CurrencySymbols.properties > - Bug6204853 should not be converted > - Copyright year for CompileProperties > - Redo translation for CS.properties > - Spot convert CurrencySymbols.properties > - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a Wondering if anyone has any thoughts on the consequences of this PR, in relation to Intellj's (and other IDEs) default encoding for .properties files. Intellj sets the default encoding for .properties files to ISO-8859-1, which would be the wrong encoding if the .properties files are converted to UTF-8 native. This would cause certain key,values to be skewed when represented in the file. Although the default file-encoding for .properties can be switched to UTF-8, it is not the default. Wondering what some solutions/thoughts to this are. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544708830 From honkar at openjdk.org Thu May 11 21:51:03 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 11 May 2023 21:51:03 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java In-Reply-To: References: Message-ID: On Thu, 11 May 2023 17:16:58 GMT, Dmitry Markov wrote: > Do you also suggest changing the key stroke to another combination? @aivanov-jdk @Renjithkannath I think the idea of changing the key combination would make it less confusing for someone testing it manually and to figure out that it fails because of Application Windows shortcut & then having to disable it. Or another option is to add a note in the test itself, probably in jtreg @summary tag or the test frame about having to disable the shortcut in Mac so that the tester is aware. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13578#issuecomment-1544710065 From naoto at openjdk.org Thu May 11 21:51:13 2023 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 11 May 2023 21:51:13 GMT Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v6] In-Reply-To: References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com> Message-ID: <2apKDcin5cwY53zz5jOIPhqm7cCWhyYMdsXGU4TauEk=.781d695e-39fe-46f7-bd03-be514ca0b85c@github.com> On Thu, 11 May 2023 20:21:57 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii. >> >> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file. > > Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Convert the merged master changes to UTF-8 > - Merge master and fix conflicts > - Close streams when finished loading into props > - Adjust CF test to read in with UTF-8 to fix failing test > - Reconvert CS.properties to UTF-8 > - Revert all changes to CurrencySymbols.properties > - Bug6204853 should not be converted > - Copyright year for CompileProperties > - Redo translation for CS.properties > - Spot convert CurrencySymbols.properties > - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a I think this is fine, as those properties files are JDK's own. I believe the benefit of moving to UTF-8 outweighs the issue you wrote, which can be remedied by changing the encoding in the IDEs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544722480 From honkar at openjdk.org Thu May 11 21:53:00 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 11 May 2023 21:53:00 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v3] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 05:27:52 GMT, Tejesh R wrote: >> Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. > > Tejesh R has updated the pull request incrementally with two additional commits since the last revision: > > - Updated based on review comments > - Updated based on review comments test/jdk/java/awt/Scrollbar/ScrollbarKeyControlTest.java line 143: > 141: robot.keyPress(KeyEvent.VK_END); > 142: robot.keyRelease(KeyEvent.VK_END); > 143: LOCK.wait(2000); @TejeshR13 Is a delay of 2s required between key presses? Seems a bit more than usual. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1191723610 From prr at openjdk.org Thu May 11 22:02:02 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 11 May 2023 22:02:02 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 20:41:06 GMT, Alexander Zvegintsev wrote: >> src/java.desktop/share/classes/java/awt/Robot.java line 478: >> >>> 476: * @throws SecurityException if {@code readDisplayPixels} permission >>> 477: * is not granted, or user has not allowed any of his screens >>> 478: * to be captured. >> >> "user" -> "the user" >> "his" -> gender neutral "their". >> Or maybe better ", or access to the screen is denied by the desktop environment" > > Updated to the former for now. I think you should draft the CSR now based on the current text. We may still need to tweak words like "or the user has not allowed any of their screens to be captured." based on developing understanding, or perhaps being careful not to be describe in the docs what happens to be the pipewire behaviour. In fact that is why I suggested my other words, because (1) there may be no user involved and (2) screen vs screens seems to be a pipewire / wayland concept. I'm pretty sure macOS just treats it as "the desktop" no matter how many monitors are involved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1191730203 From prr at openjdk.org Thu May 11 22:02:05 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 11 May 2023 22:02:05 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v3] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 20:59:11 GMT, Alexander Zvegintsev wrote: >> We need to relax the java.awt.Robot specification according to the latest operating system trends. >> This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. >> >> https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots >> https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor >> https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. >> https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures > > Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision: > > - corrections > - remove revokeScreenCapturePermission src/java.desktop/share/classes/java/awt/peer/RobotPeer.java line 2: > 1: /* > 2: * Copyright (c) 1999, 2023, Oracle and/or its affiliates. All rights reserved. This file no longer needed in this PR ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1191726964 From duke at openjdk.org Thu May 11 22:47:07 2023 From: duke at openjdk.org (babblebubble) Date: Thu, 11 May 2023 22:47:07 GMT Subject: RFR: 8221452: Window.setMinimumSize does not respect DPI scaling Message-ID: <7fZ5gO65xyT8dqEjqv_B9rUXZWJDwLHMC-IjCOJ856M=.712cde39-b694-4542-9a06-3fdf5566e609@github.com> Hi, I'm not sure if I did the formatting of this pull request right, new to this, but the bug was bothering me so I fixed it (took three attempts). All I had to do was add ScaleUpX and ScaleUpY and it fixed it. Sorry for being new to GitHub, I only made an account to fix this. ------------- Commit messages: - Fixed bug JDK-8221452 - Revert "Attempt 1 at fixing minimum size bug" - Attempt 1 at fixing minimum size bug Changes: https://git.openjdk.org/jdk/pull/13857/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13857&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8221452 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13857/head:pull/13857 PR: https://git.openjdk.org/jdk/pull/13857 From duke at openjdk.org Thu May 11 22:47:07 2023 From: duke at openjdk.org (babblebubble) Date: Thu, 11 May 2023 22:47:07 GMT Subject: RFR: 8221452: Window.setMinimumSize does not respect DPI scaling In-Reply-To: <7fZ5gO65xyT8dqEjqv_B9rUXZWJDwLHMC-IjCOJ856M=.712cde39-b694-4542-9a06-3fdf5566e609@github.com> References: <7fZ5gO65xyT8dqEjqv_B9rUXZWJDwLHMC-IjCOJ856M=.712cde39-b694-4542-9a06-3fdf5566e609@github.com> Message-ID: On Mon, 8 May 2023 00:49:58 GMT, babblebubble wrote: > Hi, I'm not sure if I did the formatting of this pull request right, new to this, but the bug was bothering me so I fixed it (took three attempts). > All I had to do was add ScaleUpX and ScaleUpY and it fixed it. > Sorry for being new to GitHub, I only made an account to fix this. > Hi @babblebubble, welcome to this OpenJDK project and thanks for contributing! > > We do not recognize you as [Contributor](https://openjdk.java.net/bylaws#contributor) and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow [the instructions](https://oca.opensource.oracle.com/). Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing `/signed` in a comment in this pull request. > > If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user babblebubble" as summary for the issue. > > If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing `/covered` in a comment in this pull request. I did sign it, waiting for it to be reviewed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13857#issuecomment-1538175200 From dnguyen at openjdk.org Thu May 11 23:07:44 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 11 May 2023 23:07:44 GMT Subject: RFR: 8307325: Verify the focus owner when non focused windows requesting focus In-Reply-To: References: Message-ID: On Thu, 11 May 2023 14:36:04 GMT, lawrence.andrews wrote: >> Write a test Check, when the top level Window is not the focused Window requesting for focus and becoming the Focus Owner for any Component in that Window checking the following >> >> 1.The Component is the Focus Owner and the Window becomes the focused Window If the platform supports cross requesting focus >> across Windows. >> 2.The request is remembered and be granted when the Window is later focused If the platform does not support requesting focus >> across Windows. >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > test/jdk/java/awt/Focus/CrossFocusRequestTest/CrossFocusRequestTest.java line 52: > >> 50: private volatile static Button button; >> 51: private volatile static TextField textField; >> 52: private volatile static int waitTimeout = 1000; > > Add final keyword since value does not change Agreed. This should be a final constant. And if you make it a constant, I don't think the volatile is necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13790#discussion_r1191765282 From dnguyen at openjdk.org Thu May 11 23:07:47 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 11 May 2023 23:07:47 GMT Subject: RFR: 8307325: Verify the focus owner when non focused windows requesting focus In-Reply-To: References: Message-ID: On Thu, 4 May 2023 05:41:43 GMT, Ravi Gupta wrote: > Write a test Check, when the top level Window is not the focused Window requesting for focus and becoming the Focus Owner for any Component in that Window checking the following > > 1.The Component is the Focus Owner and the Window becomes the focused Window If the platform supports cross requesting focus > across Windows. > 2.The request is remembered and be granted when the Window is later focused If the platform does not support requesting focus > across Windows. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. test/jdk/java/awt/Focus/CrossFocusRequestTest/CrossFocusRequestTest.java line 85: > 83: } > 84: > 85: robot.waitForIdle(); Did you mean to put delays here instead of waitForIdles? I believe you already have setAutoWaitForIdle to handle this. Might be better to set a delay(1000) instead for stability. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13790#discussion_r1191763671 From abhiscxk at openjdk.org Fri May 12 02:55:56 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 12 May 2023 02:55:56 GMT Subject: Integrated: 8306996: Open source Swing MenuItem related tests In-Reply-To: References: Message-ID: On Fri, 5 May 2023 04:56:22 GMT, Abhishek Kumar wrote: > This PR is to open source JMenuItem related swing tests. This pull request has now been integrated. Changeset: 73491fa4 Author: Abhishek Kumar URL: https://git.openjdk.org/jdk/commit/73491fa452e73cf7c02c577f4e3f1a34c02bea6d Stats: 459 lines in 4 files changed: 459 ins; 0 del; 0 mod 8306996: Open source Swing MenuItem related tests Reviewed-by: dnguyen, honkar, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/13822 From itakiguchi at openjdk.org Fri May 12 03:09:46 2023 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Fri, 12 May 2023 03:09:46 GMT Subject: RFR: 8307953: [AIX] C locale's font setting was changed by JEP 400 Message-ID: On AIX, lib/fontconfig.bfc file is used to find font setting. I ran SwingSet2 List demo program with AIX C locale. JDK21's line spacing is larger then JDK17. Screen shots are in [JDK-8307953](https://bugs.openjdk.org/browse/JDK-8307953). When I used `-Dfile.encoding=COMPAT` option on AIX C locale, SwingSet2 worked fine as expected. This situation happens `Charset.defaultCharset()` always returns UTF-8 after JEP 400 by default. `native.encoding` system property has platform's encoding/charset name. If platform's charset name is not supported by Java, charset name should be `UTF-8`. Additionally, following parts are changed: `src/java.desktop/aix/data/fontconfig/fontconfig.propertie`s has invalid charset name. For Java for AIX: - Encoding name for AIX's Zh_TW locale is `big5`, charset name should be `x-IBM950` instead of `big5`. - Encoding name for AIX's zh_CN locale is `IBM-eucCN`, charset name should be `x-IBM1383` instead of `x-EUCCN`. In my understanding, this fix affects just for AIX platform. Note: macos-x64 tier1 test was failed, but I think it's not related this PR. ------------- Commit messages: - 8307953: [AIX] C locale's font setting was changed by JEP 400 Changes: https://git.openjdk.org/jdk/pull/13937/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13937&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307953 Stats: 7 lines in 2 files changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13937.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13937/head:pull/13937 PR: https://git.openjdk.org/jdk/pull/13937 From tr at openjdk.org Fri May 12 03:35:46 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 12 May 2023 03:35:46 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v3] In-Reply-To: References: Message-ID: <0lI1_HILYpTYThMBxHabO6dQBlE6E92dfS1aUINGMFs=.5cd8e9dc-b779-4083-93c9-bc1bbd1e14f6@github.com> On Thu, 11 May 2023 21:50:06 GMT, Harshitha Onkar wrote: >> Tejesh R has updated the pull request incrementally with two additional commits since the last revision: >> >> - Updated based on review comments >> - Updated based on review comments > > test/jdk/java/awt/Scrollbar/ScrollbarKeyControlTest.java line 143: > >> 141: robot.keyPress(KeyEvent.VK_END); >> 142: robot.keyRelease(KeyEvent.VK_END); >> 143: LOCK.wait(2000); > > @TejeshR13 Is a delay of 2s required between key presses? Seems a bit more than usual. This is not a delay, maximum wait time is 2sec which doesn't seem to happen during the test execution unless scrollbar adjustment is not invoked. I think max wait time of 2sec in case of unlock failure is fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1191872271 From abhiscxk at openjdk.org Fri May 12 04:47:44 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 12 May 2023 04:47:44 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v3] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 05:27:52 GMT, Tejesh R wrote: >> Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. > > Tejesh R has updated the pull request incrementally with two additional commits since the last revision: > > - Updated based on review comments > - Updated based on review comments test/jdk/java/awt/Panel/SetForegroundTest.java line 48: > 46: } catch (ClassCastException cce) { > 47: System.out.println("TEST FAILED"); > 48: throw new RuntimeException("Test failed.", cce); I think try-catch block may not be needed here and for other tests as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1191896987 From duke at openjdk.org Fri May 12 05:03:46 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Fri, 12 May 2023 05:03:46 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java In-Reply-To: References: Message-ID: On Thu, 11 May 2023 16:50:00 GMT, Alexey Ivanov wrote: >> The new version of the test fails for me on macOS because CTRL + DOWN key combination is reserved by the operating system. It is necessary to disable "Application windows" system key shortcut to execute the test without failure. >> An interesting thing is that the old version of the test works fine even if "Application windows" system key shortcut is enabled. >> I would suggest documenting (probably at testing.md/wiki page) that "Application windows" key shortcut should be disabled prior testing. > >> The new version of the test fails for me on macOS because CTRL + DOWN key combination is reserved by the operating system. It is necessary to disable "Application windows" system key shortcut to execute the test without failure. > > Yes, it's known. It is recommended to disable all system shortcuts for running client tests, see [the requirements on the wiki](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements#AutomatedclientGUItestingsystemsetuprequirements-macOS-SpecificSystemsetupnotes), which may be unfeasible for a system one uses day-to-day. > >> An interesting thing is that the old version of the test works fine even if "Application windows" system key shortcut is enabled. > > It's because the old test didn't open that popup or didn't check its position, I can't remember for sure. > >> I would suggest documenting (probably at testing.md/wiki page) that "Application windows" key shortcut should be disabled prior testing. > > It is already documented per the comment above. > > Do you also suggest changing the key stroke to another combination? @aivanov-jdk , you are right "_the old test didn't open that popup and check its position_" and similarly some other cases also missed and that was the reason for updating the test case. Thank you @dmarkov20 bringing this point up and @honkar-jdk for your recommendation. Since system per-requirement is well documented look like we can keep it as it is. @aivanov-jdk please share your recommendation will update based on this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13578#issuecomment-1545142377 From tr at openjdk.org Fri May 12 05:32:14 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 12 May 2023 05:32:14 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v4] In-Reply-To: References: Message-ID: > Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13828/files - new: https://git.openjdk.org/jdk/pull/13828/files/1ba7c25f..c102c912 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13828&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13828&range=02-03 Stats: 23 lines in 2 files changed: 1 ins; 9 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/13828.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13828/head:pull/13828 PR: https://git.openjdk.org/jdk/pull/13828 From tr at openjdk.org Fri May 12 05:32:15 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 12 May 2023 05:32:15 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v3] In-Reply-To: References: Message-ID: <0kasqeDPvFSXFSbryJ3jmjDr60QFgjGJZvLP5c_lb6Q=.97257c94-43e5-473c-bfb3-e88cb0cf20a8@github.com> On Fri, 12 May 2023 04:36:09 GMT, Abhishek Kumar wrote: >> Tejesh R has updated the pull request incrementally with two additional commits since the last revision: >> >> - Updated based on review comments >> - Updated based on review comments > > test/jdk/java/awt/Panel/SetForegroundTest.java line 48: > >> 46: } catch (ClassCastException cce) { >> 47: System.out.println("TEST FAILED"); >> 48: throw new RuntimeException("Test failed.", cce); > > I think try-catch block may not be needed here and for other tests as well. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1191919881 From psadhukhan at openjdk.org Fri May 12 09:09:56 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 12 May 2023 09:09:56 GMT Subject: RFR: 8296920: Regression Test DialogOrient.java fails on MacOS Message-ID: Test was failing with PrinterException: Wrong Orientation since printing was done with default orientation. Fix is made to set the printable with correct PageFormat It was not seen prior to [JDK-8262731](https://bugs.openjdk.org/browse/JDK-8262731) probably because the exception was being swallowed.. ------------- Commit messages: - 8296920: Regression Test DialogOrient.java fails on MacOS Changes: https://git.openjdk.org/jdk/pull/13950/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13950&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296920 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13950.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13950/head:pull/13950 PR: https://git.openjdk.org/jdk/pull/13950 From duke at openjdk.org Fri May 12 12:08:45 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 12 May 2023 12:08:45 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code Message-ID: When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. With this PR we address only the platform dependent code changes. ------------- Commit messages: - JDK-8306304 Changes: https://git.openjdk.org/jdk/pull/13953/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13953&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306304 Stats: 36 lines in 9 files changed: 7 ins; 0 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/13953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13953/head:pull/13953 PR: https://git.openjdk.org/jdk/pull/13953 From duke at openjdk.org Fri May 12 12:26:52 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Fri, 12 May 2023 12:26:52 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java [v2] In-Reply-To: References: Message-ID: > Hi Reviewers, > Noticed this test case not verifying all the cases which is intended. Modified it for improving the coverage for 3 type of popups (menu, context menu and combobox). > > Evaluating conditions: > 1. Not enough space for showing popup downwards(default layout), it should show upwards > 2. Window starts from negative position, Popup should show on visible area > > For achieving this following areas are modified > - Updated isPopupOnScreen by adding Additional checks (like the position of combobox popup is always verified) > - Menu creation made as function and reused for all menu creation. > - Updated ComboPopupCheckListener class and modified its popupMenuWillBecomeInvisible function. Made it as generic and it is capable to evaluate any combo box's position if this class set as its listener. > - This test case is not intended for multi monitor setup so added a check for identifying monitor, else error out. > - Updated CTRL_MASK to CTRL_DOWN_MASK for removing depreciation warnings and removed some other warnings. > > Please review this > > Regards, > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Updated test description, disabling all system shortcut is required to run the test case on MAC ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13578/files - new: https://git.openjdk.org/jdk/pull/13578/files/b6b521b9..a46881b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13578&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13578&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13578.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13578/head:pull/13578 PR: https://git.openjdk.org/jdk/pull/13578 From duke at openjdk.org Fri May 12 12:26:53 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Fri, 12 May 2023 12:26:53 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 12:58:58 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > Noticed this test case not verifying all the cases which is intended. Modified it for improving the coverage for 3 type of popups (menu, context menu and combobox). > > Evaluating conditions: > 1. Not enough space for showing popup downwards(default layout), it should show upwards > 2. Window starts from negative position, Popup should show on visible area > > For achieving this following areas are modified > - Updated isPopupOnScreen by adding Additional checks (like the position of combobox popup is always verified) > - Menu creation made as function and reused for all menu creation. > - Updated ComboPopupCheckListener class and modified its popupMenuWillBecomeInvisible function. Made it as generic and it is capable to evaluate any combo box's position if this class set as its listener. > - This test case is not intended for multi monitor setup so added a check for identifying monitor, else error out. > - Updated CTRL_MASK to CTRL_DOWN_MASK for removing depreciation warnings and removed some other warnings. > > Please review this > > Regards, > Renjith. Updated @summary of the test case, thank you @dmarkov20 and @honkar-jdk for your review and suggestion. Please let me know is that help. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13578#issuecomment-1545658438 From erikj at openjdk.org Fri May 12 12:50:43 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 12 May 2023 12:50:43 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: References: Message-ID: On Fri, 12 May 2023 12:01:43 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13953#pullrequestreview-1424445347 From duke at openjdk.org Fri May 12 14:09:43 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 12 May 2023 14:09:43 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: References: Message-ID: On Fri, 12 May 2023 12:01:43 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. Thank you for reviewing ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1545806719 From azvegint at openjdk.org Fri May 12 15:23:56 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 12 May 2023 15:23:56 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v4] In-Reply-To: References: Message-ID: > We need to relax the java.awt.Robot specification according to the latest operating system trends. > This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. > > https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots > https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor > https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. > https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: update SecurityException, fix year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13809/files - new: https://git.openjdk.org/jdk/pull/13809/files/cc192e9c..04de71ac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13809&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13809&range=02-03 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13809/head:pull/13809 PR: https://git.openjdk.org/jdk/pull/13809 From tsteele at openjdk.org Fri May 12 15:27:46 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Fri, 12 May 2023 15:27:46 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: References: Message-ID: On Fri, 12 May 2023 12:01:43 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. Marked as reviewed by tsteele (Committer). src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp line 426: > 424: // Missing test if instr is commutative and if we should swap. > 425: if (right.value()->type()->as_LongConstant() && > 426: (x->op() == Bytecodes::_lsub && right.value()->type()->as_LongConstant()->value() == -32768 ) ) { I would prefer a shifted value here as it's usually more readable. If the compiler is being stubborn in its warnings, a comment explaining the magic value would be fine too. src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp line 480: > 478: // Missing test if instr is commutative and if we should swap. > 479: if (right.value()->type()->as_IntConstant() && > 480: (x->op() == Bytecodes::_isub && right.value()->type()->as_IntConstant()->value() == -32768) ) { As above. ------------- PR Review: https://git.openjdk.org/jdk/pull/13953#pullrequestreview-1424714446 PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1192505757 PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1192505876 From tsteele at openjdk.org Fri May 12 15:32:52 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Fri, 12 May 2023 15:32:52 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: References: Message-ID: <9lfGtX1kleo6vBh3j6_llYExI2XK4rAorE05To8P6Rk=.aa7f177b-40ac-4105-8fd9-7f72a34de2e6@github.com> On Fri, 12 May 2023 14:07:26 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > Thank you for reviewing Thanks for your PR @JoKern65. I've been wanting to go over the new ibm-clang compiler warnings as well. It would be nice to 'enable warnings as errors' by default after we make the transition. I'm not sure if it's been mentioned to you already. As I understand it, we usually wait for 2 reviews before proceeding with changes unless they are deemed trivial. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1545926700 From duke at openjdk.org Fri May 12 16:16:03 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 12 May 2023 16:16:03 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: References: Message-ID: On Fri, 12 May 2023 12:01:43 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. Explained change in a new comment -32768 means same as ((-1)<<15)) , but the compiler doesn't like this anymore. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1545976254 From duke at openjdk.org Fri May 12 16:16:01 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 12 May 2023 16:16:01 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: Message-ID: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. JoKern65 has updated the pull request incrementally with one additional commit since the last revision: cosmetic changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13953/files - new: https://git.openjdk.org/jdk/pull/13953/files/ad3be1bd..d7e2d4f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13953&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13953&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13953/head:pull/13953 PR: https://git.openjdk.org/jdk/pull/13953 From honkar at openjdk.org Fri May 12 16:24:51 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 12 May 2023 16:24:51 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java [v2] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 12:26:52 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> Noticed this test case not verifying all the cases which is intended. Modified it for improving the coverage for 3 type of popups (menu, context menu and combobox). >> >> Evaluating conditions: >> 1. Not enough space for showing popup downwards(default layout), it should show upwards >> 2. Window starts from negative position, Popup should show on visible area >> >> For achieving this following areas are modified >> - Updated isPopupOnScreen by adding Additional checks (like the position of combobox popup is always verified) >> - Menu creation made as function and reused for all menu creation. >> - Updated ComboPopupCheckListener class and modified its popupMenuWillBecomeInvisible function. Made it as generic and it is capable to evaluate any combo box's position if this class set as its listener. >> - This test case is not intended for multi monitor setup so added a check for identifying monitor, else error out. >> - Updated CTRL_MASK to CTRL_DOWN_MASK for removing depreciation warnings and removed some other warnings. >> >> Please review this >> >> Regards, >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated test description, disabling all system shortcut is required to run the test case on MAC LGTM ------------- Marked as reviewed by honkar (Committer). PR Review: https://git.openjdk.org/jdk/pull/13578#pullrequestreview-1424819907 From dnguyen at openjdk.org Fri May 12 16:39:56 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 May 2023 16:39:56 GMT Subject: RFR: 8306638: Open source some AWT tests related to datatransfer and Toolkit In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 13:48:16 GMT, Jayathirth D V wrote: > This PR open sources some tests related to AWT datatransfer and Toolkit. test/jdk/java/awt/Toolkit/ToolkitListenerTest/ToolkitListenerTest.java line 64: > 62: EventQueue.invokeAndWait(() -> { > 63: frame = new Frame("ToolkitListenerTest"); > 64: frame.setSize(200,200); Add a space after comma test/jdk/java/awt/datatransfer/DataFlavor/BestTextFlavorTest/BestTextFlavorTest.java line 67: > 65: System.out.println("ClassNotFound Exception is thrown when"+ > 66: "flavors are created"); > 67: }//catch We've been typically removing these comments at the end-brackets test/jdk/java/awt/datatransfer/DataFlavor/BestTextFlavorTest/BestTextFlavorTest.java line 85: > 83: if(bestFlavor2.match(bestFlavor1)) { > 84: System.out.println("The test is Passed"); > 85: System.out.println("Pass"); Redundant prints test/jdk/java/awt/datatransfer/FileTransferAWTLockTest/FileTransferAWTLockTest.java line 48: > 46: if (!(System.getProperty("os.name").startsWith("Linux"))) { > 47: return; > 48: } Isn't this already covered by the @requires? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1192583347 PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1192588172 PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1192588655 PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1192589278 From tsteele at openjdk.org Fri May 12 16:55:47 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Fri, 12 May 2023 16:55:47 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 16:16:01 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > cosmetic changes Thanks for adding that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1546024401 From aivanov at openjdk.org Fri May 12 18:35:51 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 May 2023 18:35:51 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java [v2] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 12:26:52 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> Noticed this test case not verifying all the cases which is intended. Modified it for improving the coverage for 3 type of popups (menu, context menu and combobox). >> >> Evaluating conditions: >> 1. Not enough space for showing popup downwards(default layout), it should show upwards >> 2. Window starts from negative position, Popup should show on visible area >> >> For achieving this following areas are modified >> - Updated isPopupOnScreen by adding Additional checks (like the position of combobox popup is always verified) >> - Menu creation made as function and reused for all menu creation. >> - Updated ComboPopupCheckListener class and modified its popupMenuWillBecomeInvisible function. Made it as generic and it is capable to evaluate any combo box's position if this class set as its listener. >> - This test case is not intended for multi monitor setup so added a check for identifying monitor, else error out. >> - Updated CTRL_MASK to CTRL_DOWN_MASK for removing depreciation warnings and removed some other warnings. >> >> Please review this >> >> Regards, >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated test description, disabling all system shortcut is required to run the test case on MAC Changes requested by aivanov (Reviewer). test/jdk/javax/swing/Popup/TaskbarPositionTest.java line 64: > 62: * @summary Tests the location of the heavy weight popup portion of JComboBox, > 63: * JMenu and JPopupMenu. > 64: * On MAC disable all system shortcuts before executing this test case. Well, the test uses only one particular shortcut which was introduced in macOS Ventura. I'd rather have a more specific statement, something like this: The test uses Ctrl+Down Arrow (?) which is a system shortcut on macOS, disable it in system settings, otherwise the test will fail. The systems which are exclusively used for running tests should have all system shortcuts disabled. It may be *unfeasible* to disable all the shortcuts on a system that you use regularly for doing your work as well as for running tests (while you're updating it or fixing a bug). ------------- PR Review: https://git.openjdk.org/jdk/pull/13578#pullrequestreview-1424983532 PR Review Comment: https://git.openjdk.org/jdk/pull/13578#discussion_r1192683506 From achung at openjdk.org Fri May 12 19:30:57 2023 From: achung at openjdk.org (Alisen Chung) Date: Fri, 12 May 2023 19:30:57 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v7] In-Reply-To: References: Message-ID: On Thu, 11 May 2023 08:22:10 GMT, Tejesh R wrote: >> Open source few AWT ScrollPane related tests. > > Tejesh R has updated the pull request incrementally with two additional commits since the last revision: > > - Updated based on review comments > - Updated based on review comments test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 81: > 79: EventQueue.invokeAndWait(() -> { > 80: frame.pack(); > 81: frame.setVisible(true); should frame setup code be moved into init()? test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 94: > 92: frame.setLocationRelativeTo(null); > 93: frame.setVisible(true); > 94: pane.doLayout(); frame setup moved to init() here too? test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 88: > 86: pane.add(button); > 87: buttonLoc = button.getLocationOnScreen(); > 88: buttonSize = button.getSize(); here too test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 92: > 90: frame.setLocationRelativeTo(null); > 91: frame.setVisible(true); > 92: paneInsets = sp.getInsets(); here too ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1192726569 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1192727481 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1192727730 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1192727939 From aivanov at openjdk.org Fri May 12 19:30:57 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 May 2023 19:30:57 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v7] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 19:24:07 GMT, Alisen Chung wrote: >> Tejesh R has updated the pull request incrementally with two additional commits since the last revision: >> >> - Updated based on review comments >> - Updated based on review comments > > test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 81: > >> 79: EventQueue.invokeAndWait(() -> { >> 80: frame.pack(); >> 81: frame.setVisible(true); > > should frame setup code be moved into init()? Does it matter? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1192729433 From achung at openjdk.org Fri May 12 21:28:13 2023 From: achung at openjdk.org (Alisen Chung) Date: Fri, 12 May 2023 21:28:13 GMT Subject: RFR: 8307297: Move some DnD tests to open [v6] In-Reply-To: References: Message-ID: > Adding some DnD tests Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: - remove extra robot waits causing timeouts - fix test timeout ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13756/files - new: https://git.openjdk.org/jdk/pull/13756/files/1292a6a5..257c49d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13756&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13756&range=04-05 Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13756/head:pull/13756 PR: https://git.openjdk.org/jdk/pull/13756 From achung at openjdk.org Fri May 12 21:28:15 2023 From: achung at openjdk.org (Alisen Chung) Date: Fri, 12 May 2023 21:28:15 GMT Subject: Integrated: 8307297: Move some DnD tests to open In-Reply-To: References: Message-ID: On Tue, 2 May 2023 17:49:39 GMT, Alisen Chung wrote: > Adding some DnD tests This pull request has now been integrated. Changeset: 3bf38761 Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/3bf3876185f7b9e7679af3fa22ec20887cd4e498 Stats: 1233 lines in 7 files changed: 1233 ins; 0 del; 0 mod 8307297: Move some DnD tests to open Reviewed-by: prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/13756 From kbarrett at openjdk.org Fri May 12 22:07:54 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 12 May 2023 22:07:54 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 16:16:01 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > cosmetic changes Changes requested by kbarrett (Reviewer). src/hotspot/cpu/ppc/ppc.ad line 11444: > 11442: effect(KILL cr0); > 11443: ins_cost(DEFAULT_COST * 5); > 11444: size((VM_Version::has_brw() ? 16 : 20)); What is it complaining about here? src/hotspot/os/aix/os_aix.cpp line 464: > 462: guarantee0(shmid != -1); // Should always work. > 463: // Try to set pagesize. > 464: struct shmid_ds shm_buf = { {0,0,0,0,0,0,0,0},0,0,0,0,0,0,0,0,0,0,0,0,0,0 }; Would just `= {};` work? (I think it should, but with warnings who knows...) src/java.desktop/aix/native/libawt/porting_aix.c line 49: > 47: for (;;) { > 48: if (addr >= p->ldinfo_textorg && > 49: (char*)addr < (char*)(p->ldinfo_textorg) + p->ldinfo_textsize) { What is being warned about here? At worst, could you just cast the RHS to `void*`? ------------- PR Review: https://git.openjdk.org/jdk/pull/13953#pullrequestreview-1425195126 PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1192823550 PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1192824441 PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1192825686 From kbarrett at openjdk.org Fri May 12 22:07:55 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 12 May 2023 22:07:55 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: Message-ID: <4YjPGApkbH1tUGsRDIx4zr0wNyWh_KlhmCTWcVlrzog=.8618971d-58be-46da-ba52-0041ab476d95@github.com> On Fri, 12 May 2023 15:16:36 GMT, Tyler Steele wrote: >> JoKern65 has updated the pull request incrementally with one additional commit since the last revision: >> >> cosmetic changes > > src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp line 426: > >> 424: // Missing test if instr is commutative and if we should swap. >> 425: if (right.value()->type()->as_LongConstant() && >> 426: (x->op() == Bytecodes::_lsub && right.value()->type()->as_LongConstant()->value() == -32768 ) ) { > > I would prefer a shifted value here as it's usually more readable. If the compiler is being stubborn in its warnings, a comment explaining the magic value would be fine too. What is the warning here? Note that we've already turned off `-Wshift-negative-value` for gcc and xlc (but not for clang, for some reason). See `# Disabled warnings` in CompileJvm.gmk. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1192821299 From kbarrett at openjdk.org Fri May 12 23:44:43 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 12 May 2023 23:44:43 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: <9lfGtX1kleo6vBh3j6_llYExI2XK4rAorE05To8P6Rk=.aa7f177b-40ac-4105-8fd9-7f72a34de2e6@github.com> References: <9lfGtX1kleo6vBh3j6_llYExI2XK4rAorE05To8P6Rk=.aa7f177b-40ac-4105-8fd9-7f72a34de2e6@github.com> Message-ID: <8qe3ls9E7_X2nbWJdGWtUQC-AGFswGkKNu9M5HEEBBg=.0e5e36c7-8339-45d1-a61f-93bc478cd8cc@github.com> On Fri, 12 May 2023 15:29:32 GMT, Tyler Steele wrote: > I'm not sure if it's been mentioned to you already. As I understand it, we usually wait for 2 reviews before proceeding with changes unless they are deemed trivial. Also wait for 24 hours. See https://openjdk.org/guide/#life-of-a-pr bullet 6. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1546438398 From rmahajan at openjdk.org Sun May 14 19:40:44 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Sun, 14 May 2023 19:40:44 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com> References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com> Message-ID: On Wed, 10 May 2023 17:45:17 GMT, Sergey Bylokhov wrote: >> So, I added this code specifically to have improved rendering for the 25% cases, like 125%, 225%, 325% as rendering was a little off for these scale values and empirically based on what we saw it looked better with this calculation. >> It is also important to note that windows is not consistent in what size it provides for a part(button) . For example for 150% it provides part size as 20 and we calculate it as 20 in above code. For 175% windows still provides 20 again (while we would expect higher value) and we calculate it as 23 and it works out good. But as I said earlier for 125% or 225% it works best with above code. >> The 20 vs 19 thing that I mentioned above was to just show that clipRound doesn't calculate it same was as my code and can have rendering repercussions as it is very sensitive to pixel variation , even 1 pixel variation causes rendering artifacts. > >>So, I added this code specifically to have improved rendering for the 25% cases, like 125%, 225%, 325% as rendering was a little off f > > But why it looks off if the clipRound is used? Does that size scales worse or does it cut the image at some direction? With clipRound this is what I see with 150% Scaling: ![image](https://github.com/openjdk/jdk/assets/79671271/600730d5-9eb3-42c9-a9d2-e40b42fb29b0) With the current code change this is what I see with 150% Scaling: ![image](https://github.com/openjdk/jdk/assets/79671271/66fc6278-08ea-474a-b26c-2fd007859093) I see it scaled down with clipRound. I think this because of the calculation difference I mentioned above, as this is very sensitive and even 1pixel here or there can cause rendering issues. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1193198693 From duke at openjdk.org Mon May 15 04:17:45 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 15 May 2023 04:17:45 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java [v3] In-Reply-To: References: Message-ID: > Hi Reviewers, > Noticed this test case not verifying all the cases which is intended. Modified it for improving the coverage for 3 type of popups (menu, context menu and combobox). > > Evaluating conditions: > 1. Not enough space for showing popup downwards(default layout), it should show upwards > 2. Window starts from negative position, Popup should show on visible area > > For achieving this following areas are modified > - Updated isPopupOnScreen by adding Additional checks (like the position of combobox popup is always verified) > - Menu creation made as function and reused for all menu creation. > - Updated ComboPopupCheckListener class and modified its popupMenuWillBecomeInvisible function. Made it as generic and it is capable to evaluate any combo box's position if this class set as its listener. > - This test case is not intended for multi monitor setup so added a check for identifying monitor, else error out. > - Updated CTRL_MASK to CTRL_DOWN_MASK for removing depreciation warnings and removed some other warnings. > > Please review this > > Regards, > Renjith. Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Updated test description with more meaning full message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13578/files - new: https://git.openjdk.org/jdk/pull/13578/files/a46881b2..833dee4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13578&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13578&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13578.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13578/head:pull/13578 PR: https://git.openjdk.org/jdk/pull/13578 From duke at openjdk.org Mon May 15 04:17:48 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 15 May 2023 04:17:48 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java [v2] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 18:32:29 GMT, Alexey Ivanov wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated test description, disabling all system shortcut is required to run the test case on MAC > > test/jdk/javax/swing/Popup/TaskbarPositionTest.java line 64: > >> 62: * @summary Tests the location of the heavy weight popup portion of JComboBox, >> 63: * JMenu and JPopupMenu. >> 64: * On MAC disable all system shortcuts before executing this test case. > > Well, the test uses only one particular shortcut which was introduced in macOS Ventura. > I'd rather have a more specific statement, something like this: The test uses Ctrl+Down Arrow (?) which is a system shortcut on macOS, disable it in system settings, otherwise the test will fail. > > The systems which are exclusively used for running tests should have all system shortcuts disabled. It may be *unfeasible* to disable all the shortcuts on a system that you use regularly for doing your work as well as for running tests (while you're updating it or fixing a bug). Thanks @aivanov-jdk, that make more sense and I have updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13578#discussion_r1193307899 From jdv at openjdk.org Mon May 15 06:26:02 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 15 May 2023 06:26:02 GMT Subject: RFR: 8306638: Open source some AWT tests related to datatransfer and Toolkit [v2] In-Reply-To: References: Message-ID: > This PR open sources some tests related to AWT datatransfer and Toolkit. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Update after review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13642/files - new: https://git.openjdk.org/jdk/pull/13642/files/677874f0..6b0f6511 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13642&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13642&range=00-01 Stats: 32 lines in 5 files changed: 9 ins; 1 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/13642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13642/head:pull/13642 PR: https://git.openjdk.org/jdk/pull/13642 From jdv at openjdk.org Mon May 15 06:31:50 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 15 May 2023 06:31:50 GMT Subject: RFR: 8306638: Open source some AWT tests related to datatransfer and Toolkit [v2] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 02:53:25 GMT, Sergey Bylokhov wrote: >> Surely it will be the EDT ? Why do you ask ? > > it sets a couple of flags that will be used on the main thread, see "start()" above I added logs and saw that before we check these flags we have synchronous EDT tasks, that is the reason it was not failing. But yes we need to check these flags in EDT only. @mrserb Now i am checking these flags in EDT. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1193375637 From jdv at openjdk.org Mon May 15 06:31:56 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 15 May 2023 06:31:56 GMT Subject: RFR: 8306638: Open source some AWT tests related to datatransfer and Toolkit [v2] In-Reply-To: References: Message-ID: <3O8FN60Y4Gz2X3lxCZaEPADnLi3A02Bw9OfEYRp2bc0=.244ad31c-aa8b-407e-b7c6-b23c3997ed78@github.com> On Fri, 12 May 2023 16:35:48 GMT, Damon Nguyen wrote: >> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after review comments > > test/jdk/java/awt/datatransfer/FileTransferAWTLockTest/FileTransferAWTLockTest.java line 48: > >> 46: if (!(System.getProperty("os.name").startsWith("Linux"))) { >> 47: return; >> 48: } > > Isn't this already covered by the @requires? I have kept it, so that it helps during standalone run without jtreg. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13642#discussion_r1193376465 From duke at openjdk.org Mon May 15 08:32:48 2023 From: duke at openjdk.org (JoKern65) Date: Mon, 15 May 2023 08:32:48 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: <2nOXHGp99zMM5YyMuMgN0blrNJjpXJjeLiJIc1dR4r0=.01e91354-789e-484f-a05c-01261354c0e8@github.com> On Fri, 12 May 2023 21:56:50 GMT, Kim Barrett wrote: >> JoKern65 has updated the pull request incrementally with one additional commit since the last revision: >> >> cosmetic changes > > src/hotspot/cpu/ppc/ppc.ad line 11444: > >> 11442: effect(KILL cr0); >> 11443: ins_cost(DEFAULT_COST * 5); >> 11444: size((VM_Version::has_brw() ? 16 : 20)); > > What is it complaining about here? /data/d042520/xlc17/jdk/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:426:97: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] I reverted my change in c1_LIRGenerator_ppc.cpp and added shift-negative-value to the DISABLED_WARNINGS_clang in CompileJvm.gmk. ad_ppc.cpp:18388:10: error: converting the result of '?:' with integer constants to a boolean always evaluates to 'true' [-Werror,-Wtautological-constant-compare] assert(VerifyOops || MachNode::size(ra_) <= VM_Version::has_brw() ? 16 : 20, "bad fixed size"); ^ Should I also add tautological-constant-compare to DISABLED_WARNINGS_clang in CompileJvm.gmk or where else? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193506933 From kbarrett at openjdk.org Mon May 15 09:37:46 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 15 May 2023 09:37:46 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <2nOXHGp99zMM5YyMuMgN0blrNJjpXJjeLiJIc1dR4r0=.01e91354-789e-484f-a05c-01261354c0e8@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <2nOXHGp99zMM5YyMuMgN0blrNJjpXJjeLiJIc1dR4r0=.01e91354-789e-484f-a05c-01261354c0e8@github.com> Message-ID: On Mon, 15 May 2023 08:29:31 GMT, JoKern65 wrote: >> src/hotspot/cpu/ppc/ppc.ad line 11444: >> >>> 11442: effect(KILL cr0); >>> 11443: ins_cost(DEFAULT_COST * 5); >>> 11444: size((VM_Version::has_brw() ? 16 : 20)); >> >> What is it complaining about here? > > /data/d042520/xlc17/jdk/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:426:97: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] > I reverted my change in c1_LIRGenerator_ppc.cpp and added shift-negative-value to the DISABLED_WARNINGS_clang in CompileJvm.gmk. > > ad_ppc.cpp:18388:10: error: converting the result of '?:' with integer constants to a boolean always evaluates to 'true' [-Werror,-Wtautological-constant-compare] > assert(VerifyOops || MachNode::size(ra_) <= VM_Version::has_brw() ? 16 : 20, "bad fixed size"); > ^ > Should I also add tautological-constant-compare to DISABLED_WARNINGS_clang in CompileJvm.gmk or where else? I see, so `size` is kind of macro-like, and is just textually splicing its argument expression into another expression. And without the added parens the resulting full expression for the assert isn't checking what's intended, due to operator precedence. This is in generated source; it might be better to find the code generator (somewhere in adlc) and change it to add appropriate parens, as there may be other similar places (both here and for other platforms) that aren't doing what's intended but are not triggering warnings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193579404 From kbarrett at openjdk.org Mon May 15 09:37:47 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 15 May 2023 09:37:47 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <2nOXHGp99zMM5YyMuMgN0blrNJjpXJjeLiJIc1dR4r0=.01e91354-789e-484f-a05c-01261354c0e8@github.com> Message-ID: On Mon, 15 May 2023 09:30:52 GMT, Kim Barrett wrote: >> /data/d042520/xlc17/jdk/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:426:97: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] >> I reverted my change in c1_LIRGenerator_ppc.cpp and added shift-negative-value to the DISABLED_WARNINGS_clang in CompileJvm.gmk. >> >> ad_ppc.cpp:18388:10: error: converting the result of '?:' with integer constants to a boolean always evaluates to 'true' [-Werror,-Wtautological-constant-compare] >> assert(VerifyOops || MachNode::size(ra_) <= VM_Version::has_brw() ? 16 : 20, "bad fixed size"); >> ^ >> Should I also add tautological-constant-compare to DISABLED_WARNINGS_clang in CompileJvm.gmk or where else? > > I see, so `size` is kind of macro-like, and is just textually splicing its argument expression into another expression. > And without the added parens the resulting full expression for the assert isn't checking what's intended, due > to operator precedence. > > This is in generated source; it might be better to find the code generator (somewhere in adlc) and change it > to add appropriate parens, as there may be other similar places (both here and for other platforms) that > aren't doing what's intended but are not triggering warnings. Such a fix of adlc is probably out of scope for this change though. We should probably have a separate bug for that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193581173 From duke at openjdk.org Mon May 15 09:37:50 2023 From: duke at openjdk.org (JoKern65) Date: Mon, 15 May 2023 09:37:50 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 21:59:11 GMT, Kim Barrett wrote: >> JoKern65 has updated the pull request incrementally with one additional commit since the last revision: >> >> cosmetic changes > > src/hotspot/os/aix/os_aix.cpp line 464: > >> 462: guarantee0(shmid != -1); // Should always work. >> 463: // Try to set pagesize. >> 464: struct shmid_ds shm_buf = { {0,0,0,0,0,0,0,0},0,0,0,0,0,0,0,0,0,0,0,0,0,0 }; > > Would just `= {};` work? (I think it should, but with warnings who knows...) os_aix.cpp:460:37: error: missing field 'gid' initializer [-Werror,-Wmissing-field-initializers] struct shmid_ds shm_buf = { 0 }; ={} seems to work, but I do not know if it works on every compiler because standard says: the initializer must be a **non-empty, (until C23)** brace-enclosed, comma-separated list of initializers for the members. Should I then disable Warning missing-field-initializers? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193583982 From duke at openjdk.org Mon May 15 09:46:53 2023 From: duke at openjdk.org (JoKern65) Date: Mon, 15 May 2023 09:46:53 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 22:01:46 GMT, Kim Barrett wrote: >> JoKern65 has updated the pull request incrementally with one additional commit since the last revision: >> >> cosmetic changes > > src/java.desktop/aix/native/libawt/porting_aix.c line 49: > >> 47: for (;;) { >> 48: if (addr >= p->ldinfo_textorg && >> 49: (char*)addr < (char*)(p->ldinfo_textorg) + p->ldinfo_textsize) { > > What is being warned about here? At worst, could you just cast the RHS to `void*`? /porting_aix.c:49:34: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] addr < p->ldinfo_textorg + p->ldinfo_textsize) { and with` void*` cast on RHS porting_aix.c:49:43: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] addr < (void*)(p->ldinfo_textorg) + p->ldinfo_textsize) { So either my code change or disabling warning gnu-pointer-arith. What would you prefer? and if you prefer disabling the Warning, where should I do it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193594350 From duke at openjdk.org Mon May 15 09:55:45 2023 From: duke at openjdk.org (JoKern65) Date: Mon, 15 May 2023 09:55:45 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <2nOXHGp99zMM5YyMuMgN0blrNJjpXJjeLiJIc1dR4r0=.01e91354-789e-484f-a05c-01261354c0e8@github.com> Message-ID: On Mon, 15 May 2023 09:32:26 GMT, Kim Barrett wrote: >> I see, so `size` is kind of macro-like, and is just textually splicing its argument expression into another expression. >> And without the added parens the resulting full expression for the assert isn't checking what's intended, due >> to operator precedence. >> >> This is in generated source; it might be better to find the code generator (somewhere in adlc) and change it >> to add appropriate parens, as there may be other similar places (both here and for other platforms) that >> aren't doing what's intended but are not triggering warnings. > > Such a fix of adlc is probably out of scope for this change though. We should probably have a separate bug for that. And what should I use as a workaround meanwhile to get our new compiler through? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193605092 From mdoerr at openjdk.org Mon May 15 12:38:48 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 15 May 2023 12:38:48 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 16:16:01 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > cosmetic changes Thanks for addressing all the warnings! Looks basically good to me. Some details need to get checked. src/hotspot/os/aix/os_aix.cpp line 677: > 675: #ifdef AIX_XLC_GE_17 > 676: #include "alloca.h" > 677: #endif Includes should better be at the beginning of the file. ------------- PR Review: https://git.openjdk.org/jdk/pull/13953#pullrequestreview-1426444262 PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193770194 From mdoerr at openjdk.org Mon May 15 12:38:51 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 15 May 2023 12:38:51 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <4YjPGApkbH1tUGsRDIx4zr0wNyWh_KlhmCTWcVlrzog=.8618971d-58be-46da-ba52-0041ab476d95@github.com> References: <4YjPGApkbH1tUGsRDIx4zr0wNyWh_KlhmCTWcVlrzog=.8618971d-58be-46da-ba52-0041ab476d95@github.com> Message-ID: On Fri, 12 May 2023 21:51:59 GMT, Kim Barrett wrote: >> src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp line 426: >> >>> 424: // Missing test if instr is commutative and if we should swap. >>> 425: if (right.value()->type()->as_LongConstant() && >>> 426: (x->op() == Bytecodes::_lsub && right.value()->type()->as_LongConstant()->value() == -32768 ) ) { >> >> I would prefer a shifted value here as it's usually more readable. If the compiler is being stubborn in its warnings, a comment explaining the magic value would be fine too. > > What is the warning here? Note that we've already turned off `-Wshift-negative-value` for gcc and xlc > (but not for clang, for some reason). See `# Disabled warnings` in CompileJvm.gmk. I think disabling the warning is fine. Alternatively, we could `#define MIN_INT16 -32768` somewhere or introduce `const int16_t min_int16 = (int16_t)1 << (sizeof(int16_t)*BitsPerByte-1);`. What do you prefer, Kim? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1193762594 From prr at openjdk.org Mon May 15 17:00:54 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 15 May 2023 17:00:54 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v4] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 15:23:56 GMT, Alexander Zvegintsev wrote: >> We need to relax the java.awt.Robot specification according to the latest operating system trends. >> This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. >> >> https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots >> https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor >> https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. >> https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > update SecurityException, fix year src/java.desktop/share/classes/java/awt/Robot.java line 475: > 473: * @see SecurityManager#checkPermission > 474: * @see AWTPermission > 475: */ BTW, all of the above also needs to be added to createMultiResolutionScreenCapture(..) ! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13809#discussion_r1194106007 From jiangli at openjdk.org Mon May 15 17:47:52 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 15 May 2023 17:47:52 GMT Subject: RFR: JDK-8308110: Resolve multiple definition of 'JNI_OnLoad_jsound' linking error Message-ID: Remove DEF_STATIC_JNI_OnLoad from src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c. src/java.desktop/share/native/libjsound/Platform.c defines DEF_STATIC_JNI_OnLoad for libjsound. ------------- Commit messages: - JDK-8308110: Resolve multiple definition of 'JNI_OnLoad_jsound' linking error Changes: https://git.openjdk.org/jdk/pull/13994/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13994&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308110 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13994.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13994/head:pull/13994 PR: https://git.openjdk.org/jdk/pull/13994 From azvegint at openjdk.org Mon May 15 19:54:06 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 15 May 2023 19:54:06 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v5] In-Reply-To: References: Message-ID: > We need to relax the java.awt.Robot specification according to the latest operating system trends. > This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. > > https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots > https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor > https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. > https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: update createMultiResolutionScreenCapture documentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13809/files - new: https://git.openjdk.org/jdk/pull/13809/files/04de71ac..6903d338 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13809&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13809&range=03-04 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13809/head:pull/13809 PR: https://git.openjdk.org/jdk/pull/13809 From serb at openjdk.org Mon May 15 20:57:48 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 15 May 2023 20:57:48 GMT Subject: RFR: 8306638: Open source some AWT tests related to datatransfer and Toolkit [v2] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 06:26:02 GMT, Jayathirth D V wrote: >> This PR open sources some tests related to AWT datatransfer and Toolkit. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update after review comments Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13642#pullrequestreview-1427354481 From dnguyen at openjdk.org Mon May 15 21:34:49 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 May 2023 21:34:49 GMT Subject: RFR: 8306638: Open source some AWT tests related to datatransfer and Toolkit [v2] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 06:26:02 GMT, Jayathirth D V wrote: >> This PR open sources some tests related to AWT datatransfer and Toolkit. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Update after review comments Marked as reviewed by dnguyen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13642#pullrequestreview-1427397951 From serb at openjdk.org Mon May 15 21:47:46 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 15 May 2023 21:47:46 GMT Subject: RFR: 8307299: Move more DnD tests to open [v4] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 17:54:41 GMT, Alisen Chung wrote: >> Added DnD tests > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > fix space, add method on EDT Looks fine, please confirm march5 is green. ------------- Marked as reviewed by serb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13759#pullrequestreview-1427411634 From serb at openjdk.org Mon May 15 21:56:44 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 15 May 2023 21:56:44 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com> Message-ID: <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com> On Sun, 14 May 2023 19:38:12 GMT, Rajat Mahajan wrote: >>>So, I added this code specifically to have improved rendering for the 25% cases, like 125%, 225%, 325% as rendering was a little off f >> >> But why it looks off if the clipRound is used? Does that size scales worse or does it cut the image at some direction? > > With clipRound this is what I see with 150% Scaling: > > ![image](https://github.com/openjdk/jdk/assets/79671271/600730d5-9eb3-42c9-a9d2-e40b42fb29b0) > > With the current code change this is what I see with 150% Scaling: > > ![image](https://github.com/openjdk/jdk/assets/79671271/66fc6278-08ea-474a-b26c-2fd007859093) > > I see it scaled down with clipRound. > I think this because of the calculation difference I mentioned above, as this is very sensitive and even 1pixel here or there can cause rendering issues. >From the picture above it does not seem that the difference is just 1 pixel, no? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1194398790 From rmahajan at openjdk.org Mon May 15 22:09:47 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Mon, 15 May 2023 22:09:47 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com> References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com> <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com> Message-ID: On Mon, 15 May 2023 21:53:58 GMT, Sergey Bylokhov wrote: >> With clipRound this is what I see with 150% Scaling: >> >> ![image](https://github.com/openjdk/jdk/assets/79671271/600730d5-9eb3-42c9-a9d2-e40b42fb29b0) >> >> With the current code change this is what I see with 150% Scaling: >> >> ![image](https://github.com/openjdk/jdk/assets/79671271/66fc6278-08ea-474a-b26c-2fd007859093) >> >> I see it scaled down with clipRound. >> I think this because of the calculation difference I mentioned above, as this is very sensitive and even 1pixel here or there can cause rendering issues. > > From the picture above it does not seem that the difference is just 1 pixel, no? Actually I literally didn't mean 1 physical pixel, it was more figurative to say that when the width calculation on Java side is reduced by 1 we see a big difference in final scaling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1194409519 From jdv at openjdk.org Tue May 16 04:14:00 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 16 May 2023 04:14:00 GMT Subject: Integrated: 8306638: Open source some AWT tests related to datatransfer and Toolkit In-Reply-To: References: Message-ID: <5Glqd2jwoSN9gf8Q73wrcFKXenXsoE_5Z0mQ-t_t6K4=.049c9ced-0064-42d1-a563-efa814e74e59@github.com> On Tue, 25 Apr 2023 13:48:16 GMT, Jayathirth D V wrote: > This PR open sources some tests related to AWT datatransfer and Toolkit. This pull request has now been integrated. Changeset: 2210e067 Author: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/2210e06788d14dab38f78d8b20a2397e633195af Stats: 863 lines in 5 files changed: 863 ins; 0 del; 0 mod 8306638: Open source some AWT tests related to datatransfer and Toolkit Reviewed-by: prr, serb, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/13642 From duke at openjdk.org Tue May 16 05:04:51 2023 From: duke at openjdk.org (Ravi Gupta) Date: Tue, 16 May 2023 05:04:51 GMT Subject: RFR: 8307325: Verify the focus owner when non focused windows requesting focus [v2] In-Reply-To: References: Message-ID: > Write a test Check, when the top level Window is not the focused Window requesting for focus and becoming the Focus Owner for any Component in that Window checking the following > > 1.The Component is the Focus Owner and the Window becomes the focused Window If the platform supports cross requesting focus > across Windows. > 2.The request is remembered and be granted when the Window is later focused If the platform does not support requesting focus > across Windows. > > Testing: > Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision: 8307325: Review comments fixed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13790/files - new: https://git.openjdk.org/jdk/pull/13790/files/57887a48..d09ead4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13790&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13790&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13790.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13790/head:pull/13790 PR: https://git.openjdk.org/jdk/pull/13790 From alanb at openjdk.org Tue May 16 05:43:43 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 May 2023 05:43:43 GMT Subject: RFR: JDK-8308110: Resolve multiple definition of 'JNI_OnLoad_jsound' linking error In-Reply-To: References: Message-ID: On Mon, 15 May 2023 17:41:18 GMT, Jiangli Zhou wrote: > Remove DEF_STATIC_JNI_OnLoad from src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c. src/java.desktop/share/native/libjsound/Platform.c defines DEF_STATIC_JNI_OnLoad for libjsound. Probably should wait for someone in the client libs area to review too but I think this is okay. It would require digging into the history to know how the duplicate came about when it is already defined in Platform.c. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13994#pullrequestreview-1427754182 From tr at openjdk.org Tue May 16 06:46:46 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 16 May 2023 06:46:46 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows Message-ID: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. ------------- Commit messages: - Fix + Manual Test Changes: https://git.openjdk.org/jdk/pull/13998/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307105 Stats: 87 lines in 2 files changed: 84 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13998/head:pull/13998 PR: https://git.openjdk.org/jdk/pull/13998 From aturbanov at openjdk.org Tue May 16 06:50:56 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 16 May 2023 06:50:56 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Mon, 8 May 2023 22:43:12 GMT, Rajat Mahajan wrote: >> Problem: >> >> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: >> >> - Scrawly ticks in checkboxes; >> - Wrong circle relations in selected radio buttons. >> >> Root-cause: >> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. >> Due to this when the app window goes to Secondary Screen with different DPI UI buttons >> appear incorrectly rendered. >> Following is a list proposed changes to fix this issue. >> >> >> Proposed Fix with Summary of changes: >> >> 1. Open a new Theme Handle per the DPI of the Screen where the App window is. >> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. >> window is. >> >> 2. GetPartSize() of icons returns size based on standard size = 96 DPI. >> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. >> >> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. >> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. >> >> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. >> --> This helps make sure that for .25s scaling we get better rendering. >> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. >> >> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. >> >> >> Testing: >> >> Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. >> >> ___________________________________ >> Monitor 1 | Monitor 2 >> (Primary) | >> | >> 125% | 175% >> 150% | 175% >> 150% | 225% >> 175% | 175% >> 175% | 150% >> 175% | 225% >> _____________________ |_____________ >> >> Also tested on setup with scaling values of up-to 350%. > > Rajat Mahajan has updated the pull request incrementally with two additional commits since the last revision: > > - code cleanup as per suggestions from reviewers > - code cleanup from suggestions in code review src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java line 710: > 708: // Get DPI to pass further to ThemeReader.paintBackground() > 709: Graphics2D g2d = (Graphics2D) g; > 710: AffineTransform at = g2d.getTransform(); nit Suggestion: AffineTransform at = g2d.getTransform(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1194690342 From mbaesken at openjdk.org Tue May 16 07:25:59 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 16 May 2023 07:25:59 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <4YjPGApkbH1tUGsRDIx4zr0wNyWh_KlhmCTWcVlrzog=.8618971d-58be-46da-ba52-0041ab476d95@github.com> Message-ID: On Mon, 15 May 2023 12:25:29 GMT, Martin Doerr wrote: >> What is the warning here? Note that we've already turned off `-Wshift-negative-value` for gcc and xlc >> (but not for clang, for some reason). See `# Disabled warnings` in CompileJvm.gmk. > > I think disabling the warning is fine. Alternatively, we could `#define MIN_INT16 -32768` somewhere or introduce `const int16_t min_int16 = (int16_t)1 << (sizeof(int16_t)*BitsPerByte-1);`. What do you prefer, Kim? Hi Martin/Joachim , I like the MIN_INT16 define idea Martin proposed, makes the code more readable and makes the warning go away . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1194725996 From psadhukhan at openjdk.org Tue May 16 09:03:03 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 16 May 2023 09:03:03 GMT Subject: RFR: 8306119: Many components respond to a mouse event by requesting focus without supplying the MOUSE_EVENT cause Message-ID: Many Swing components request a focus transfer in response to a mouse event, but fail to supply a Cause when requesting focus. A focus event listener will find the cause to be UNKNOWN, but MOUSE_EVENT would be more appropriate. Fixed by adding MOUSE_EVENT cause to requestFocus() when it is called for mouse events... ------------- Commit messages: - 8306119: Many components respond to a mouse event by requesting focus without supplying the MOUSE_EVENT cause Changes: https://git.openjdk.org/jdk/pull/14004/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14004&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306119 Stats: 27 lines in 11 files changed: 9 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/14004.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14004/head:pull/14004 PR: https://git.openjdk.org/jdk/pull/14004 From aturbanov at openjdk.org Tue May 16 10:20:54 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 16 May 2023 10:20:54 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Mon, 8 May 2023 22:43:12 GMT, Rajat Mahajan wrote: >> Problem: >> >> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: >> >> - Scrawly ticks in checkboxes; >> - Wrong circle relations in selected radio buttons. >> >> Root-cause: >> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. >> Due to this when the app window goes to Secondary Screen with different DPI UI buttons >> appear incorrectly rendered. >> Following is a list proposed changes to fix this issue. >> >> >> Proposed Fix with Summary of changes: >> >> 1. Open a new Theme Handle per the DPI of the Screen where the App window is. >> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. >> window is. >> >> 2. GetPartSize() of icons returns size based on standard size = 96 DPI. >> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. >> >> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. >> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. >> >> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. >> --> This helps make sure that for .25s scaling we get better rendering. >> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. >> >> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. >> >> >> Testing: >> >> Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. >> >> ___________________________________ >> Monitor 1 | Monitor 2 >> (Primary) | >> | >> 125% | 175% >> 150% | 175% >> 150% | 225% >> 175% | 175% >> 175% | 150% >> 175% | 225% >> _____________________ |_____________ >> >> Also tested on setup with scaling values of up-to 350%. > > Rajat Mahajan has updated the pull request incrementally with two additional commits since the last revision: > > - code cleanup as per suggestions from reviewers > - code cleanup from suggestions in code review src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 88: > 86: Long theme = null; > 87: > 88: if(dpiAwareWidgetToTheme.containsKey(dpi)) { Can we just call `dpiAwareWidgetToTheme.get(dpi)`, assign it to a variable and compare it with `null` ? It's faster then 2 containsKey+get calls. src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 104: > 102: } > 103: > 104: if (dpiAwareWidgetToTheme.get(dpi) != null) { use computeIfAbsent ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1194691227 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1194691909 From aivanov at openjdk.org Tue May 16 10:20:57 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 May 2023 10:20:57 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Tue, 16 May 2023 06:49:37 GMT, Andrey Turbanov wrote: >> Rajat Mahajan has updated the pull request incrementally with two additional commits since the last revision: >> >> - code cleanup as per suggestions from reviewers >> - code cleanup from suggestions in code review > > src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 104: > >> 102: } >> 103: >> 104: if (dpiAwareWidgetToTheme.get(dpi) != null) { > > use computeIfAbsent Yes, [`computeIfAbsent`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Map.html#computeIfAbsent(K,java.util.function.Function)) could simplify the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1194944245 From tr at openjdk.org Tue May 16 13:41:00 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 16 May 2023 13:41:00 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v7] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 19:28:11 GMT, Alexey Ivanov wrote: >> test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 81: >> >>> 79: EventQueue.invokeAndWait(() -> { >>> 80: frame.pack(); >>> 81: frame.setVisible(true); >> >> should frame setup code be moved into init()? > > Does it matter? Functionally doesn't matter, I guess its for code readability and uniformity. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1195180560 From tr at openjdk.org Tue May 16 14:10:32 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 16 May 2023 14:10:32 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v8] In-Reply-To: References: Message-ID: > Open source few AWT ScrollPane related tests. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13621/files - new: https://git.openjdk.org/jdk/pull/13621/files/32cc2acd..3571229e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=06-07 Stats: 55 lines in 4 files changed: 24 ins; 25 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621 PR: https://git.openjdk.org/jdk/pull/13621 From aivanov at openjdk.org Tue May 16 14:10:35 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 May 2023 14:10:35 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v7] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 13:37:33 GMT, Tejesh R wrote: >> Does it matter? > > Functionally doesn't matter, I guess its for grouping similar functionalities into particular methods. Yes, I agree it's better to combine them but then you could go further and remove `start()` and `init()` altogether. It would be good to be consistent across test groups especially those handled by one person. Yet I admit I didn't pay much attention to this thing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1195218418 From tr at openjdk.org Tue May 16 14:17:31 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 16 May 2023 14:17:31 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v9] In-Reply-To: References: Message-ID: > Open source few AWT ScrollPane related tests. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13621/files - new: https://git.openjdk.org/jdk/pull/13621/files/3571229e..c10491b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=07-08 Stats: 7 lines in 1 file changed: 5 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621 PR: https://git.openjdk.org/jdk/pull/13621 From tr at openjdk.org Tue May 16 14:17:34 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 16 May 2023 14:17:34 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v7] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 14:02:47 GMT, Alexey Ivanov wrote: >> Functionally doesn't matter, I guess its for grouping similar functionalities into particular methods. > > Yes, I agree it's better to combine them but then you could go further and remove `start()` and `init()` altogether. > > It would be good to be consistent across test groups especially those handled by one person. Yet I admit I didn't pay much attention to this thing. I have updated all the test for consistency. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1195232259 From tr at openjdk.org Tue May 16 14:30:48 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 16 May 2023 14:30:48 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v4] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 05:32:14 GMT, Tejesh R wrote: >> Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments @prrace I have updated all the review comments. Could you please re-review the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13828#issuecomment-1549787855 From jiangli at openjdk.org Tue May 16 14:54:45 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 16 May 2023 14:54:45 GMT Subject: RFR: JDK-8308110: Resolve multiple definition of 'JNI_OnLoad_jsound' linking error In-Reply-To: References: Message-ID: On Tue, 16 May 2023 05:40:34 GMT, Alan Bateman wrote: > Probably should wait for someone in the client libs area to review too but I think this is okay. It would require digging into the history to know how the duplicate came about when it is already defined in Platform.c. Thanks for the review. Will wait for additional review as suggested. According to `blame`, `DEF_STATIC_JNI_OnLoad` in PLATFORM_API_LinuxOS_ALSA_CommonUtils.c was added by https://github.com/openjdk/jdk/commit/3dc2d0258537bae096be7c15ac7cfc28b2729a53 for `8136556: Add the ability to perform static builds of MacOSX x64 binaries`. `DEF_STATIC_JNI_OnLoad` in libjsound/Platform.c was added in the same commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13994#issuecomment-1549831475 From asemenov at openjdk.org Tue May 16 17:56:04 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Tue, 16 May 2023 17:56:04 GMT Subject: RFR: 8302687 Implement interfaces and shared code for announcement feature [v5] In-Reply-To: References: Message-ID: > This enhancement covers basic API and shared code that should be implemented for the Accessibility Announcement feature. > > CSR [JDK-8304499](https://bugs.openjdk.org/browse/JDK-8304499 "bugs.openjdk.org") > > @mrserb @prrace @azuev-java please review Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13001/files - new: https://git.openjdk.org/jdk/pull/13001/files/a51d8a58..e904618a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13001&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13001&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13001.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13001/head:pull/13001 PR: https://git.openjdk.org/jdk/pull/13001 From achung at openjdk.org Tue May 16 18:54:59 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 16 May 2023 18:54:59 GMT Subject: RFR: 8307299: Move more DnD tests to open [v5] In-Reply-To: References: Message-ID: <2FLYWoHa5UFYRpF274HvXF2HtcaHbnj49i7do2Gp5ZQ=.bc0554b5-1dbf-4db7-9056-4049bca53338@github.com> > Added DnD tests Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: fix test timeout ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13759/files - new: https://git.openjdk.org/jdk/pull/13759/files/0f5df266..6ef6c730 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13759&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13759&range=03-04 Stats: 7 lines in 2 files changed: 2 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13759.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13759/head:pull/13759 PR: https://git.openjdk.org/jdk/pull/13759 From aivanov at openjdk.org Tue May 16 19:29:46 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 May 2023 19:29:46 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com> <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com> Message-ID: On Mon, 15 May 2023 22:06:11 GMT, Rajat Mahajan wrote: >> From the picture above it does not seem that the difference is just 1 pixel, no? > > Actually I literally didn't mean 1 physical pixel, it was more figurative to say that when the width calculation on Java side is reduced by 1 we see a big difference in final scaling. Perhaps, this needs additional details. The size of checkbox and radio button is 13 as reported by Theme API for the standard DPI of 96. Being a prime number, 13 doesn't scale well, there's always fractional part unless the scale is whole. Thus, the scaled size never matches. As the result, `CachedPainter` seems to apply a scale to compensate for that ? whether we choose ceil or floot. The entire thing should have been simpler: a `MultiResolutionImage` which paints the background according to the scale requested. Yet it proved to be not as simple. We're planning to look further into simplifying it if possible and, alternatively or in addition to, considering [dynamic layout based on graphics configuration](https://github.com/openjdk/jdk/pull/13701#discussion_r1187985627) as you suggested above. The current solution may be not perfect but it provides better rendering compared to what we have now: *the controls look crisp only on the main display*. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1195604571 From aivanov at openjdk.org Tue May 16 19:32:51 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 16 May 2023 19:32:51 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Fri, 28 Apr 2023 21:33:11 GMT, Sergey Bylokhov wrote: >> Rajat Mahajan has updated the pull request incrementally with two additional commits since the last revision: >> >> - code cleanup as per suggestions from reviewers >> - code cleanup from suggestions in code review > > src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java line 685: > >> 683: Graphics2D g2d = (Graphics2D) g; >> 684: AffineTransform at = g2d.getTransform(); >> 685: int dpi = (int)(at.getScaleX() * 96); > > I think this will not work if the image is not VolatileImage, the scale will be = 1 and as a result, the image could be twice smaller than expected on the HiDPI monitor since rescale operation in another place is deleted. Please double-check. Could you elaborate, please? How can this be not a `VolatileImage`? If the components are painted into a `BufferedImage`, the scale needs to be specified explicitly if it's the intent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1195606984 From abhiscxk at openjdk.org Wed May 17 03:37:46 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 17 May 2023 03:37:46 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows In-Reply-To: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: On Tue, 16 May 2023 06:40:20 GMT, Tejesh R wrote: > This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. > The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. test/jdk/javax/swing/JFileChooser/FileChooserIPETest.java line 80: > 78: frame.add(jfc, BorderLayout.CENTER); > 79: frame.pack(); > 80: frame.setVisible(true); Do we need to dispose the frame? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1195890917 From psadhukhan at openjdk.org Wed May 17 03:49:45 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 17 May 2023 03:49:45 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v7] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 06:44:20 GMT, Prasanta Sadhukhan wrote: >> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. >> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. >> Fixed by implementing the equality and hashCode method for CSS.FontSize class. >> >> All jtreg/jck tests are ok > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > hashCode fix @prrace @aivanov-jdk Any other comments for this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13405#issuecomment-1550655311 From dnguyen at openjdk.org Wed May 17 04:28:45 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 17 May 2023 04:28:45 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows In-Reply-To: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: On Tue, 16 May 2023 06:40:20 GMT, Tejesh R wrote: > This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. > The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. test/jdk/javax/swing/JFileChooser/FileChooserIPETest.java line 41: > 39: * @build PassFailJFrame > 40: * @summary Test to check if the certain windows like "This PC", > 41: * "Library","network" does not throw Invalid Path Exception on selection. Space after "," and capital "N" to maintain consistency test/jdk/javax/swing/JFileChooser/FileChooserIPETest.java line 54: > 52: public void run() { > 53: initialize(); > 54: } Does this need to be a "Runnable"? Can't initialize()'s contents just be put into main? I might be missing something ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1195912857 PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1195915673 From tr at openjdk.org Wed May 17 05:17:53 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 17 May 2023 05:17:53 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v7] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 14:02:47 GMT, Alexey Ivanov wrote: >> Functionally doesn't matter, I guess its for grouping similar functionalities into particular methods. > > Yes, I agree it's better to combine them but then you could go further and remove `start()` and `init()` altogether. > > It would be good to be consistent across test groups especially those handled by one person. Yet I admit I didn't pay much attention to this thing. @aivanov-jdk Can you please re-review the PR and see if its fine. I have updated all the review comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1195946976 From tr at openjdk.org Wed May 17 05:30:54 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 17 May 2023 05:30:54 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v2] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: On Wed, 17 May 2023 04:20:23 GMT, Damon Nguyen wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/javax/swing/JFileChooser/FileChooserIPETest.java line 41: > >> 39: * @build PassFailJFrame >> 40: * @summary Test to check if the certain windows like "This PC", >> 41: * "Library","network" does not throw Invalid Path Exception on selection. > > Space after "," and capital "N" to maintain consistency Updated. > test/jdk/javax/swing/JFileChooser/FileChooserIPETest.java line 54: > >> 52: public void run() { >> 53: initialize(); >> 54: } > > Does this need to be a "Runnable"? Can't initialize()'s contents just be put into main? I might be missing something Means you are pointing towards `new Runnable()` within Swing worker thread ? Or you are asking whether `initialize()` has to be in worker thread? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1195953039 PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1195954270 From tr at openjdk.org Wed May 17 05:30:51 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 17 May 2023 05:30:51 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v2] In-Reply-To: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: <7TY7wtbG2_gc5ILTXLkIGKK6nKF41y1zJl7IACHDsaE=.f31bec3d-9acf-4c98-9360-b82713168acc@github.com> > This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. > The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13998/files - new: https://git.openjdk.org/jdk/pull/13998/files/509b79f3..32cccee4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13998/head:pull/13998 PR: https://git.openjdk.org/jdk/pull/13998 From tr at openjdk.org Wed May 17 05:30:55 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 17 May 2023 05:30:55 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v2] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: On Wed, 17 May 2023 03:35:16 GMT, Abhishek Kumar wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/javax/swing/JFileChooser/FileChooserIPETest.java line 80: > >> 78: frame.add(jfc, BorderLayout.CENTER); >> 79: frame.pack(); >> 80: frame.setVisible(true); > > Do we need to dispose the frame? Not required when its been added to PassFailJFrame. PassFailJFrame takes care of frame dispose. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1195952498 From psadhukhan at openjdk.org Wed May 17 07:12:52 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 17 May 2023 07:12:52 GMT Subject: RFR: 8307311: Timeouts on one macOS 12.6.1 host of two Swing JTableHeader tests Message-ID: Issue was bug6889007.java was causing a timeout issue on mac system. Although bug6889007.java fail with small test group with "Wrong cursor type" error, it could not reproduce bug6884066.java It might be due to waitForIdle() being called in loop which will be calling sync() so replaced with delay.. Modified fix passed the suggested small test group `desktop_timeout ` several times in all platforms in addition to several iterations of the test run in standalone mode in all platforms.. ------------- Commit messages: - 8307311: Timeouts on one macOS 12.6.1 host of two Swing JTableHeader tests Changes: https://git.openjdk.org/jdk/pull/14026/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14026&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307311 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14026.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14026/head:pull/14026 PR: https://git.openjdk.org/jdk/pull/14026 From kbarrett at openjdk.org Wed May 17 09:47:46 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 May 2023 09:47:46 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> On Mon, 15 May 2023 09:34:28 GMT, JoKern65 wrote: >> src/hotspot/os/aix/os_aix.cpp line 464: >> >>> 462: guarantee0(shmid != -1); // Should always work. >>> 463: // Try to set pagesize. >>> 464: struct shmid_ds shm_buf = { {0,0,0,0,0,0,0,0},0,0,0,0,0,0,0,0,0,0,0,0,0,0 }; >> >> Would just `= {};` work? (I think it should, but with warnings who knows...) > > os_aix.cpp:460:37: error: missing field 'gid' initializer [-Werror,-Wmissing-field-initializers] > struct shmid_ds shm_buf = { 0 }; > > ={} seems to work, but I do not know if it works on every compiler because standard says: the initializer must be a **non-empty, (until C23)** brace-enclosed, comma-separated list of initializers for the members. > Should I then disable Warning missing-field-initializers? Use struct shmid_ds shm_buf{}; to _value-initialize_. Calls the default constructor if there is one. Otherwise, performs _zero-initialization_, which is what we want here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1196232015 From kbarrett at openjdk.org Wed May 17 09:58:45 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 May 2023 09:58:45 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <4YjPGApkbH1tUGsRDIx4zr0wNyWh_KlhmCTWcVlrzog=.8618971d-58be-46da-ba52-0041ab476d95@github.com> Message-ID: On Tue, 16 May 2023 07:22:44 GMT, Matthias Baesken wrote: >> I think disabling the warning is fine. Alternatively, we could `#define MIN_INT16 -32768` somewhere or introduce `const int16_t min_int16 = (int16_t)1 << (sizeof(int16_t)*BitsPerByte-1);`. What do you prefer, Kim? > > Hi Martin/Joachim , I like the MIN_INT16 define idea Martin proposed, makes the code more readable and makes the warning go away . Use `INT16_MIN`, which is in , which we already use. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1196239520 From kbarrett at openjdk.org Wed May 17 09:58:46 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 May 2023 09:58:46 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <2nOXHGp99zMM5YyMuMgN0blrNJjpXJjeLiJIc1dR4r0=.01e91354-789e-484f-a05c-01261354c0e8@github.com> Message-ID: On Mon, 15 May 2023 09:52:59 GMT, JoKern65 wrote: >> Such a fix of adlc is probably out of scope for this change though. We should probably have a separate bug for that. > > And what should I use as a workaround meanwhile to get our new compiler through? Now that I understand what the proposed change (adding an extra level of parens) is for, I'm okay with that for this PR. But there should be some followup to look at the code generated by adlc in this area. There could be other places where the wrong thing is being done but not generating a warning. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1196243839 From duke at openjdk.org Wed May 17 11:54:37 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 17 May 2023 11:54:37 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v3] In-Reply-To: References: Message-ID: <-9STqzY6P_smSUlD7O-3n0IXoPi5t1TYYmtIeFpbDR0=.dee45abf-c001-4498-908f-ca272b224ca6@github.com> > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. JoKern65 has updated the pull request incrementally with one additional commit since the last revision: followed the suggested changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13953/files - new: https://git.openjdk.org/jdk/pull/13953/files/d7e2d4f9..c3bd97b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13953&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13953&range=01-02 Stats: 12 lines in 2 files changed: 4 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13953/head:pull/13953 PR: https://git.openjdk.org/jdk/pull/13953 From mbaesken at openjdk.org Wed May 17 11:54:38 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 17 May 2023 11:54:38 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v3] In-Reply-To: <-9STqzY6P_smSUlD7O-3n0IXoPi5t1TYYmtIeFpbDR0=.dee45abf-c001-4498-908f-ca272b224ca6@github.com> References: <-9STqzY6P_smSUlD7O-3n0IXoPi5t1TYYmtIeFpbDR0=.dee45abf-c001-4498-908f-ca272b224ca6@github.com> Message-ID: <4FAR4XpMioQo1f-1Ynu7JJmAx96PuApjhtZXS7_3KYQ=.9364b390-032e-479a-8558-0167f3077c43@github.com> On Wed, 17 May 2023 11:49:24 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > followed the suggested changes Looks okay to me, thanks for addressing the issues. ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13953#pullrequestreview-1430464795 From duke at openjdk.org Wed May 17 11:54:41 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 17 May 2023 11:54:41 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 16:16:01 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > cosmetic changes I implemented all suggested changes. Thank you all for participating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1551237290 From mbaesken at openjdk.org Wed May 17 11:54:41 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 17 May 2023 11:54:41 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> Message-ID: On Fri, 12 May 2023 16:16:01 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. >> With this PR we address only the platform dependent code changes. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > cosmetic changes error in GHA is unrelated The following packages have unmet dependencies: libc6:i386 : Depends: libgcc-s1:i386 but it is not going to be installed libtiffxx5:i386 : Depends: libstdc++6:i386 (>= 5) but it is not going to be installed E: Unable to correct problems, you have held broken packages. Error: Process completed with exit code 100. probably some mess in the infra. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13953#issuecomment-1551246979 From duke at openjdk.org Wed May 17 11:54:44 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 17 May 2023 11:54:44 GMT Subject: Integrated: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code In-Reply-To: References: Message-ID: <0BTPHRbjRqlHSDzJJLkbJPC4Cqhgt1qN1a6RR8vTzGQ=.e73e0537-84c7-4764-a474-123dae1f46d5@github.com> On Fri, 12 May 2023 12:01:43 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Many of those are in the aix or ppc specific codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > With this PR we address only the platform dependent code changes. This pull request has now been integrated. Changeset: c7951cf6 Author: JoKern65 Committer: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/c7951cf674581ccd021e7403f5c3bd898e0542f4 Stats: 37 lines in 9 files changed: 8 ins; 0 del; 29 mod 8306304: Fix xlc17 clang warnings in ppc and aix code Reviewed-by: erikj, tsteele, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/13953 From duke at openjdk.org Wed May 17 12:33:56 2023 From: duke at openjdk.org (xpbob) Date: Wed, 17 May 2023 12:33:56 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 Message-ID: configure --enable-debug error: infinite recursion detected [-Werror=infinite-recursion] ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) configure java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] ?1161 | const LangSys& l = this+_.second.offset; ------------- Commit messages: - 8308283: Build failure with gcc 13.1.0 Changes: https://git.openjdk.org/jdk/pull/14032/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14032&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308283 Stats: 13 lines in 4 files changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14032/head:pull/14032 PR: https://git.openjdk.org/jdk/pull/14032 From asemenov at openjdk.org Wed May 17 12:35:47 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Wed, 17 May 2023 12:35:47 GMT Subject: RFR: 8308286 Fix clang warnings in linux code Message-ID: When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". They can be fixed with small changes. ------------- Commit messages: - 8308286 Fix clang warnings in linux code Changes: https://git.openjdk.org/jdk/pull/14033/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308286 Stats: 134 lines in 12 files changed: 126 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033 PR: https://git.openjdk.org/jdk/pull/14033 From erikj at openjdk.org Wed May 17 13:08:46 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 17 May 2023 13:08:46 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:26:22 GMT, xpbob wrote: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; Build changes look good. Someone from hotspot should also weigh in. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14032#pullrequestreview-1430645081 From jiangli at openjdk.org Wed May 17 15:02:51 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 17 May 2023 15:02:51 GMT Subject: RFR: JDK-8308110: Resolve multiple definition of 'JNI_OnLoad_jsound' linking error In-Reply-To: References: Message-ID: On Mon, 15 May 2023 17:41:18 GMT, Jiangli Zhou wrote: > Remove DEF_STATIC_JNI_OnLoad from src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c. src/java.desktop/share/native/libjsound/Platform.c defines DEF_STATIC_JNI_OnLoad for libjsound. Could someone also please take a look of this change? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13994#issuecomment-1551529452 From dnguyen at openjdk.org Wed May 17 16:17:38 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 17 May 2023 16:17:38 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v2] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: On Wed, 17 May 2023 05:25:42 GMT, Tejesh R wrote: >> test/jdk/javax/swing/JFileChooser/FileChooserIPETest.java line 54: >> >>> 52: public void run() { >>> 53: initialize(); >>> 54: } >> >> Does this need to be a "Runnable"? Can't initialize()'s contents just be put into main? I might be missing something > > Means you are pointing towards `new Runnable()` within Swing worker thread ? Or you are asking whether `initialize()` has to be in worker thread? I technically had 2 questions in the last comment. 1. Can't you just put the contents of `initialize()` in place of line 53? It's the only thing being run. 2. Why are we creating a `Runnable` instance instead of just calling `initialize` in main? And I have another completely separate comment. If you actually need this to be a `Runnable`, I think you can replace this with a lambda function. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1196771225 From tr at openjdk.org Wed May 17 16:28:58 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 17 May 2023 16:28:58 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v2] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: On Wed, 17 May 2023 16:14:43 GMT, Damon Nguyen wrote: >> Means you are pointing towards `new Runnable()` within Swing worker thread ? Or you are asking whether `initialize()` has to be in worker thread? > > I technically had 2 questions in the last comment. > 1. Can't you just put the contents of `initialize()` in place of line 53? It's the only thing being run. > 2. Why are we creating a `Runnable` instance instead of just calling `initialize` in main? > > And I have another completely separate comment. If you actually need this to be a `Runnable`, I think you can replace this with a lambda function. Point 1 can be done, nothing specific to adding everything into a function. Just that we are trying to maintain uniformity across other test. Point 2, it can be either with Runnable/direct lambda function, just that no return type is there we can use Runnable too I just choose it, nothing specific to functionlity. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1196783713 From tr at openjdk.org Wed May 17 16:47:56 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 17 May 2023 16:47:56 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> > This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. > The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13998/files - new: https://git.openjdk.org/jdk/pull/13998/files/32cccee4..5a791d0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=01-02 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13998/head:pull/13998 PR: https://git.openjdk.org/jdk/pull/13998 From rasbold at openjdk.org Wed May 17 17:12:53 2023 From: rasbold at openjdk.org (Chuck Rasbold) Date: Wed, 17 May 2023 17:12:53 GMT Subject: RFR: JDK-8308110: Resolve multiple definition of 'JNI_OnLoad_jsound' linking error In-Reply-To: References: Message-ID: On Mon, 15 May 2023 17:41:18 GMT, Jiangli Zhou wrote: > Remove DEF_STATIC_JNI_OnLoad from src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c. src/java.desktop/share/native/libjsound/Platform.c defines DEF_STATIC_JNI_OnLoad for libjsound. LGTM ------------- Marked as reviewed by rasbold (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13994#pullrequestreview-1431187676 From jiangli at openjdk.org Wed May 17 17:12:55 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 17 May 2023 17:12:55 GMT Subject: RFR: JDK-8308110: Resolve multiple definition of 'JNI_OnLoad_jsound' linking error In-Reply-To: References: Message-ID: On Mon, 15 May 2023 17:41:18 GMT, Jiangli Zhou wrote: > Remove DEF_STATIC_JNI_OnLoad from src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c. src/java.desktop/share/native/libjsound/Platform.c defines DEF_STATIC_JNI_OnLoad for libjsound. Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13994#issuecomment-1551776115 From prr at openjdk.org Wed May 17 18:52:53 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 17 May 2023 18:52:53 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 In-Reply-To: References: Message-ID: <2DGmslRRkkyYHGuhLnCslvb9-rC1ojbRkwzeEt_lT6E=.daa21a27-1410-4e84-af70-636b6bf35089@github.com> On Wed, 17 May 2023 12:26:22 GMT, xpbob wrote: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; This is a duplicate of https://bugs.openjdk.org/browse/JDK-8307210 Please check for existing reports before creating a new bug. We already plan to fix this before we officially upgrade to 13.1, until then you just disable the warning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1551894669 From achung at openjdk.org Wed May 17 19:03:36 2023 From: achung at openjdk.org (Alisen Chung) Date: Wed, 17 May 2023 19:03:36 GMT Subject: RFR: 8307299: Move more DnD tests to open [v6] In-Reply-To: References: Message-ID: > Added DnD tests Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: fix test timeout ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13759/files - new: https://git.openjdk.org/jdk/pull/13759/files/6ef6c730..faca0092 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13759&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13759&range=04-05 Stats: 51 lines in 2 files changed: 12 ins; 12 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/13759.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13759/head:pull/13759 PR: https://git.openjdk.org/jdk/pull/13759 From achung at openjdk.org Wed May 17 19:03:39 2023 From: achung at openjdk.org (Alisen Chung) Date: Wed, 17 May 2023 19:03:39 GMT Subject: Integrated: 8307299: Move more DnD tests to open In-Reply-To: References: Message-ID: On Tue, 2 May 2023 18:12:38 GMT, Alisen Chung wrote: > Added DnD tests This pull request has now been integrated. Changeset: 950c5df8 Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/950c5df859c373864ab4e7cf080c38bbd501e54b Stats: 1780 lines in 6 files changed: 1780 ins; 0 del; 0 mod 8307299: Move more DnD tests to open Reviewed-by: prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/13759 From jiangli at openjdk.org Wed May 17 21:07:56 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 17 May 2023 21:07:56 GMT Subject: Integrated: JDK-8308110: Resolve multiple definition of 'JNI_OnLoad_jsound' linking error In-Reply-To: References: Message-ID: <8g9Wbykq0-TZzGs_j1AZSK95Ru3T-ccgGWR0IHNolVM=.ba9ea0ac-6d3d-4700-a4de-10b7c3e6fbaf@github.com> On Mon, 15 May 2023 17:41:18 GMT, Jiangli Zhou wrote: > Remove DEF_STATIC_JNI_OnLoad from src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c. src/java.desktop/share/native/libjsound/Platform.c defines DEF_STATIC_JNI_OnLoad for libjsound. This pull request has now been integrated. Changeset: 902585be Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/902585bec1d4d5681208213bea180302d1b52df9 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod 8308110: Resolve multiple definition of 'JNI_OnLoad_jsound' linking error Reviewed-by: alanb, rasbold ------------- PR: https://git.openjdk.org/jdk/pull/13994 From achung at openjdk.org Wed May 17 21:50:50 2023 From: achung at openjdk.org (Alisen Chung) Date: Wed, 17 May 2023 21:50:50 GMT Subject: RFR: 8296920: Regression Test DialogOrient.java fails on MacOS In-Reply-To: References: Message-ID: On Fri, 12 May 2023 09:03:07 GMT, Prasanta Sadhukhan wrote: > Test was failing with PrinterException: Wrong Orientation since printing was done with default orientation. > Fix is made to set the printable with correct PageFormat > > It was not seen prior to [JDK-8262731](https://bugs.openjdk.org/browse/JDK-8262731) probably because the exception was being swallowed.. test/jdk/java/awt/print/Dialog/DialogOrient.java line 73: > 71: PrinterJob job = PrinterJob.getPrinterJob(); > 72: PageFormat landscape = job.pageDialog(job.defaultPage()); > 73: job.setPrintable(new DialogOrient(), landscape); why doesn't job.setPrintable(DialogOrient) work here? doesn't job.pageDialog already set the job orientation to landscape? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13950#discussion_r1197084889 From jiefu at openjdk.org Wed May 17 23:08:48 2023 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 17 May 2023 23:08:48 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 In-Reply-To: <2DGmslRRkkyYHGuhLnCslvb9-rC1ojbRkwzeEt_lT6E=.daa21a27-1410-4e84-af70-636b6bf35089@github.com> References: <2DGmslRRkkyYHGuhLnCslvb9-rC1ojbRkwzeEt_lT6E=.daa21a27-1410-4e84-af70-636b6bf35089@github.com> Message-ID: On Wed, 17 May 2023 18:49:44 GMT, Phil Race wrote: > This is a duplicate of https://bugs.openjdk.org/browse/JDK-8307210 I don't think so since it also fixes the build broken due to `-Werror=infinite-recursion`. Actually, `-Werror=infinite-recursion` was first introduced in GCC12. So the build will also fail with GCC12. > Please check for existing reports before creating a new bug. We already plan to fix this before we officially upgrade to 13.1, until then you just disable the warning. I think it's fine to just disable the warning before you have cycles to fix it since it's a third-party code. Now part of our testing machines had been upgrade to GCC13 so it would be good to fix it as soon as possible. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1552195846 From jiefu at openjdk.org Wed May 17 23:24:48 2023 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 17 May 2023 23:24:48 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:26:22 GMT, xpbob wrote: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; @xpbob , maybe, it would be better to change the JBS title with something like `Build failure with GCC12 & GCC13`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1552206443 From duke at openjdk.org Thu May 18 01:55:46 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 01:55:46 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:26:22 GMT, xpbob wrote: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; The patch here involves two different parts. I tried to change the JBS title ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1552298341 From duke at openjdk.org Thu May 18 02:09:00 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 02:09:00 GMT Subject: RFR: 8308283: Build failure with gcc 13.1.0 In-Reply-To: <2DGmslRRkkyYHGuhLnCslvb9-rC1ojbRkwzeEt_lT6E=.daa21a27-1410-4e84-af70-636b6bf35089@github.com> References: <2DGmslRRkkyYHGuhLnCslvb9-rC1ojbRkwzeEt_lT6E=.daa21a27-1410-4e84-af70-636b6bf35089@github.com> Message-ID: On Wed, 17 May 2023 18:49:44 GMT, Phil Race wrote: >> configure --enable-debug >> >> error: infinite recursion detected [-Werror=infinite-recursion] >> ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) >> >> configure >> >> java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] >> ?1161 | const LangSys& l = this+_.second.offset; > > This is a duplicate of https://bugs.openjdk.org/browse/JDK-8307210 > Please check for existing reports before creating a new bug. > We already plan to fix this before we officially upgrade to 13.1, until then you just disable the warning. @prrace hi I found the error: infinite recursion detected [-Werror=infinite-recursion] message and check the information in existing reports,There are no similar bugs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1552307691 From duke at openjdk.org Thu May 18 02:18:48 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 02:18:48 GMT Subject: RFR: 8308283: Build failure with GCC12 & GCC13 In-Reply-To: References: Message-ID: On Wed, 17 May 2023 23:21:59 GMT, Jie Fu wrote: >> configure --enable-debug >> >> error: infinite recursion detected [-Werror=infinite-recursion] >> ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) >> >> configure >> >> java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] >> ?1161 | const LangSys& l = this+_.second.offset; > > @xpbob , maybe, it would be better to change the JBS title with something like `Build failure with GCC12 & GCC13`? @DamonFool @prrace I have changed the JBS title ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1552313421 From jiefu at openjdk.org Thu May 18 02:38:51 2023 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 18 May 2023 02:38:51 GMT Subject: RFR: 8308283: Build failure with GCC12 & GCC13 In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:26:22 GMT, xpbob wrote: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 49: > 47: // Disable -Winfinite-recursion which is introduced in GCC 12. > 48: #if !defined(__clang_major__) && (__GNUC__ >= 12) > 49: #define PRAGMA_INFINITE_RECURSION_IGNORED PRAGMA_DISABLE_GCC_WARNING("-Winfinite-recursion") How about moving this line after Line 44? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14032#discussion_r1197283986 From duke at openjdk.org Thu May 18 03:11:23 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 03:11:23 GMT Subject: RFR: 8308283: Build failure with GCC12 & GCC13 [v2] In-Reply-To: References: Message-ID: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; xpbob has updated the pull request incrementally with one additional commit since the last revision: merge line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14032/files - new: https://git.openjdk.org/jdk/pull/14032/files/1c80f579..3da47371 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14032&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14032&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14032/head:pull/14032 PR: https://git.openjdk.org/jdk/pull/14032 From duke at openjdk.org Thu May 18 03:15:53 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 03:15:53 GMT Subject: RFR: 8308283: Build failure with GCC12 & GCC13 [v3] In-Reply-To: References: Message-ID: <8wy1eahoLl-9S83Eddo3jw3o3cKSE8HyqquqRfqsiw4=.ff75b795-38d3-4f00-99a0-135fe7c49277@github.com> > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; xpbob has updated the pull request incrementally with one additional commit since the last revision: remove blank ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14032/files - new: https://git.openjdk.org/jdk/pull/14032/files/3da47371..34906c92 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14032&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14032&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14032.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14032/head:pull/14032 PR: https://git.openjdk.org/jdk/pull/14032 From jiefu at openjdk.org Thu May 18 03:21:49 2023 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 18 May 2023 03:21:49 GMT Subject: RFR: 8308283: Build failure with GCC12 & GCC13 [v3] In-Reply-To: <8wy1eahoLl-9S83Eddo3jw3o3cKSE8HyqquqRfqsiw4=.ff75b795-38d3-4f00-99a0-135fe7c49277@github.com> References: <8wy1eahoLl-9S83Eddo3jw3o3cKSE8HyqquqRfqsiw4=.ff75b795-38d3-4f00-99a0-135fe7c49277@github.com> Message-ID: On Thu, 18 May 2023 03:15:53 GMT, xpbob wrote: >> configure --enable-debug >> >> error: infinite recursion detected [-Werror=infinite-recursion] >> ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) >> >> configure >> >> java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] >> ?1161 | const LangSys& l = this+_.second.offset; > > xpbob has updated the pull request incrementally with one additional commit since the last revision: > > remove blank LGTM Thanks for the update. ------------- Marked as reviewed by jiefu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14032#pullrequestreview-1431943484 From duke at openjdk.org Thu May 18 03:21:51 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 03:21:51 GMT Subject: RFR: 8308283: Build failure with GCC12 & GCC13 In-Reply-To: References: Message-ID: <8mQnUCyvdXhXrw0kwMFw7SPhwgSN5S5jZCcnYLmpBMc=.b8a6b84d-d65c-4b82-9e0c-fb54bb03f217@github.com> On Wed, 17 May 2023 23:21:59 GMT, Jie Fu wrote: >> configure --enable-debug >> >> error: infinite recursion detected [-Werror=infinite-recursion] >> ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) >> >> configure >> >> java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] >> ?1161 | const LangSys& l = this+_.second.offset; > > @xpbob , maybe, it would be better to change the JBS title with something like `Build failure with GCC12 & GCC13`? @DamonFool Thanks for the review,The code has been updated ------------- PR Comment: https://git.openjdk.org/jdk/pull/14032#issuecomment-1552348251 From achung at openjdk.org Thu May 18 05:09:08 2023 From: achung at openjdk.org (Alisen Chung) Date: Thu, 18 May 2023 05:09:08 GMT Subject: RFR: JDK-8307083: Open source some drag and drop tests 3 [v4] In-Reply-To: References: Message-ID: > moving tests to open Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: fix robot timeout ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13764/files - new: https://git.openjdk.org/jdk/pull/13764/files/de4cfd7d..c259d2b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13764&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13764&range=02-03 Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13764.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13764/head:pull/13764 PR: https://git.openjdk.org/jdk/pull/13764 From tr at openjdk.org Thu May 18 05:27:53 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 18 May 2023 05:27:53 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: On Wed, 17 May 2023 16:25:59 GMT, Tejesh R wrote: >> I technically had 2 questions in the last comment. >> 1. Can't you just put the contents of `initialize()` in place of line 53? It's the only thing being run. >> 2. Why are we creating a `Runnable` instance instead of just calling `initialize` in main? >> >> And I have another completely separate comment. If you actually need this to be a `Runnable`, I think you can replace this with a lambda function. > > Point 1 can be done, nothing specific to adding everything into a function. Just that we are trying to maintain uniformity across other test. Point 2, it can be either with Runnable/direct lambda function, just that no return type is there we can use Runnable too I just choose it, nothing specific to functionlity. Updated by removing `Runnable`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1197385063 From duke at openjdk.org Thu May 18 12:29:57 2023 From: duke at openjdk.org (xpbob) Date: Thu, 18 May 2023 12:29:57 GMT Subject: Integrated: 8308283: Build failure with GCC12 & GCC13 In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:26:22 GMT, xpbob wrote: > configure --enable-debug > > error: infinite recursion detected [-Werror=infinite-recursion] > ??193 | void VMError::reattempt_test_hit_stack_limit(outputStream* st) > > configure > > java.desktop/share/native/libharfbuzz/graph/../hb-ot-layout-common.hh:1161:24: error: possibly dangling reference to a temporary [-Werror=dangling-reference] > ?1161 | const LangSys& l = this+_.second.offset; This pull request has now been integrated. Changeset: bfc3ccd9 Author: bobpengxie Committer: Jie Fu URL: https://git.openjdk.org/jdk/commit/bfc3ccd90d579f6cba3a704766b7a1ea56beebe1 Stats: 13 lines in 4 files changed: 11 ins; 1 del; 1 mod 8308283: Build failure with GCC12 & GCC13 Reviewed-by: erikj, jiefu ------------- PR: https://git.openjdk.org/jdk/pull/14032 From kbarrett at openjdk.org Thu May 18 15:23:00 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 18 May 2023 15:23:00 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> Message-ID: On Wed, 17 May 2023 09:44:47 GMT, Kim Barrett wrote: >> os_aix.cpp:460:37: error: missing field 'gid' initializer [-Werror,-Wmissing-field-initializers] >> struct shmid_ds shm_buf = { 0 }; >> >> ={} seems to work, but I do not know if it works on every compiler because standard says: the initializer must be a **non-empty, (until C23)** brace-enclosed, comma-separated list of initializers for the members. >> Should I then disable Warning missing-field-initializers? > > Use > > struct shmid_ds shm_buf{}; > > to _value-initialize_. Calls the default constructor if there is one. Otherwise, performs _zero-initialization_, > which is what we want here. The final suggested change (to value-initialize the object) seems to have *not* been made. However, I think it doesn't matter. The mentioned restriction against being non-empty until C23 is not relevant. This is C++, not C. Empty initializers are, and have always been, permitted by C++. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1197956866 From achung at openjdk.org Thu May 18 15:48:04 2023 From: achung at openjdk.org (Alisen Chung) Date: Thu, 18 May 2023 15:48:04 GMT Subject: Integrated: JDK-8307083: Open source some drag and drop tests 3 In-Reply-To: References: Message-ID: <0v4eg_d36gPWdRcQ5ZxDyhCsFQpLuNu1NbcPrHwe3n8=.03ceb77b-5085-4a66-bcc5-b43a4156b071@github.com> On Tue, 2 May 2023 21:53:59 GMT, Alisen Chung wrote: > moving tests to open This pull request has now been integrated. Changeset: 1b154e4f Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/1b154e4fd361103936f976db72e04b73aa7b1077 Stats: 895 lines in 4 files changed: 895 ins; 0 del; 0 mod 8307083: Open source some drag and drop tests 3 Reviewed-by: prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/13764 From serb at openjdk.org Thu May 18 17:03:51 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 18 May 2023 17:03:51 GMT Subject: RFR: 8221452: Window.setMinimumSize does not respect DPI scaling In-Reply-To: <7fZ5gO65xyT8dqEjqv_B9rUXZWJDwLHMC-IjCOJ856M=.712cde39-b694-4542-9a06-3fdf5566e609@github.com> References: <7fZ5gO65xyT8dqEjqv_B9rUXZWJDwLHMC-IjCOJ856M=.712cde39-b694-4542-9a06-3fdf5566e609@github.com> Message-ID: <4SO4lGd0JtIuUiGBLatBygXcAfifUiDq0Ct7OCG3HEk=.9f1603ad-2cc8-4f2b-8b5d-b796c9c935fc@github.com> On Mon, 8 May 2023 00:49:58 GMT, babblebubble wrote: > Hi, I'm not sure if I did the formatting of this pull request right, new to this, but the bug was bothering me so I fixed it (took three attempts). > All I had to do was add ScaleUpX and ScaleUpY and it fixed it. > Sorry for being new to GitHub, I only made an account to fix this. How hard is to create the new jtreg test for this patch? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13857#issuecomment-1553348669 From azvegint at openjdk.org Thu May 18 17:17:42 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 18 May 2023 17:17:42 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v3] In-Reply-To: References: Message-ID: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: refactoring to remove resetScreenCapturePermission ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/482471df..3f01bb26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=01-02 Stats: 619 lines in 10 files changed: 504 ins; 48 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From azvegint at openjdk.org Thu May 18 17:17:44 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 18 May 2023 17:17:44 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots In-Reply-To: References: Message-ID: On Fri, 5 May 2023 14:58:15 GMT, Alexander Zvegintsev wrote: > Do we really need to add this new API? probably we can implement the feature w/o this new method? Please review the changes to remove resetScreenCapturePermission The token is now stored together with the bounds of the screens for which the screen capture was allowed. Now when we want to take a screenshot, we create a list of the bounds of the system screens that have the data we're interested in. Based on this list, we pick up the tokens from the previously saved ones: a. exact match of the bounds of the screens b. the same size(screens can be moved, while the old token for them works) We try to get an image with these tokens, checking that the previously associated bounds have not changed and we get the image from the capture area available to us. If, for some reason, the old token is withdrawn, a new permission will be requested to capture screens. If none of the tokens worked, we try to get a new permission. If none of above worked, we throw a SecurityException. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1553360491 From prr at openjdk.org Thu May 18 17:21:55 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 18 May 2023 17:21:55 GMT Subject: RFR: 8307779: Relax the java.awt.Robot specification [v5] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 19:54:06 GMT, Alexander Zvegintsev wrote: >> We need to relax the java.awt.Robot specification according to the latest operating system trends. >> This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. >> >> https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots >> https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor >> https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. >> https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > update createMultiResolutionScreenCapture documentation Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13809#pullrequestreview-1433116244 From azvegint at openjdk.org Thu May 18 18:17:03 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 18 May 2023 18:17:03 GMT Subject: Integrated: 8307779: Relax the java.awt.Robot specification In-Reply-To: References: Message-ID: <1Ah7cR4KhgPGvBy5PWMvVy-Ebh6ByLr9vHSbqGUmaAU=.9412c753-eaab-40e0-a8aa-1279341af542@github.com> On Thu, 4 May 2023 16:26:47 GMT, Alexander Zvegintsev wrote: > We need to relax the java.awt.Robot specification according to the latest operating system trends. > This should at least cover the case of Wayland, which has changed many familiar concepts in Linux. > > https://bugs.openjdk.org/browse/JDK-8280982 [Wayland] [XWayland] java.awt.Robot taking screenshots > https://bugs.openjdk.org/browse/JDK-8280995 [XWayland] Robot.mouseMove does not visually move mouse cursor > https://bugs.openjdk.org/browse/JDK-8280990 [XWayland] XTest emulated mouse click does not bring window to front. > https://bugs.openjdk.org/browse/JDK-8280988 [XWayland] Click on title to request focus test failures This pull request has now been integrated. Changeset: 21aa057f Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/21aa057fafd88f4dd677bbf7c99a7eabb6b18409 Stats: 80 lines in 1 file changed: 72 ins; 1 del; 7 mod 8307779: Relax the java.awt.Robot specification Reviewed-by: mkartashev, prr ------------- PR: https://git.openjdk.org/jdk/pull/13809 From azvegint at openjdk.org Thu May 18 18:56:11 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 18 May 2023 18:56:11 GMT Subject: Integrated: 8308370: Fix build failures related to the java.awt.Robot documentation Message-ID: Fix a typo ------------- Commit messages: - initial Changes: https://git.openjdk.org/jdk/pull/14050/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14050&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308370 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14050.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14050/head:pull/14050 PR: https://git.openjdk.org/jdk/pull/14050 From dcubed at openjdk.org Thu May 18 18:56:11 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 18 May 2023 18:56:11 GMT Subject: Integrated: 8308370: Fix build failures related to the java.awt.Robot documentation In-Reply-To: References: Message-ID: On Thu, 18 May 2023 18:42:41 GMT, Alexander Zvegintsev wrote: > Fix a typo Thumbs up. This is a trivial fix for a typo. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14050#pullrequestreview-1433268138 From azvegint at openjdk.org Thu May 18 18:56:11 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 18 May 2023 18:56:11 GMT Subject: Integrated: 8308370: Fix build failures related to the java.awt.Robot documentation In-Reply-To: References: Message-ID: On Thu, 18 May 2023 18:42:41 GMT, Alexander Zvegintsev wrote: > Fix a typo This pull request has now been integrated. Changeset: 02dc95e6 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/02dc95e6b99e5998b028e90c3fe9c64ad9f47d9e Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8308370: Fix build failures related to the java.awt.Robot documentation Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk/pull/14050 From rriggs at openjdk.org Thu May 18 19:54:57 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 May 2023 19:54:57 GMT Subject: Integrated: 8308370: Fix build failures related to the java.awt.Robot documentation In-Reply-To: References: Message-ID: On Thu, 18 May 2023 18:42:41 GMT, Alexander Zvegintsev wrote: > Fix a typo The extraneous

    should have been removed not just closed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14050#issuecomment-1553568050 From prr at openjdk.org Thu May 18 22:34:55 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 18 May 2023 22:34:55 GMT Subject: RFR: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland [v2] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 18:01:31 GMT, Alexander Zvegintsev wrote: >> On Linux systems, we rely on XGrabPointer (X11 API) to capture mouse input and dismiss popup menus on mouse clicks outside the popup menu. >> Unfortunately, on Linux systems using the [Wayland](https://wayland.freedesktop.org/) session this only works inside [XWayland(Wayland's X11 server implementation)](https://wayland.freedesktop.org/xserver.html). >> This means if a user clicks on a part of the screen not controlled by XWayland (e.g. window decorations, other non X11 applications) the popup menu will not be hidden. >> >> As a workaround, we can hide this menu when the parent popup menu window loses focus. >> However, it does have its drawbacks, which should be described in the documentation.The focus does not change when clicking on the header of its own parent window or on non-focusable windows, .e.g., empty space in system dock, so in this case the popup menu is not hidden. >> >> Third-party applications use a similar approach. >> >> I also have doubts about the need to change the documentation, as I can't find where it is described that the popup menu should be hidden when clicked outside the menu. >> >> CSR: https://bugs.openjdk.org/browse/JDK-8307529 > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > undo documentation changes src/java.desktop/share/classes/java/awt/PopupMenu.java line 49: > 47: * by clicking on the decorations of its own parent window > 48: * and on some system panels. > 49: * I think I agree with others that its questionable if we need to say this at all. It would be odd to specify the places you can click to dismiss a popup, so unless we already do that, we don't need to start now. src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 767: > 765: } > 766: > 767: // We rely on the X11 input grab mechanism, but for the Wayland session Whilst we need to do this, having all this code discussing Wayland here in JPopupMenu is really the wrong place. This needs to be re-done in a way that is about the specific problem which is something like SunToolkit.clickOutsideWillDismissPopup() and the word "Wayland" shouldn't appear anywhere here. IIUC this fix is needed so that a number of tests that fail now because of this problem will be able to pass, so it would be good to get it in soon so I can get a clearer picture of what remaining test issues we have. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13830#discussion_r1187870382 PR Review Comment: https://git.openjdk.org/jdk/pull/13830#discussion_r1198364501 From serb at openjdk.org Thu May 18 23:02:51 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 18 May 2023 23:02:51 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v2] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com> <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com> Message-ID: On Tue, 16 May 2023 19:26:57 GMT, Alexey Ivanov wrote: >> Actually I literally didn't mean 1 physical pixel, it was more figurative to say that when the width calculation on Java side is reduced by 1 we see a big difference in final scaling. > > Perhaps, this needs additional details. The size of checkbox and radio button is 13 as reported by Theme API for the standard DPI of 96. Being a prime number, 13 doesn't scale well, there's always fractional part unless the scale is whole. Thus, the scaled size never matches. > > As the result, `CachedPainter` seems to apply a scale to compensate for that ? whether we choose ceil or floor. The above formula gives better results. > > The entire thing should have been simpler: a `MultiResolutionImage` which paints the background according to the scale requested. Yet it proved to be not as simple. We're planning to look further into simplifying it if possible and, alternatively or in addition to, considering [dynamic layout based on graphics configuration](https://github.com/openjdk/jdk/pull/13701#discussion_r1187985627) as you suggested above. > > The current solution may be not perfect but it provides better rendering compared to what we have now: *the controls look crisp only on the main display*. But still why the size on the components are so different? is it really caused by one "pixel/unit" we requested from the native? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1198378292 From azvegint at openjdk.org Fri May 19 11:23:50 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 19 May 2023 11:23:50 GMT Subject: RFR: 8307311: Timeouts on one macOS 12.6.1 host of two Swing JTableHeader tests In-Reply-To: References: Message-ID: <2xWe3W_n7yyQjr3o3tfoPOs7OFuDOQf6RHKgqEF4aVw=.d95b1711-ff38-4483-8d0f-abb086bbaf17@github.com> On Wed, 17 May 2023 07:06:01 GMT, Prasanta Sadhukhan wrote: > Issue was bug6889007.java was causing a timeout issue on mac system. Although bug6889007.java fail with small test group with "Wrong cursor type" error, it could not reproduce bug6884066.java > The hang issue might be due to waitForIdle() being called in loop which will be calling sync() so replaced with delay.. > > Modified fix passed the suggested small test group `desktop_timeout ` several times in all platforms > in addition to several iterations of the test run in standalone mode in all platforms.. test/jdk/javax/swing/JTableHeader/6889007/bug6889007.java line 72: > 70: frame.pack(); > 71: frame.setLocationRelativeTo(null); > 72: frame.setAlwaysOnTop(true); Why do we need to keep the window on top? test/jdk/javax/swing/JTableHeader/6889007/bug6889007.java line 87: > 85: for(int i = -shift; i < width + 2*shift; i++) { > 86: robot.mouseMove(x++, y); > 87: robot.delay(100); It looks like we don't need this delay since there is `robot.setAutoDelay(100);` on line 56. A total delay of 200ms seems too much to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14026#discussion_r1198849137 PR Review Comment: https://git.openjdk.org/jdk/pull/14026#discussion_r1198847995 From psadhukhan at openjdk.org Fri May 19 11:26:51 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 19 May 2023 11:26:51 GMT Subject: RFR: 8296920: Regression Test DialogOrient.java fails on MacOS In-Reply-To: References: Message-ID: On Wed, 17 May 2023 21:48:01 GMT, Alisen Chung wrote: >> Test was failing with PrinterException: Wrong Orientation since printing was done with default orientation. >> Fix is made to set the printable with correct PageFormat >> >> It was not seen prior to [JDK-8262731](https://bugs.openjdk.org/browse/JDK-8262731) probably because the exception was being swallowed.. > > test/jdk/java/awt/print/Dialog/DialogOrient.java line 73: > >> 71: PrinterJob job = PrinterJob.getPrinterJob(); >> 72: PageFormat landscape = job.pageDialog(job.defaultPage()); >> 73: job.setPrintable(new DialogOrient(), landscape); > > why doesn't job.setPrintable(DialogOrient) work here? doesn't job.pageDialog already set the job orientation to landscape? https://docs.oracle.com/en/java/javase/20/docs/api/java.desktop/java/awt/print/PrinterJob.html#setPrintable(java.awt.print.Printable) says "The [PageFormat](file:///D:/jdk-17.0.1_doc-all/docs/api/java.desktop/java/awt/print/PageFormat.html) for each page is the default page format." which is Portrait so it seems prudent to pass the pageformat modified in pageDialog to setPrintable ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13950#discussion_r1198853598 From psadhukhan at openjdk.org Fri May 19 11:29:51 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 19 May 2023 11:29:51 GMT Subject: RFR: 8307311: Timeouts on one macOS 12.6.1 host of two Swing JTableHeader tests In-Reply-To: <2xWe3W_n7yyQjr3o3tfoPOs7OFuDOQf6RHKgqEF4aVw=.d95b1711-ff38-4483-8d0f-abb086bbaf17@github.com> References: <2xWe3W_n7yyQjr3o3tfoPOs7OFuDOQf6RHKgqEF4aVw=.d95b1711-ff38-4483-8d0f-abb086bbaf17@github.com> Message-ID: On Fri, 19 May 2023 11:18:16 GMT, Alexander Zvegintsev wrote: >> Issue was bug6889007.java was causing a timeout issue on mac system. Although bug6889007.java fail with small test group with "Wrong cursor type" error, it could not reproduce bug6884066.java >> The hang issue might be due to waitForIdle() being called in loop which will be calling sync() so replaced with delay.. >> >> Modified fix passed the suggested small test group `desktop_timeout ` several times in all platforms >> in addition to several iterations of the test run in standalone mode in all platforms.. > > test/jdk/javax/swing/JTableHeader/6889007/bug6889007.java line 72: > >> 70: frame.pack(); >> 71: frame.setLocationRelativeTo(null); >> 72: frame.setAlwaysOnTop(true); > > Why do we need to keep the window on top? In windows primarily, I see sometimes the frame is rendered below some if there are other windows present ie remains hidden and mouse cursor is moved which looks odd, so I ensured the frame is always on top for the test > test/jdk/javax/swing/JTableHeader/6889007/bug6889007.java line 87: > >> 85: for(int i = -shift; i < width + 2*shift; i++) { >> 86: robot.mouseMove(x++, y); >> 87: robot.delay(100); > > It looks like we don't need this delay since there is `robot.setAutoDelay(100);` on line 56. A total delay of 200ms seems too much to me. I dont think it's too much as compared to 500ms we have in some tests..Since I have tested in all platforms with this values without any problems observed, I will like to keep this value for now.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14026#discussion_r1198855883 PR Review Comment: https://git.openjdk.org/jdk/pull/14026#discussion_r1198855919 From azvegint at openjdk.org Fri May 19 11:46:50 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 19 May 2023 11:46:50 GMT Subject: RFR: 8307311: Timeouts on one macOS 12.6.1 host of two Swing JTableHeader tests In-Reply-To: References: <2xWe3W_n7yyQjr3o3tfoPOs7OFuDOQf6RHKgqEF4aVw=.d95b1711-ff38-4483-8d0f-abb086bbaf17@github.com> Message-ID: On Fri, 19 May 2023 11:27:16 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/JTableHeader/6889007/bug6889007.java line 87: >> >>> 85: for(int i = -shift; i < width + 2*shift; i++) { >>> 86: robot.mouseMove(x++, y); >>> 87: robot.delay(100); >> >> It looks like we don't need this delay since there is `robot.setAutoDelay(100);` on line 56. A total delay of 200ms seems too much to me. > > I dont think it's too much as compared to 500ms we have in some tests..Since I have tested in all platforms with this values without any problems observed, I will like to keep this value for now.. This seems OK to me for a rarely repeated operation. Here it is repeated 405 times(at least for my testing), which leads to an additional ~40.5 s of the test execution time. 100ms is still a pretty solid delay for mouse movement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14026#discussion_r1198868406 From psadhukhan at openjdk.org Fri May 19 11:51:50 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 19 May 2023 11:51:50 GMT Subject: RFR: 8307311: Timeouts on one macOS 12.6.1 host of two Swing JTableHeader tests In-Reply-To: References: <2xWe3W_n7yyQjr3o3tfoPOs7OFuDOQf6RHKgqEF4aVw=.d95b1711-ff38-4483-8d0f-abb086bbaf17@github.com> Message-ID: On Fri, 19 May 2023 11:44:03 GMT, Alexander Zvegintsev wrote: >> I dont think it's too much as compared to 500ms we have in some tests..Since I have tested in all platforms with this values without any problems observed, I will like to keep this value for now.. > > This seems OK to me for a rarely repeated operation. > Here it is repeated 405 times(at least for my testing), which leads to an additional ~40.5 s of the test execution time. > 100ms is still a pretty solid delay for mouse movement. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14026#discussion_r1198872014 From azvegint at openjdk.org Fri May 19 15:58:07 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 19 May 2023 15:58:07 GMT Subject: RFR: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland [v3] In-Reply-To: References: Message-ID: > On Linux systems, we rely on XGrabPointer (X11 API) to capture mouse input and dismiss popup menus on mouse clicks outside the popup menu. > Unfortunately, on Linux systems using the [Wayland](https://wayland.freedesktop.org/) session this only works inside [XWayland(Wayland's X11 server implementation)](https://wayland.freedesktop.org/xserver.html). > This means if a user clicks on a part of the screen not controlled by XWayland (e.g. window decorations, other non X11 applications) the popup menu will not be hidden. > > As a workaround, we can hide this menu when the parent popup menu window loses focus. > However, it does have its drawbacks, which should be described in the documentation.The focus does not change when clicking on the header of its own parent window or on non-focusable windows, .e.g., empty space in system dock, so in this case the popup menu is not hidden. > > Third-party applications use a similar approach. > > I also have doubts about the need to change the documentation, as I can't find where it is described that the popup menu should be hidden when clicked outside the menu. > > CSR: https://bugs.openjdk.org/browse/JDK-8307529 Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: move to toolkit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13830/files - new: https://git.openjdk.org/jdk/pull/13830/files/becb92d3..58057d28 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13830&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13830&range=01-02 Stats: 231 lines in 6 files changed: 105 ins; 99 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/13830.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13830/head:pull/13830 PR: https://git.openjdk.org/jdk/pull/13830 From azvegint at openjdk.org Fri May 19 16:03:51 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 19 May 2023 16:03:51 GMT Subject: RFR: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland [v2] In-Reply-To: References: Message-ID: <0GB-yDa7rClFnUuI1cU-XdTn5qtgr51mjEYv8068oek=.335b3e48-86ce-4880-a7c9-b6e6c3d8e28b@github.com> On Thu, 18 May 2023 22:32:13 GMT, Phil Race wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> undo documentation changes > > src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 767: > >> 765: } >> 766: >> 767: // We rely on the X11 input grab mechanism, but for the Wayland session > > Whilst we need to do this, having all this code discussing Wayland here in JPopupMenu is really the wrong place. > This needs to be re-done in a way that is about the specific problem which is something like > SunToolkit.clickOutsideWillDismissPopup() > and the word "Wayland" shouldn't appear anywhere here. > > IIUC this fix is needed so that a number of tests that fail now because of this problem will be able to pass, so it would be good to get it in soon so I can get a clearer picture of what remaining test issues we have. Sure, moved to toolkit. > IIUC this fix is needed so that a number of tests that fail now because of this problem will be able to pass, so it would be good to get it in soon so I can get a clearer picture of what remaining test issues we have. This only affects manual tests, as automatic tests use the XTest API, which works correctly with X11 Input Grab. Besides, this is a real use case that can be annoying. This change doesn't fix the problem completely (we still can't hide the menu by clicking on the title bar of our own window or on non-focusable windows such as the desktop), but it definitely makes the user experience better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13830#discussion_r1199126453 From azvegint at openjdk.org Fri May 19 16:07:51 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 19 May 2023 16:07:51 GMT Subject: RFR: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland [v3] In-Reply-To: References: Message-ID: On Fri, 19 May 2023 15:58:07 GMT, Alexander Zvegintsev wrote: >> On Linux systems, we rely on XGrabPointer (X11 API) to capture mouse input and dismiss popup menus on mouse clicks outside the popup menu. >> Unfortunately, on Linux systems using the [Wayland](https://wayland.freedesktop.org/) session this only works inside [XWayland(Wayland's X11 server implementation)](https://wayland.freedesktop.org/xserver.html). >> This means if a user clicks on a part of the screen not controlled by XWayland (e.g. window decorations, other non X11 applications) the popup menu will not be hidden. >> >> As a workaround, we can hide this menu when the parent popup menu window loses focus. >> However, it does have its drawbacks, which should be described in the documentation.The focus does not change when clicking on the header of its own parent window or on non-focusable windows, .e.g., empty space in system dock, so in this case the popup menu is not hidden. >> >> Third-party applications use a similar approach. >> >> I also have doubts about the need to change the documentation, as I can't find where it is described that the popup menu should be hidden when clicked outside the menu. >> >> CSR: https://bugs.openjdk.org/browse/JDK-8307529 > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > move to toolkit src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 763: > 761: > 762: private Window getMenuInvoker() { > 763: if (invoker instanceof Window menuInvoker) { [Pattern matching for instanceof](https://openjdk.org/jeps/394) is used. Maybe we shouldn't use this if we plan to backport this change to the JDK < 16 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13830#discussion_r1199131560 From aivanov at openjdk.org Fri May 19 16:46:59 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 19 May 2023 16:46:59 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v7] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 06:44:20 GMT, Prasanta Sadhukhan wrote: >> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. >> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. >> Fixed by implementing the equality and hashCode method for CSS.FontSize class. >> >> All jtreg/jck tests are ok > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > hashCode fix Can all the subclasses of `CssValue` be compared with correct result? src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2223: > 2221: @Override > 2222: public boolean equals(Object val) { > 2223: return val instanceof CSS.FontSize size && value == size.value; What about different units? `font-size: 1em` shouldn't be equal to `font-size: 1ex`, should it? What about keywords? Currently, declarations `font-size: smaller` and `font-size: larger` are considered equal. src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2334: > 2332: public boolean equals(Object val) { > 2333: return val instanceof CSS.FontFamily font > 2334: && Objects.equals(family, font.family); Could you be consistent? The indentation at [lines 2035-2036](https://github.com/openjdk/jdk/pull/13405/files/2bc265cdb1ed0d070b21233ff9982758bef6da71..717d1a1d4e8a3eb0cea848a7e8800210f30660fd#diff-e2c9b23b1844fa877fb1c4f048a8a8b85cd21d146f963837e039ab20b9560fe7R2036) above is different. Personally, I would align `&&` with `v` of `val`; aligning to start of `instanceof` look good too, I prefer it compared to 8-column indent you used above. src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2680: > 2678: if (percentage) { > 2679: return false; > 2680: } else { Why are percentage values never equal? I expect two attribute sets produced from `"margin-top: 100%"` to be equal. However, the real length on rendering could be different if the attribute is applied to different elements. src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2681: > 2679: return false; > 2680: } else { > 2681: return val instanceof CSS.LengthValue lu && span == lu.span; What about different units? "1mm" should not be equal to "1cm", should it? ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13405#pullrequestreview-1434591382 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1199147541 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1199063559 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1199144022 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1199144367 From prr at openjdk.org Fri May 19 17:25:51 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 19 May 2023 17:25:51 GMT Subject: RFR: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland [v3] In-Reply-To: References: Message-ID: On Fri, 19 May 2023 15:58:07 GMT, Alexander Zvegintsev wrote: >> On Linux systems, we rely on XGrabPointer (X11 API) to capture mouse input and dismiss popup menus on mouse clicks outside the popup menu. >> Unfortunately, on Linux systems using the [Wayland](https://wayland.freedesktop.org/) session this only works inside [XWayland(Wayland's X11 server implementation)](https://wayland.freedesktop.org/xserver.html). >> This means if a user clicks on a part of the screen not controlled by XWayland (e.g. window decorations, other non X11 applications) the popup menu will not be hidden. >> >> As a workaround, we can hide this menu when the parent popup menu window loses focus. >> However, it does have its drawbacks, which should be described in the documentation.The focus does not change when clicking on the header of its own parent window or on non-focusable windows, .e.g., empty space in system dock, so in this case the popup menu is not hidden. >> >> Third-party applications use a similar approach. >> >> I also have doubts about the need to change the documentation, as I can't find where it is described that the popup menu should be hidden when clicked outside the menu. >> >> CSR: https://bugs.openjdk.org/browse/JDK-8307529 > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > move to toolkit Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13830#pullrequestreview-1434815761 From prr at openjdk.org Fri May 19 17:25:54 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 19 May 2023 17:25:54 GMT Subject: RFR: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland [v3] In-Reply-To: References: Message-ID: On Fri, 19 May 2023 16:04:50 GMT, Alexander Zvegintsev wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> move to toolkit > > src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 763: > >> 761: >> 762: private Window getMenuInvoker() { >> 763: if (invoker instanceof Window menuInvoker) { > > [Pattern matching for instanceof](https://openjdk.org/jeps/394) is used. > Maybe we shouldn't use this if we plan to backport this change to the JDK < 16 I wouldn't worry about that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13830#discussion_r1199191097 From aivanov at openjdk.org Fri May 19 18:05:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 19 May 2023 18:05:56 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v7] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 06:44:20 GMT, Prasanta Sadhukhan wrote: >> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. >> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. >> Fixed by implementing the equality and hashCode method for CSS.FontSize class. >> >> All jtreg/jck tests are ok > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > hashCode fix May I suggest a simplified version of [the CSSAttributeEqualityBug.java test](https://github.com/aivanov-jdk/jdk/blob/4997c4dcc258a451e4177d267301abaadae122af/test/jdk/javax/swing/text/html/CSS/CSSAttributeEqualityBug.java) which contains a list of CSS declarations which produce equal attribute sets and another list of declarations which produce non-equal attribute sets. The updated test covers all the existing cases as well as a few more cases for which I raised my concerns above. To add a new test case, just add a new entry into either `EQUALS` or `NOT_EQUALS` array. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13405#issuecomment-1555041654 From aivanov at openjdk.org Fri May 19 18:14:53 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 19 May 2023 18:14:53 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v7] In-Reply-To: References: Message-ID: <6-CpsQDvVY1TgWwJfIj_sEDfZOeYPp-HWdtO1R0iSgw=.2a1fabad-aedb-48f3-a9a0-e9e89966b394@github.com> On Fri, 19 May 2023 18:02:33 GMT, Alexey Ivanov wrote: > The updated test covers all the existing cases as well as a few more cases for which I raised my concerns above. To be more specific, it produces the following output: margin-top=100% is not equal to margin-top=100% font-size=42px is equal to font-size=22px font-size=42px is equal to font-size=42pt font-size=42em is equal to font-size=42ex font-size=100% is equal to font-size=200% margin-top=42px is equal to margin-top=42pt java.lang.RuntimeException: 6 failure(s) detected: margin-top=100% is not equal to margin-top=100% at CSSAttributeEqualityBug.main(CSSAttributeEqualityBug.java:105) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccess or.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125) at java.base/java.lang.Thread.run(Thread.java:1630) The new test does not provide direct references to `CSS.CssValue` subclasses, yet it's somewhat easy to infer. Comments in the arrays could refer to the class, for example `margin-top` uses `CSS.LengthValue`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13405#issuecomment-1555052119 From dnguyen at openjdk.org Fri May 19 18:19:49 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 19 May 2023 18:19:49 GMT Subject: RFR: 8307311: Timeouts on one macOS 12.6.1 host of two Swing JTableHeader tests In-Reply-To: References: Message-ID: On Wed, 17 May 2023 07:06:01 GMT, Prasanta Sadhukhan wrote: > Issue was bug6889007.java was causing a timeout issue on mac system. Although bug6889007.java fail with small test group with "Wrong cursor type" error, it could not reproduce bug6884066.java > The hang issue might be due to waitForIdle() being called in loop which will be calling sync() so replaced with delay.. > > Modified fix passed the suggested small test group `desktop_timeout ` several times in all platforms > in addition to several iterations of the test run in standalone mode in all platforms.. Changes seem fair to me. Tested on my local 13.3.1 Mac device. I'm slightly weary of the set delay since some machines may need longer, but since the action is repeated so often, it makes sense to keep it short. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/14026#pullrequestreview-1434889699 From aivanov at openjdk.org Fri May 19 20:14:14 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 19 May 2023 20:14:14 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v9] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 14:17:31 GMT, Tejesh R wrote: >> Open source few AWT ScrollPane related tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Changes requested by aivanov (Reviewer). test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 82: > 80: try { > 81: EventQueue.invokeAndWait(() -> { > 82: scrollpane.getVAdjustable().setValue(20); I suggest moving the remaining line to `init()` too. The code will be cleaner then. test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 47: > 45: import java.awt.event.MouseAdapter; > 46: > 47: import java.util.Properties; The `Properties` import is unused. test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 54: > 52: static final int SCROLL_POS = 50000; > 53: public static Component child = null; > 54: static CountDownLatch go = new CountDownLatch(1); Suggestion: static final CountDownLatch go = new CountDownLatch(1); test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 90: > 88: pane.doLayout(); > 89: }); > 90: robot = new Robot(); It makes no difference, yet `robot` isn't used in `init()`, so I propose moving it to `start()`. test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 96: > 94: try { > 95: robot.delay(1000); > 96: robot.waitForIdle(); Suggestion: robot.waitForIdle(); robot.delay(1000); Usually, these lines come in reverse order. test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 128: > 126: Dimension d = pane.getSize(); > 127: point.x += d.width / 2; > 128: point.y += d.height / 2; Suggestion: p = pane.getLocationOnScreen(); Dimension d = pane.getSize(); point = new Point(p.x += d.width / 2, p.y += d.height / 2); This is safer, only one write to volatile `point`. test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 133: > 131: robot.mousePress(InputEvent.BUTTON1_DOWN_MASK); > 132: robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK); > 133: robot.waitForIdle(); This `waitForIdle` is redundant because you're waiting for the count-down on the next line. test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 94: > 92: robot.waitForIdle(); > 93: robot.mouseMove(buttonLoc.x + buttonSize.width / 2, > 94: buttonLoc.y + buttonSize.height / 2); Suggestion: robot.waitForIdle(); robot.delay(1000); robot.mouseMove(buttonLoc.x + buttonSize.width / 2, buttonLoc.y + buttonSize.height / 2); I propose reversing `delay` and `waitForIdle` to the usual order. (Robot could be create here rather than in `init`. I propose adding a blank line to visually separate waiting from the posting events to the UI. test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 100: > 98: robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK); > 99: > 100: robot.delay(50); This additional `delay` is redundant, you're waiting on the next line anyway. test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 114: > 112: } > 113: > 114: private static class Semaphore { The `Semaphore` class is unused now, remove it. test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 87: > 85: > 86: vScroll.addAdjustmentListener(this); > 87: hScroll.addAdjustmentListener(this); [In my previous comment](https://github.com/openjdk/jdk/pull/13621#discussion_r1179076672), I also meant listeners should also be added inside `invokeAndWait`. test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 135: > 133: > 134: notifyReceived = false; > 135: synchronized (LOCK) { Suggestion: synchronized (LOCK) { notifyReceived = false; The `notifyReceived` must always be read and written inside a synchronised block. Other places should also be corrected. test/jdk/java/awt/ScrollPane/ScrollPositionIntact.java line 72: > 70: }); > 71: } > 72: } It does not even compile. Add a blank line before `init` and remove `try`-block to make it compilable. ------------- PR Review: https://git.openjdk.org/jdk/pull/13621#pullrequestreview-1434978305 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1199297623 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1199304933 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1199307181 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1199301306 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1199301712 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1199306087 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1199306770 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1199312034 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1199312394 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1199312739 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1199320045 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1199325017 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1199330843 From jiangli at openjdk.org Fri May 19 20:25:52 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 19 May 2023 20:25:52 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries Message-ID: Original description for JDK-8307194 change: ----- This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target - For libjvm.a specifically, exclude operator_new.o - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a - Handle long arguments case for static build in make/common/NativeCompilation.gmk - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS ----- Updates to address build failures reported on macosx- platforms: - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. ------------- Commit messages: - Merge branch 'master' into JDK-8307858 - Clean up. - In clude $MACHINE_FLAG in partial linking flag. - Use '-m32' instead of '-m elf_i386'. - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform. - Only do partial linking step with gcc/clang on 64-bit platform. - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG. - Merge branch 'master' into JDK-8307858 - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change. - When building a static library, partially link the input object files first. Then create the static library using the output object file produced by partial linking. - ... and 1 more: https://git.openjdk.org/jdk/compare/265f40b4...8af1ec2f Changes: https://git.openjdk.org/jdk/pull/14064/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307858 Stats: 201 lines in 10 files changed: 150 ins; 34 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/14064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064 PR: https://git.openjdk.org/jdk/pull/14064 From erikj at openjdk.org Fri May 19 21:23:02 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 19 May 2023 21:23:02 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: Message-ID: On Fri, 19 May 2023 20:18:53 GMT, Jiangli Zhou wrote: > Original description for JDK-8307194 change: > ----- > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > ----- > > Updates to address build failures reported on macosx- platforms: > > - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. > > The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. > > The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. I ran this patch in our internal build and test system and got failures on macos and windows. I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in. [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1 make/common/NativeCompilation.gmk line 1208: > 1206: $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ > 1207: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ > 1208: $$($1_LD_OBJ_ARG)) This command line is missing `$$($1_SYSROOT_LDFLAGS)` which is causing it to fail in our builds with: ld: library not found for -lSystem ------------- PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1435143793 PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1199405809 From jiangli at openjdk.org Fri May 19 21:50:49 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 19 May 2023 21:50:49 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: Message-ID: On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson wrote: > I ran this patch in our internal build and test system and got failures on macos and windows. Thanks a lot, @erikj79! I was going to ask your help for testing the patch. > I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in. > > ``` > [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error > [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data > [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed > [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1 > ``` The warning error looks the same as https://bugs.openjdk.org/browse/JDK-8307858?focusedCommentId=14581027&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14581027. Sorry I didn't look closely earlier. I just took a look of https://github.com/openjdk/jdk/blob/939344b8433b32166f42ad73ae3d96e84b033478/src/hotspot/share/compiler/disassembler.cpp#L792: #ifdef STATIC_BUILD char* p = strrchr(buf, '/'); *p = '\0'; strcat(p, "/lib/"); lib_offset = jvm_offset = strlen(buf); #else The code is only enabled for the static build, which is why the issue doesn't show up in regular JDK build. `strlen` return value is `size_t`. I'll work on a fix. Could you please help fix the mac failure as you have already looked into it. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1555290450 From erikj at openjdk.org Fri May 19 22:47:52 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 19 May 2023 22:47:52 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: Message-ID: On Fri, 19 May 2023 21:13:24 GMT, Erik Joelsson wrote: >> Original description for JDK-8307194 change: >> ----- >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS >> ----- >> >> Updates to address build failures reported on macosx- platforms: >> >> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. >> >> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. >> >> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. > > make/common/NativeCompilation.gmk line 1208: > >> 1206: $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ >> 1207: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ >> 1208: $$($1_LD_OBJ_ARG)) > > This command line is missing `$$($1_SYSROOT_LDFLAGS)` which is causing it to fail in our builds with: > > ld: library not found for -lSystem This is the mac failure, sorry if that wasn't clear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1199482710 From erikj at openjdk.org Fri May 19 21:23:02 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 19 May 2023 21:23:02 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: Message-ID: On Fri, 19 May 2023 20:18:53 GMT, Jiangli Zhou wrote: > Original description for JDK-8307194 change: > ----- > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > ----- > > Updates to address build failures reported on macosx- platforms: > > - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. > > The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. > > The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. I ran this patch in our internal build and test system and got failures on macos and windows. I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in. [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1 make/common/NativeCompilation.gmk line 1208: > 1206: $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ > 1207: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ > 1208: $$($1_LD_OBJ_ARG)) This command line is missing `$$($1_SYSROOT_LDFLAGS)` which is causing it to fail in our builds with: ld: library not found for -lSystem ------------- PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1435143793 PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1199405809 From duke at openjdk.org Sun May 21 15:42:09 2023 From: duke at openjdk.org (kansasSamurai) Date: Sun, 21 May 2023 15:42:09 GMT Subject: RFR: 8282526: Default icon is not painted properly [v8] In-Reply-To: References: Message-ID: <9PJaZZ1OvNoxnesiTflOGOxd0SEAqq_Dpz7JdchnBw4=.9af36c04-e3cb-4bd2-8a61-35eb78f0d25f@github.com> On Fri, 15 Jul 2022 19:15:52 GMT, Alexander Zuev wrote: >> Detect the situation where we do need to perform interpolation during ImageIcon >> painting and set a hint to the rendering to perform bicubic approximation so >> image details are preserved during transition. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Correct wrong wording in a comment I came across this PR while researching the same issue using Windows11 w/ JDK8. If my comment is of merit, I can provide the exact JDK8 build. As I read the history of this PR, I can't help but feel that maybe it's gone a little off course? I agree with the reasoning for the addition of: `getSystemIcon(file,w,w)` i.e. to me, it only makes sense that since Win10/11 changed the behavior of getSystemIcon(file), then a new method is required to be more specific. However, I'm not sure I agree that forcing the legacy method `getSystemIcon()` to return 16x16 is the best solution. While I understand that it has historically worked that way, it does not seem to be a documented feature that the icon will always be 16x16 but rather a "coincidence" based on OS system implementation. Seems to me that the best cross platform approach is to return the icon based on the OS behavior. While I certainly understand that behavior might result in "odd" UI changes, at least the raw system icon is returned and the end programmer can make decisions how to best handle it (certainly wouldn't be the first time java programmers have to account for multiple OS behavior). It does put a burden on the end programmer if they want a certain size (and I also understand that most will want that based on consistent UI designs), but that behavior is fairly easy to implement and a default implementation of that could be *added* to the API as well (although, IMO, it would b e nice but is the lowest on my personal priority list). I hope I've expressed my reasoning well. Just thought some input from "the field" might be of some value. p.s. I also realize this PR is closed but it still seemed like the best place to leave the feedback since several other issues were spawned from this one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/7805#issuecomment-1556208677 From tr at openjdk.org Mon May 22 06:58:10 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 May 2023 06:58:10 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v9] In-Reply-To: References: Message-ID: On Fri, 19 May 2023 19:22:05 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/java/awt/ScrollPane/ComponentScrollTest.java line 82: > >> 80: try { >> 81: EventQueue.invokeAndWait(() -> { >> 82: scrollpane.getVAdjustable().setValue(20); > > I suggest moving the remaining line to `init()` too. The code will be cleaner then. Looks like its old code. > test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 47: > >> 45: import java.awt.event.MouseAdapter; >> 46: >> 47: import java.util.Properties; > > The `Properties` import is unused. Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 54: > >> 52: static final int SCROLL_POS = 50000; >> 53: public static Component child = null; >> 54: static CountDownLatch go = new CountDownLatch(1); > > Suggestion: > > static final CountDownLatch go = new CountDownLatch(1); Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 90: > >> 88: pane.doLayout(); >> 89: }); >> 90: robot = new Robot(); > > It makes no difference, yet `robot` isn't used in `init()`, so I propose moving it to `start()`. Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 96: > >> 94: try { >> 95: robot.delay(1000); >> 96: robot.waitForIdle(); > > Suggestion: > > robot.waitForIdle(); > robot.delay(1000); > > Usually, these lines come in reverse order. Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 128: > >> 126: Dimension d = pane.getSize(); >> 127: point.x += d.width / 2; >> 128: point.y += d.height / 2; > > Suggestion: > > p = pane.getLocationOnScreen(); > Dimension d = pane.getSize(); > point = new Point(p.x += d.width / 2, p.y += d.height / 2); > > This is safer, only one write to volatile `point`. Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 133: > >> 131: robot.mousePress(InputEvent.BUTTON1_DOWN_MASK); >> 132: robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK); >> 133: robot.waitForIdle(); > > This `waitForIdle` is redundant because you're waiting for the count-down on the next line. Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 94: > >> 92: robot.waitForIdle(); >> 93: robot.mouseMove(buttonLoc.x + buttonSize.width / 2, >> 94: buttonLoc.y + buttonSize.height / 2); > > Suggestion: > > robot.waitForIdle(); > robot.delay(1000); > > robot.mouseMove(buttonLoc.x + buttonSize.width / 2, > buttonLoc.y + buttonSize.height / 2); > > > I propose reversing `delay` and `waitForIdle` to the usual order. (Robot could be create here rather than in `init`. > > I propose adding a blank line to visually separate waiting from the posting events to the UI. Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 100: > >> 98: robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK); >> 99: >> 100: robot.delay(50); > > This additional `delay` is redundant, you're waiting on the next line anyway. Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 114: > >> 112: } >> 113: >> 114: private static class Semaphore { > > The `Semaphore` class is unused now, remove it. Removed. > test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 87: > >> 85: >> 86: vScroll.addAdjustmentListener(this); >> 87: hScroll.addAdjustmentListener(this); > > [In my previous comment](https://github.com/openjdk/jdk/pull/13621#discussion_r1179076672), I also meant listeners should also be added inside `invokeAndWait`. Updated. > test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 135: > >> 133: >> 134: notifyReceived = false; >> 135: synchronized (LOCK) { > > Suggestion: > > synchronized (LOCK) { > notifyReceived = false; > > The `notifyReceived` must always be read and written inside a synchronised block. Other places should also be corrected. Updated. > test/jdk/java/awt/ScrollPane/ScrollPositionIntact.java line 72: > >> 70: }); >> 71: } >> 72: } > > It does not even compile. > > Add a blank line before `init` and remove `try`-block to make it compilable. My bad, I updated the wrong commit for this particular file. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200041902 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200042110 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200042538 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200044118 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200042017 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200042228 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200042318 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200042657 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200043142 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200043909 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200042837 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200042911 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200043736 From tr at openjdk.org Mon May 22 07:06:37 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 May 2023 07:06:37 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v10] In-Reply-To: References: Message-ID: > Open source few AWT ScrollPane related tests. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13621/files - new: https://git.openjdk.org/jdk/pull/13621/files/c10491b5..23b51603 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=08-09 Stats: 111 lines in 4 files changed: 28 ins; 61 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/13621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621 PR: https://git.openjdk.org/jdk/pull/13621 From duke at openjdk.org Mon May 22 07:12:03 2023 From: duke at openjdk.org (JoKern65) Date: Mon, 22 May 2023 07:12:03 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> Message-ID: On Thu, 18 May 2023 15:20:22 GMT, Kim Barrett wrote: >> Use >> >> struct shmid_ds shm_buf{}; >> >> to _value-initialize_. Calls the default constructor if there is one. Otherwise, performs _zero-initialization_, >> which is what we want here. > > The final suggested change (to direct-value-initialize the object) seems to have *not* been made. > > However, I think it doesn't matter. The mentioned restriction against being non-empty until C23 is not relevant. > This is C++, not C. Empty initializers are, and have always been, permitted by C++. Strange the last resulting change I see is `struct shmid_ds shm_buf{};` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1200056697 From psadhukhan at openjdk.org Mon May 22 08:41:23 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 22 May 2023 08:41:23 GMT Subject: RFR: 8307311: Timeouts on one macOS 12.6.1 host of two Swing JTableHeader tests [v2] In-Reply-To: References: Message-ID: > Issue was bug6889007.java was causing a timeout issue on mac system. Although bug6889007.java fail with small test group with "Wrong cursor type" error, it could not reproduce bug6884066.java > The hang issue might be due to waitForIdle() being called in loop which will be calling sync() so replaced with delay.. > > Modified fix passed the suggested small test group `desktop_timeout ` several times in all platforms > in addition to several iterations of the test run in standalone mode in all platforms.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: remove delay ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14026/files - new: https://git.openjdk.org/jdk/pull/14026/files/85d4cf0f..36225b73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14026&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14026&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14026.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14026/head:pull/14026 PR: https://git.openjdk.org/jdk/pull/14026 From psadhukhan at openjdk.org Mon May 22 08:41:23 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 22 May 2023 08:41:23 GMT Subject: RFR: 8307311: Timeouts on one macOS 12.6.1 host of two Swing JTableHeader tests [v2] In-Reply-To: References: <2xWe3W_n7yyQjr3o3tfoPOs7OFuDOQf6RHKgqEF4aVw=.d95b1711-ff38-4483-8d0f-abb086bbaf17@github.com> Message-ID: On Fri, 19 May 2023 11:48:45 GMT, Prasanta Sadhukhan wrote: >> This seems OK to me for a rarely repeated operation. >> Here it is repeated 405 times(at least for my testing), which leads to an additional ~40.5 s of the test execution time. >> 100ms is still a pretty solid delay for mouse movement. > > ok Removed setAutoDelay as there are no other robot usage apart from the mouseMove where I retained the delay.. Testing is green. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14026#discussion_r1200155639 From psadhukhan at openjdk.org Mon May 22 09:50:21 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 22 May 2023 09:50:21 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v8] In-Reply-To: References: Message-ID: > Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. > In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. > Fixed by implementing the equality and hashCode method for CSS.FontSize class. > > All jtreg/jck tests are ok Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test and fix updated as per review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13405/files - new: https://git.openjdk.org/jdk/pull/13405/files/717d1a1d..88841b82 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=06-07 Stats: 184 lines in 2 files changed: 68 ins; 71 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/13405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13405/head:pull/13405 PR: https://git.openjdk.org/jdk/pull/13405 From psadhukhan at openjdk.org Mon May 22 09:53:52 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 22 May 2023 09:53:52 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v7] In-Reply-To: References: Message-ID: On Fri, 19 May 2023 16:19:20 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> hashCode fix > > src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2680: > >> 2678: if (percentage) { >> 2679: return false; >> 2680: } else { > > Why are percentage values never equal? > > I expect two attribute sets produced from `"margin-top: 100%"` to be equal. However, the real length on rendering could be different if the attribute is applied to different elements. I was not sure how to get the other value which is told in the spec where it says percentage needs another value to be passed in. Also checking for percentage equality resulted in regression in one closed test bug4690812.java so percentage equality was not handled. https://github.com/openjdk/jdk/blob/8aa50288a1a6a853bf4d8d97b1849d5744ed7a32/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L2607-L2609 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1200275173 From itakiguchi at openjdk.org Mon May 22 10:20:53 2023 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Mon, 22 May 2023 10:20:53 GMT Subject: RFR: 8307953: [AIX] C locale's font setting was changed by JEP 400 In-Reply-To: References: Message-ID: On Thu, 11 May 2023 18:23:45 GMT, Ichiroh Takiguchi wrote: > On AIX, lib/fontconfig.bfc file is used to find font setting. > I ran SwingSet2 List demo program with AIX C locale. > JDK21's line spacing is larger then JDK17. > Screen shots are in [JDK-8307953](https://bugs.openjdk.org/browse/JDK-8307953). > When I used `-Dfile.encoding=COMPAT` option on AIX C locale, SwingSet2 worked fine as expected. > > This situation happens `Charset.defaultCharset()` always returns UTF-8 after JEP 400 by default. > `native.encoding` system property has platform's encoding/charset name. > If platform's charset name is not supported by Java, charset name should be `UTF-8`. > > Additionally, following parts are changed: > `src/java.desktop/aix/data/fontconfig/fontconfig.propertie`s has invalid charset name. > For Java for AIX: > - Encoding name for AIX's Zh_TW locale is `big5`, charset name should be `x-IBM950` instead of `big5`. > - Encoding name for AIX's zh_CN locale is `IBM-eucCN`, charset name should be `x-IBM1383` instead of `x-EUCCN`. > > In my understanding, this fix affects just for AIX platform. > > Note: > macos-x64 tier1 test was failed, but I think it's not related this PR. Gentle reminder, could you give reviewer suggestions ? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13937#issuecomment-1556953613 From itakiguchi at openjdk.org Mon May 22 10:20:54 2023 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Mon, 22 May 2023 10:20:54 GMT Subject: RFR: 6928542: Chinese characters in RTF are not decoded In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 05:47:35 GMT, Ichiroh Takiguchi wrote: > "character set of font" (font charset) table was created by "Rich Text Format Specification 1.9.1" > https://interoperability.blob.core.windows.net/files/Archive_References/[MSFT-RTF].pdf > It refers windgi.h > https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-textmetrica > > Test files and testcase are in bugid [JDK-6928542](https://bugs.openjdk.org/browse/JDK-6928542) > > Additional change: > Special character `\line` should `\n` > > **Note:** Following GitHub actions were failed > linux-x86 / test (jdk/tier1 part 1) was failed, it seems it was already reported >> [JDK-8305875](https://bugs.openjdk.org/browse/JDK-8305875) Test TraceVirtualThreadLocals should be run with continuations only > > windows-aarch64 / build (debug) was failed, but I have no idea... Gentle reminder, could you give reviewer suggestions ? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13553#issuecomment-1556952913 From aivanov at openjdk.org Mon May 22 10:56:55 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 May 2023 10:56:55 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v7] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 09:51:12 GMT, Prasanta Sadhukhan wrote: > I was not sure how to get the other value which is told in the spec where it says percentage needs another value to be passed in. Also checking for percentage equality resulted in regression in one closed test bug4690812.java so percentage equality was not handled. > > https://github.com/openjdk/jdk/blob/8aa50288a1a6a853bf4d8d97b1849d5744ed7a32/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L2607-L2609 I don't think you need to. In this case, AttributeSets are compared. All the relative units will result in different computed value depending on the element they're applied to. I'll take a look at the test. I can't see how implementation of `equals` affects that test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1200345789 From aivanov at openjdk.org Mon May 22 11:03:54 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 May 2023 11:03:54 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v8] In-Reply-To: References: Message-ID: <4tS4xhEMMPxLcIvzhUws3c3lD7Bv5H87mH46iuuF51s=.54620da5-6b9f-44d1-a15b-aaf5ebee7c74@github.com> On Mon, 22 May 2023 09:50:21 GMT, Prasanta Sadhukhan wrote: >> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. >> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. >> Fixed by implementing the equality and hashCode method for CSS.FontSize class. >> >> All jtreg/jck tests are ok > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test and fix updated as per review comments Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2235: > 2233: return value == size.value; > 2234: } > 2235: return false; Is it not enough to compare `value`, `index` and `lu` fields of `FontSize` object? Parsing the value string does not look good. ------------- PR Review: https://git.openjdk.org/jdk/pull/13405#pullrequestreview-1436370423 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1200351364 From azvegint at openjdk.org Mon May 22 11:36:51 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 22 May 2023 11:36:51 GMT Subject: RFR: 8307311: Timeouts on one macOS 12.6.1 host of two Swing JTableHeader tests [v2] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 08:41:23 GMT, Prasanta Sadhukhan wrote: >> Issue was bug6889007.java was causing a timeout issue on mac system. Although bug6889007.java fail with small test group with "Wrong cursor type" error, it could not reproduce bug6884066.java >> The hang issue might be due to waitForIdle() being called in loop which will be calling sync() so replaced with delay.. >> >> Modified fix passed the suggested small test group `desktop_timeout ` several times in all platforms >> in addition to several iterations of the test run in standalone mode in all platforms.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > remove delay Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14026#pullrequestreview-1436428788 From azvegint at openjdk.org Mon May 22 11:40:00 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 22 May 2023 11:40:00 GMT Subject: Integrated: 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland In-Reply-To: References: Message-ID: On Fri, 5 May 2023 12:27:04 GMT, Alexander Zvegintsev wrote: > On Linux systems, we rely on XGrabPointer (X11 API) to capture mouse input and dismiss popup menus on mouse clicks outside the popup menu. > Unfortunately, on Linux systems using the [Wayland](https://wayland.freedesktop.org/) session this only works inside [XWayland(Wayland's X11 server implementation)](https://wayland.freedesktop.org/xserver.html). > This means if a user clicks on a part of the screen not controlled by XWayland (e.g. window decorations, other non X11 applications) the popup menu will not be hidden. > > As a workaround, we can hide this menu when the parent popup menu window loses focus. > However, it does have its drawbacks, which should be described in the documentation.The focus does not change when clicking on the header of its own parent window or on non-focusable windows, .e.g., empty space in system dock, so in this case the popup menu is not hidden. > > Third-party applications use a similar approach. > > I also have doubts about the need to change the documentation, as I can't find where it is described that the popup menu should be hidden when clicked outside the menu. > > CSR: https://bugs.openjdk.org/browse/JDK-8307529 This pull request has now been integrated. Changeset: 3d550f74 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/3d550f748521443dc2e148aa4f786060419f1113 Stats: 202 lines in 6 files changed: 179 ins; 0 del; 23 mod 8280993: [XWayland] Popup is not closed on click outside of area controlled by XWayland Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13830 From psadhukhan at openjdk.org Mon May 22 11:44:58 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 22 May 2023 11:44:58 GMT Subject: Integrated: 8307311: Timeouts on one macOS 12.6.1 host of two Swing JTableHeader tests In-Reply-To: References: Message-ID: <2Xo50Ql0Dvq-2y7vKkVohifppTqrhjXmhpnP3h2j4xY=.9cbaa6d6-d479-4e12-b03b-a3907afc13fd@github.com> On Wed, 17 May 2023 07:06:01 GMT, Prasanta Sadhukhan wrote: > Issue was bug6889007.java was causing a timeout issue on mac system. Although bug6889007.java fail with small test group with "Wrong cursor type" error, it could not reproduce bug6884066.java > The hang issue might be due to waitForIdle() being called in loop which will be calling sync() so replaced with delay.. > > Modified fix passed the suggested small test group `desktop_timeout ` several times in all platforms > in addition to several iterations of the test run in standalone mode in all platforms.. This pull request has now been integrated. Changeset: b3cb82b8 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/b3cb82b859d22b18343d125349a5aebc0afb8576 Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod 8307311: Timeouts on one macOS 12.6.1 host of two Swing JTableHeader tests Reviewed-by: dnguyen, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/14026 From aivanov at openjdk.org Mon May 22 12:53:15 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 May 2023 12:53:15 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v10] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 07:06:37 GMT, Tejesh R wrote: >> Open source few AWT ScrollPane related tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Changes requested by aivanov (Reviewer). test/jdk/java/awt/ScrollPane/ScrollPaneExtraScrollBar.java line 71: > 69: try { > 70: robot.delay(100); > 71: robot.waitForIdle(); Optionally, Suggestion: robot = new Robot(); robot.waitForIdle(); robot.delay(100); To be consistent with other tests in this review. test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 115: > 113: Container cp = child.getParent(); > 114: p = cp.getLocation(); > 115: if (p.y != -SCROLL_POS) { Suggestion: p = cp.getLocation(); System.out.println("Child's parent pos = " + p); if (p.y != -SCROLL_POS) { Just to make it clear that this branch is taken. Otherwise the test ends with the message: Child pos = java.awt.Point[x=0,y=0] which is confusing. Yet no exception is thrown. test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 125: > 123: p = pane.getLocationOnScreen(); > 124: Dimension d = pane.getSize(); > 125: point = new Point(p.x += d.width / 2, p.y += d.height / 2); Suggestion: point = new Point(p.x + d.width / 2, p.y + d.height / 2); There's no need to update the value stored in `p`. test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 76: > 74: frame.pack(); > 75: frame.setLocationRelativeTo(null); > 76: frame.setAlwaysOnTop(true); I wonder why you decided to make the frame in this test always on top? test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 83: > 81: public void start() throws Exception { > 82: try { > 83: Robot robot = new Robot(); Since you moved it as suggested, I see no reason why it's declared here rather than at line before `robot.waitForIdle`, that is the first usage. test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 85: > 83: System.out.println("Adjustment Vertical Scroll Event called "); > 84: } > 85: }); Suggestion: vScroll.addAdjustmentListener(ScrollPaneWindowsTest.this); Isn't it more concise without introducing any duplicate code? test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 115: > 113: > 114: robot.delay(100); > 115: robot.waitForIdle(); Suggestion: robot = new Robot(); robot.waitForIdle(); robot.delay(100); test/jdk/java/awt/ScrollPane/ScrollPositionIntact.java line 77: > 75: Robot robot = new Robot(); > 76: robot.delay(1000); > 77: robot.waitForIdle(); Suggestion: Robot robot = new Robot(); robot.waitForIdle(); robot.delay(1000); Let's make this piece of code consistent in all the tests. ------------- PR Review: https://git.openjdk.org/jdk/pull/13621#pullrequestreview-1436387950 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200456271 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200463397 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200362994 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200364050 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200366170 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200370354 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200468052 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200373022 From tr at openjdk.org Mon May 22 13:12:03 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 May 2023 13:12:03 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v10] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 11:10:05 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 76: > >> 74: frame.pack(); >> 75: frame.setLocationRelativeTo(null); >> 76: frame.setAlwaysOnTop(true); > > I wonder why you decided to make the frame in this test always on top? When I run the folder, due to previous test/command prompt the frame used to show up behind command prompt, so to be on safer side I used always on top. When we run individual test, it works fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200496068 From aivanov at openjdk.org Mon May 22 13:25:06 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 May 2023 13:25:06 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v10] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 13:09:20 GMT, Tejesh R wrote: >> test/jdk/java/awt/ScrollPane/ScrollPaneRemoveAdd.java line 76: >> >>> 74: frame.pack(); >>> 75: frame.setLocationRelativeTo(null); >>> 76: frame.setAlwaysOnTop(true); >> >> I wonder why you decided to make the frame in this test always on top? > > When I run the folder, due to previous test/command prompt the frame used to show up behind command prompt, so to be on safer side I used always on top. When we run individual test, it works fine. It may still not work? You have to disable keyboard input timeout by setting `ForegroundLockTimeout` to zero as explained in [requirements for Windows](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements#AutomatedclientGUItestingsystemsetuprequirements-Windows-SpecificSystemsetupnotes). Most likely, you don't want to do it on the system that you regularly use, otherwise apps could steal focus. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200511473 From tr at openjdk.org Mon May 22 13:51:46 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 May 2023 13:51:46 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v11] In-Reply-To: References: Message-ID: > Open source few AWT ScrollPane related tests. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13621/files - new: https://git.openjdk.org/jdk/pull/13621/files/23b51603..4f1503a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=09-10 Stats: 48 lines in 5 files changed: 18 ins; 26 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621 PR: https://git.openjdk.org/jdk/pull/13621 From tr at openjdk.org Mon May 22 13:51:50 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 May 2023 13:51:50 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v10] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 12:42:05 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 115: > >> 113: Container cp = child.getParent(); >> 114: p = cp.getLocation(); >> 115: if (p.y != -SCROLL_POS) { > > Suggestion: > > p = cp.getLocation(); > System.out.println("Child's parent pos = " + p); > if (p.y != -SCROLL_POS) { > > Just to make it clear that this branch is taken. Otherwise the test ends with the message: > > Child pos = java.awt.Point[x=0,y=0] > > which is confusing. Yet no exception is thrown. Child location is expected to be 0,0 as explained in the test, whereas parents position is -500, hence no exception is thrown. > test/jdk/java/awt/ScrollPane/ScrollPaneWindowsTest.java line 85: > >> 83: System.out.println("Adjustment Vertical Scroll Event called "); >> 84: } >> 85: }); > > Suggestion: > > vScroll.addAdjustmentListener(ScrollPaneWindowsTest.this); > > Isn't it more concise without introducing any duplicate code? Updated and tested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200540594 PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200542415 From tr at openjdk.org Mon May 22 13:51:52 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 May 2023 13:51:52 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v10] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 13:21:53 GMT, Alexey Ivanov wrote: >> When I run the folder, due to previous test/command prompt the frame used to show up behind command prompt, so to be on safer side I used always on top. When we run individual test, it works fine. > > It may still not work? You have to disable keyboard input timeout by setting `ForegroundLockTimeout` to zero as explained in [requirements for Windows](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements#AutomatedclientGUItestingsystemsetuprequirements-Windows-SpecificSystemsetupnotes). > > Most likely, you don't want to do it on the system that you regularly use, otherwise apps could steal focus. Its working fine after setting to always on top, tested multiple times. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200536924 From aivanov at openjdk.org Mon May 22 14:03:05 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 May 2023 14:03:05 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v10] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 13:44:59 GMT, Tejesh R wrote: >> test/jdk/java/awt/ScrollPane/ScrollPaneLimitation.java line 115: >> >>> 113: Container cp = child.getParent(); >>> 114: p = cp.getLocation(); >>> 115: if (p.y != -SCROLL_POS) { >> >> Suggestion: >> >> p = cp.getLocation(); >> System.out.println("Child's parent pos = " + p); >> if (p.y != -SCROLL_POS) { >> >> Just to make it clear that this branch is taken. Otherwise the test ends with the message: >> >> Child pos = java.awt.Point[x=0,y=0] >> >> which is confusing. Yet no exception is thrown. > > Child location is expected to be 0,0 as explained in the test, whereas parents position is -500, hence no exception is thrown. Yes, this is adding the suggested print will resolve all the confusion because you will see: ... Scroll pos = java.awt.Point[x=0,y=50000] Child pos = java.awt.Point[x=0,y=0] Child's parent pos = java.awt.Point[x=0,y=-50000] Isn't it clearer? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200559746 From aivanov at openjdk.org Mon May 22 14:08:06 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 May 2023 14:08:06 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v11] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 13:51:46 GMT, Tejesh R wrote: >> Open source few AWT ScrollPane related tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments I'm for resolving [this comment](https://github.com/openjdk/jdk/pull/13621#discussion_r1200559746) to make the output clearer. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13621#pullrequestreview-1436719535 From tr at openjdk.org Mon May 22 14:17:11 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 May 2023 14:17:11 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v10] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 13:59:47 GMT, Alexey Ivanov wrote: >> Child location is expected to be 0,0 as explained in the test, whereas parents position is -500, hence no exception is thrown. > > Yes, this is adding the suggested print will resolve all the confusion because you will see: > > > ... > Scroll pos = java.awt.Point[x=0,y=50000] > Child pos = java.awt.Point[x=0,y=0] > Child's parent pos = java.awt.Point[x=0,y=-50000] > > > Isn't it clearer? Yeah, can do it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200577827 From aivanov at openjdk.org Mon May 22 14:17:57 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 May 2023 14:17:57 GMT Subject: RFR: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java [v3] In-Reply-To: References: Message-ID: On Mon, 15 May 2023 04:17:45 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> Noticed this test case not verifying all the cases which is intended. Modified it for improving the coverage for 3 type of popups (menu, context menu and combobox). >> >> Evaluating conditions: >> 1. Not enough space for showing popup downwards(default layout), it should show upwards >> 2. Window starts from negative position, Popup should show on visible area >> >> For achieving this following areas are modified >> - Updated isPopupOnScreen by adding Additional checks (like the position of combobox popup is always verified) >> - Menu creation made as function and reused for all menu creation. >> - Updated ComboPopupCheckListener class and modified its popupMenuWillBecomeInvisible function. Made it as generic and it is capable to evaluate any combo box's position if this class set as its listener. >> - This test case is not intended for multi monitor setup so added a check for identifying monitor, else error out. >> - Updated CTRL_MASK to CTRL_DOWN_MASK for removing depreciation warnings and removed some other warnings. >> >> Please review this >> >> Regards, >> Renjith. > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated test description with more meaning full message Marked as reviewed by aivanov (Reviewer). test/jdk/javax/swing/Popup/TaskbarPositionTest.java line 64: > 62: * @summary Tests the location of the heavy weight popup portion of JComboBox, > 63: * JMenu and JPopupMenu. > 64: * The test uses Ctrl+Down Arrow (?) which is a system shortcut on macOS, I'm unsure if we're allowed using Unicode chars inside the tests. It shouldn't be a problem here because it's in a comment. ------------- PR Review: https://git.openjdk.org/jdk/pull/13578#pullrequestreview-1436739187 PR Review Comment: https://git.openjdk.org/jdk/pull/13578#discussion_r1200578324 From avu at openjdk.org Mon May 22 14:21:56 2023 From: avu at openjdk.org (Alexey Ushakov) Date: Mon, 22 May 2023 14:21:56 GMT Subject: RFR: 8308286 Fix clang warnings in linux code In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov wrote: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. I would suggest either disable warnings on per file basis or rewrite problematic code. Disabling warnings per fragment of code makes it less readable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1557306893 From tr at openjdk.org Mon May 22 14:23:44 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 May 2023 14:23:44 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v12] In-Reply-To: References: Message-ID: > Open source few AWT ScrollPane related tests. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13621/files - new: https://git.openjdk.org/jdk/pull/13621/files/4f1503a8..55c7974a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=10-11 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621 PR: https://git.openjdk.org/jdk/pull/13621 From tr at openjdk.org Mon May 22 14:36:08 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 May 2023 14:36:08 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v13] In-Reply-To: References: Message-ID: > Open source few AWT ScrollPane related tests. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13621/files - new: https://git.openjdk.org/jdk/pull/13621/files/55c7974a..84c0961c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=11-12 Stats: 5 lines in 2 files changed: 2 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621 PR: https://git.openjdk.org/jdk/pull/13621 From aivanov at openjdk.org Mon May 22 14:36:09 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 May 2023 14:36:09 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v12] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 14:23:44 GMT, Tejesh R wrote: >> Open source few AWT ScrollPane related tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13621#pullrequestreview-1436760231 From aivanov at openjdk.org Mon May 22 14:36:10 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 May 2023 14:36:10 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v13] In-Reply-To: References: Message-ID: <1mowzwsGO1-HXhpX2ca4bARU7B2PSPZeuqX58f2Hy00=.4668f493-8ed6-4491-a5ef-1688b5478acb@github.com> On Mon, 22 May 2023 14:29:35 GMT, Tejesh R wrote: >> Open source few AWT ScrollPane related tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13621#pullrequestreview-1436766979 From aivanov at openjdk.org Mon May 22 14:36:12 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 May 2023 14:36:12 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v10] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 14:14:06 GMT, Tejesh R wrote: >> Yes, this is adding the suggested print will resolve all the confusion because you will see: >> >> >> ... >> Scroll pos = java.awt.Point[x=0,y=50000] >> Child pos = java.awt.Point[x=0,y=0] >> Child's parent pos = java.awt.Point[x=0,y=-50000] >> >> >> Isn't it clearer? > > Yeah, can do it. Thank you! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1200591609 From aivanov at openjdk.org Mon May 22 15:21:52 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 May 2023 15:21:52 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v7] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 10:54:24 GMT, Alexey Ivanov wrote: > I don't think you need to. In this case, AttributeSets are compared. All the relative units will result in different computed value depending on the element they're applied to. Here's a [sample HTML file](https://cr.openjdk.org/~aivanov/7083187/percentage-values.html). Both `

    ` and `` element have CSS rule `font-size: 200%`. The computed value for `p` is based on its parent font size, which is the `body` element. The computed value of `span` is also based on its parent font size, its parent is `p` element, therefore the font-size of `span` is twice as large as in `p` and four times larger compared to `body`. At the same time, the attribute sets applied to `p` and `span` should be considered equal because they contain the same rules. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1200665776 From aivanov at openjdk.org Mon May 22 15:59:06 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 22 May 2023 15:59:06 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> Message-ID: On Wed, 17 May 2023 16:47:56 GMT, Tejesh R wrote: >> This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. >> The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 725: > 723: || (chooser.isDirectorySelectionEnabled() > 724: && (fsv.isFileSystem(f) > 725: || (fsv.isLink(f) && Files.isSymbolicLink(f.toPath()))) I don't think it's correct. `Files.isSymbolicLink` should only be called for objects for which `fsv.isFileSystem(f)` returns `true`. `fsv.isLink(f)` returns `true` for `.lnk` files which are the common Windows shortcuts; such a file can also be a symbolic link. test/jdk/javax/swing/JFileChooser/FileChooserIPETest.java line 45: > 43: */ > 44: > 45: public class FileChooserIPETest { Suggestion: public class FileChooserInvalidPathExceptionTest { Isn't it more descriptive this way? IPE isn't as common as NPE. test/jdk/javax/swing/JFileChooser/FileChooserIPETest.java line 68: > 66: Network. > 67: 2. Select and traverse through those folders. > 68: 3. If InvalidPathException occurs then test FAIL else test is PASS. You may be more specific: if exception occurs, the test fails automatically. ------------- PR Review: https://git.openjdk.org/jdk/pull/13998#pullrequestreview-1436912464 PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1200690007 PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1200711027 PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1200708730 From tr at openjdk.org Mon May 22 16:10:06 2023 From: tr at openjdk.org (Tejesh R) Date: Mon, 22 May 2023 16:10:06 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> Message-ID: On Mon, 22 May 2023 15:39:32 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 725: > >> 723: || (chooser.isDirectorySelectionEnabled() >> 724: && (fsv.isFileSystem(f) >> 725: || (fsv.isLink(f) && Files.isSymbolicLink(f.toPath()))) > > I don't think it's correct. > > `Files.isSymbolicLink` should only be called for objects for which `fsv.isFileSystem(f)` returns `true`. > > `fsv.isLink(f)` returns `true` for `.lnk` files which are the common Windows shortcuts; such a file can also be a symbolic link. `Files.isSymbolicLink` takes path as argument to check if its a symbolic link. For certain windows specific files as explained the path won't be exact path, rather a hex values. So directly validating with path is causing an exception. So `fsv.isLink()` is used as a first level validation which uses File to check if its valid. I didn't find any other alternatives to validate the file path, so used `fsv.isLink` as first level validation along with Symbolic Link check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1200729311 From serb at openjdk.org Mon May 22 17:20:22 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 22 May 2023 17:20:22 GMT Subject: RFR: 8307132: Cleanup the code of sun.java2d.cmm.lcms package [v3] In-Reply-To: <_LRz2K4G7ZNjIO9C_5z2N9xWTfz25uUtRmefY2FRfkA=.d111a3fc-4264-43fb-a238-dc7129c61506@github.com> References: <_LRz2K4G7ZNjIO9C_5z2N9xWTfz25uUtRmefY2FRfkA=.d111a3fc-4264-43fb-a238-dc7129c61506@github.com> Message-ID: > The description from big to small: > > - Our code to handle the image types we support is too generic, the LCMSImageLayout class can handle, byte, short, int, and double types, and many various properties of the image layout. As a result, we pass a couple of good parameters to the LCMSImageLayout and have to use safeXX methods in it to calculate the final layout, and then validate it. > This patch moves the layout properties calculation to one place - the constructor of LCMSImageLayout, and from the outside of the class, we now pass only the data array and the number of components per pixel: > - The usage of Double type is removed, we do not use that type currently, and do not plan to support it in the future. Note that we support the float type, and I tried to implement it, but unfortunately, it is [intentionally ](https://github.com/mm2/Little-CMS/issues/356)slow. So will continue to use short type instead of float. > - Discussed a few times the `do { } while (false);` block is removed. Sergey Bylokhov 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 six additional commits since the last revision: - Merge branch 'openjdk:master' into cms_cleanup_v3 - split type and size - add a comment - Merge branch 'master' into cms_cleanup_v3 - Merge branch 'master' into cms_cleanup_v3 - 8307132: Cleanup the code of sun.java2d.cmm.lcms package ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13732/files - new: https://git.openjdk.org/jdk/pull/13732/files/fcf3bcbc..d9c35f85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13732&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13732&range=01-02 Stats: 159749 lines in 2909 files changed: 119836 ins; 19918 del; 19995 mod Patch: https://git.openjdk.org/jdk/pull/13732.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13732/head:pull/13732 PR: https://git.openjdk.org/jdk/pull/13732 From prr at openjdk.org Mon May 22 18:04:51 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 22 May 2023 18:04:51 GMT Subject: RFR: 8308286 Fix clang warnings in linux code In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov wrote: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. I don't like this approach at all. if github had a "reject" button I'd be pushing it now. updating the makefiles is the normal way to do this but I don't know if we even want that. Until clang is the supported compiler for Linux then I see no reason for this to be in JDK at all. Code changes which make it so there's no warning would be the preferred way but I'd expect that to be tested properly. Also if the warning is spurious - sometimes they are - then that would NOT be appropriate. ------------- Changes requested by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1437172390 From azvegint at openjdk.org Mon May 22 18:17:27 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 22 May 2023 18:17:27 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v4] In-Reply-To: References: Message-ID: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - enable by default for Wayland - Merge branch 'master' into X11_compatibility_screencast - refactoring to remove resetScreenCapturePermission - update, based on review comments - remove wayland detection - BUILD_LIBPIPEWIRE_HEADER_DIRS -> LIBPIPEWIRE_HEADER_DIRS - replace tabs with spaces - main changes - add pipewire header files ------------- Changes: https://git.openjdk.org/jdk/pull/13803/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=03 Stats: 14701 lines in 106 files changed: 14663 ins; 18 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From jiangli at openjdk.org Mon May 22 19:14:00 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 19:14:00 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: Message-ID: On Fri, 19 May 2023 22:45:16 GMT, Erik Joelsson wrote: >> make/common/NativeCompilation.gmk line 1208: >> >>> 1206: $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ >>> 1207: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ >>> 1208: $$($1_LD_OBJ_ARG)) >> >> This command line is missing `$$($1_SYSROOT_LDFLAGS)` which is causing it to fail in our builds with: >> >> ld: library not found for -lSystem > > This is the mac failure, sorry if that wasn't clear. Thanks @erikj79. Could you please help provide some more info on the build failure: Which macOs version ran into the build issue? My mac is on Ventura 13.3.1 (a). It builds successfully for the `static-libs-image` target. Does it fail when partially linking `libjvm_relocatable.o` only, or it fails when partially linking other native libraries as well on macosx? Could you please share the partial linking command, e.g. hotspot/variant-server/libjvm/gtest/objs/static/BUILD_GTEST_LIBJVM_partial_link.cmdline? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200929473 From jiangli at openjdk.org Mon May 22 19:24:52 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 19:24:52 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries In-Reply-To: References: Message-ID: On Mon, 22 May 2023 19:10:57 GMT, Jiangli Zhou wrote: > Thanks @erikj79. Could you please help provide some more info on the build failure: > > Which macOs version ran into the build issue? My mac is on Ventura 13.3.1 (a). It builds successfully for the `static-libs-image` target. > > Does it fail when partially linking `libjvm_relocatable.o` only, or it fails when partially linking other native libraries as well on macosx? Could you please share the partial linking command, e.g. hotspot/variant-server/libjvm/gtest/objs/static/BUILD_GTEST_LIBJVM_partial_link.cmdline? Additional info, following is the partial linking command from my `macosx-x86_64` build: /usr/bin/g++ -m64 -r -o /.../github/JDK-8307858/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/static/libjvm_relocatable.o @/.../github/JDK-8307858/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/static/_BUILD_GTEST_LIBJVM_objectfilenames.txt ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200946838 From jiangli at openjdk.org Mon May 22 19:40:00 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 19:40:00 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2] In-Reply-To: References: Message-ID: <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com> > Original description for JDK-8307194 change: > ----- > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > ----- > > Updates to address build failures reported on macosx- platforms: > > - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. > > The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. > > The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into JDK-8307858 - Merge branch 'master' into JDK-8307858 - Clean up. - In clude $MACHINE_FLAG in partial linking flag. - Use '-m32' instead of '-m elf_i386'. - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform. It's based on the post on https://www.linuxquestions.org/questions/linux-software-2/relocatable-linking-on-x86-64-for-i386-872812/. - Only do partial linking step with gcc/clang on 64-bit platform. There is a linking failure with linux-x86 build: /usr/bin/ld: relocatable linking with relocations from format elf32-i386 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/gmock-all.o) to format elf64-x86-64 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/libgtest_relocatable.o) is not supported - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG. - Merge branch 'master' into JDK-8307858 - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change. - ... and 2 more: https://git.openjdk.org/jdk/compare/8474e693...fb945210 ------------- Changes: https://git.openjdk.org/jdk/pull/14064/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=01 Stats: 201 lines in 10 files changed: 150 ins; 34 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/14064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064 PR: https://git.openjdk.org/jdk/pull/14064 From erikj at openjdk.org Mon May 22 19:47:51 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 22 May 2023 19:47:51 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 19:21:52 GMT, Jiangli Zhou wrote: >> Thanks @erikj79. Could you please help provide some more info on the build failure: >> >> Which macOs version ran into the build issue? My mac is on Ventura 13.3.1 (a). It builds successfully for the `static-libs-image` target. >> >> Does it fail when partially linking `libjvm_relocatable.o` only, or it fails when partially linking other native libraries as well on macosx? Could you please share the partial linking command, e.g. hotspot/variant-server/libjvm/gtest/objs/static/BUILD_GTEST_LIBJVM_partial_link.cmdline? > >> Thanks @erikj79. Could you please help provide some more info on the build failure: >> >> Which macOs version ran into the build issue? My mac is on Ventura 13.3.1 (a). It builds successfully for the `static-libs-image` target. >> >> Does it fail when partially linking `libjvm_relocatable.o` only, or it fails when partially linking other native libraries as well on macosx? Could you please share the partial linking command, e.g. hotspot/variant-server/libjvm/gtest/objs/static/BUILD_GTEST_LIBJVM_partial_link.cmdline? > > Additional info, following is the partial linking command from my `macosx-x86_64` build: > > > /usr/bin/g++ -m64 -r -o /.../github/JDK-8307858/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/static/libjvm_relocatable.o @/.../github/JDK-8307858/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/static/_BUILD_GTEST_LIBJVM_objectfilenames.txt It fails because we are using a "devkit" and not an installed Xcode. The SYSROOT flags must always be added to any compiler or link command lines. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200973154 From erikj at openjdk.org Mon May 22 19:57:59 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 22 May 2023 19:57:59 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2] In-Reply-To: <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com> References: <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com> Message-ID: On Mon, 22 May 2023 19:40:00 GMT, Jiangli Zhou wrote: >> Original description for JDK-8307194 change: >> ----- >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS >> ----- >> >> Updates to address build failures reported on macosx- platforms: >> >> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. >> >> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. >> >> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'master' into JDK-8307858 > - Merge branch 'master' into JDK-8307858 > - Clean up. > - In clude $MACHINE_FLAG in partial linking flag. > - Use '-m32' instead of '-m elf_i386'. > - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform. > > It's based on the post on https://www.linuxquestions.org/questions/linux-software-2/relocatable-linking-on-x86-64-for-i386-872812/. > - Only do partial linking step with gcc/clang on 64-bit platform. > > There is a linking failure with linux-x86 build: > > /usr/bin/ld: relocatable linking with relocations from format elf32-i386 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/gmock-all.o) to format elf64-x86-64 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/libgtest_relocatable.o) is not supported > - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG. > - Merge branch 'master' into JDK-8307858 > - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change. > - ... and 2 more: https://git.openjdk.org/jdk/compare/8474e693...fb945210 make/common/NativeCompilation.gmk line 1175: > 1173: > 1174: ifeq ($$($1_TYPE), STATIC_LIBRARY) > 1175: $1_VARDEPS := $$($1_AR) $$(ARFLAGS) $$($1_ARFLAGS) $$($1_LIBS) \ We also need to add some things to VARDEPS. Looks like at least `$$($1_LD)` and `$$($1_SYSROOT_LDFLAGS)` are needed. Maybe conditionally. make/common/NativeCompilation.gmk line 1208: > 1206: $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ > 1207: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ > 1208: $$($1_LD_OBJ_ARG)) This makes my build pass. Suggestion: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \ $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ $$($1_LD_OBJ_ARG)) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200980626 PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200982365 From jiangli at openjdk.org Mon May 22 20:57:43 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 20:57:43 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v3] In-Reply-To: References: Message-ID: > Original description for JDK-8307194 change: > ----- > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > ----- > > Updates to address build failures reported on macosx- platforms: > > - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. > > The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. > > The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update make/common/NativeCompilation.gmk Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14064/files - new: https://git.openjdk.org/jdk/pull/14064/files/fb945210..6a321bd1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064 PR: https://git.openjdk.org/jdk/pull/14064 From jiangli at openjdk.org Mon May 22 20:57:47 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 20:57:47 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2] In-Reply-To: References: <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com> Message-ID: On Mon, 22 May 2023 19:54:59 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' into JDK-8307858 >> - Merge branch 'master' into JDK-8307858 >> - Clean up. >> - In clude $MACHINE_FLAG in partial linking flag. >> - Use '-m32' instead of '-m elf_i386'. >> - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform. >> >> It's based on the post on https://www.linuxquestions.org/questions/linux-software-2/relocatable-linking-on-x86-64-for-i386-872812/. >> - Only do partial linking step with gcc/clang on 64-bit platform. >> >> There is a linking failure with linux-x86 build: >> >> /usr/bin/ld: relocatable linking with relocations from format elf32-i386 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/gmock-all.o) to format elf64-x86-64 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/libgtest_relocatable.o) is not supported >> - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG. >> - Merge branch 'master' into JDK-8307858 >> - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change. >> - ... and 2 more: https://git.openjdk.org/jdk/compare/8474e693...fb945210 > > make/common/NativeCompilation.gmk line 1208: > >> 1206: $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ >> 1207: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ >> 1208: $$($1_LD_OBJ_ARG)) > > This makes my build pass. > Suggestion: > > $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \ > $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \ > $$($1_LD_OBJ_ARG)) Thanks! Tested with a macosx-x86_64 build and also with our prototype on JDK 11 for linux-x64. They still build okay with the change. Looks like it affects/needed for cross build. Committing your fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1201077691 From jiangli at openjdk.org Mon May 22 21:28:04 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 21:28:04 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2] In-Reply-To: References: <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com> Message-ID: On Mon, 22 May 2023 19:52:42 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' into JDK-8307858 >> - Merge branch 'master' into JDK-8307858 >> - Clean up. >> - In clude $MACHINE_FLAG in partial linking flag. >> - Use '-m32' instead of '-m elf_i386'. >> - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform. >> >> It's based on the post on https://www.linuxquestions.org/questions/linux-software-2/relocatable-linking-on-x86-64-for-i386-872812/. >> - Only do partial linking step with gcc/clang on 64-bit platform. >> >> There is a linking failure with linux-x86 build: >> >> /usr/bin/ld: relocatable linking with relocations from format elf32-i386 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/gmock-all.o) to format elf64-x86-64 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/libgtest_relocatable.o) is not supported >> - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG. >> - Merge branch 'master' into JDK-8307858 >> - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change. >> - ... and 2 more: https://git.openjdk.org/jdk/compare/8474e693...fb945210 > > make/common/NativeCompilation.gmk line 1175: > >> 1173: >> 1174: ifeq ($$($1_TYPE), STATIC_LIBRARY) >> 1175: $1_VARDEPS := $$($1_AR) $$(ARFLAGS) $$($1_ARFLAGS) $$($1_LIBS) \ > > We also need to add some things to VARDEPS. Looks like at least `$$($1_LD)` and `$$($1_SYSROOT_LDFLAGS)` are needed. Maybe conditionally. Fix, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1201128665 From jiangli at openjdk.org Mon May 22 21:27:58 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 May 2023 21:27:58 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: > Original description for JDK-8307194 change: > ----- > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > ----- > > Updates to address build failures reported on macosx- platforms: > > - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. > > The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. > > The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14064/files - new: https://git.openjdk.org/jdk/pull/14064/files/6a321bd1..695bda5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=02-03 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064 PR: https://git.openjdk.org/jdk/pull/14064 From azvegint at openjdk.org Mon May 22 22:34:17 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 22 May 2023 22:34:17 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v5] In-Reply-To: References: Message-ID: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: Call loadGtk when awt.robot.gtk set to false ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/716e3201..53de29bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=03-04 Stats: 30 lines in 1 file changed: 29 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From psadhukhan at openjdk.org Tue May 23 04:09:50 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 23 May 2023 04:09:50 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v9] In-Reply-To: References: Message-ID: > Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. > In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. > Fixed by implementing the equality and hashCode method for CSS.FontSize class. > > All jtreg/jck tests are ok Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Percentage equality fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13405/files - new: https://git.openjdk.org/jdk/pull/13405/files/88841b82..745fe232 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=07-08 Stats: 17 lines in 2 files changed: 5 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/13405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13405/head:pull/13405 PR: https://git.openjdk.org/jdk/pull/13405 From mkartashev at openjdk.org Tue May 23 05:56:48 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Tue, 23 May 2023 05:56:48 GMT Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11 sessions In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 00:06:04 GMT, Sergey Bylokhov wrote: >>> What exact operation is slow? >> >> `X11GraphicsDevice.pGetBounds()`; I didn't measure further down. > >> `X11GraphicsDevice.pGetBounds()`; I didn't measure further down. > > It would be good to know the exact function to check where it is used. @mrserb So are there any outstanding issues with this PR? I'd still like to merge it even if it's not going to make it into 21. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13346#issuecomment-1558573237 From psadhukhan at openjdk.org Tue May 23 08:36:05 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 23 May 2023 08:36:05 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v8] In-Reply-To: <4tS4xhEMMPxLcIvzhUws3c3lD7Bv5H87mH46iuuF51s=.54620da5-6b9f-44d1-a15b-aaf5ebee7c74@github.com> References: <4tS4xhEMMPxLcIvzhUws3c3lD7Bv5H87mH46iuuF51s=.54620da5-6b9f-44d1-a15b-aaf5ebee7c74@github.com> Message-ID: On Mon, 22 May 2023 10:59:53 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Test and fix updated as per review comments > > src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2235: > >> 2233: return value == size.value; >> 2234: } >> 2235: return false; > > Is it not enough to compare `value`, `index` and `lu` fields of `FontSize` object? > > > return val instanceof CSS.FontSize size > && value == size.value > && index == size.index > && Objects.equals(lu, size.lu); > > > This implies `LengthUnit` implements `equals` but it does not. In your code, `lu` may be `null` which would cause NPE. > > The following code should handle comparing `LengthUnit`s. > > > return val instanceof CSS.FontSize size > && value == size.value > && index == size.index > && ( (lu == null && size.lu == null) > || (lu != null && size.lu != null > && Objects.equals(lu.units, size.lu.units)); > > > Anyway, parsing the value string does not look good. The current PR passes regression test along with jtreg/jck tests The suggested changes above does not pass the regression test ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1201798308 From martin.pernollet at protonmail.com Tue May 23 10:54:19 2023 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Tue, 23 May 2023 10:54:19 +0000 Subject: JVM hang with Swing and macOS In-Reply-To: <3cbe14ff-8a2f-eabc-6f2c-e5d38ffe1ee6@oracle.com> References: <1108127A-4940-4240-9853-D44F5A16C28F@cbfiddle.com> <7f370680-e1b5-c58a-5e0c-4df79094614a@amazon.com> <409A29DA-FB91-42E2-BF1F-16AB4C793D69@gmail.com> <3Z6cpEUUj9wFPGD38BGfeLvHTD3lnkpOPB8WEcVQDsFZ3-V-a67l9PtQr9-KSQLHA6PtZBbr4tf7ZilUJ1BScR0_OcW6NUFNBVxVnDMhpDE=@protonmail.com> <1C071B5D-9F5C-448E-92E5-7B36F4EC669A@gmail.com> <3cbe14ff-8a2f-eabc-6f2c-e5d38ffe1ee6@oracle.com> Message-ID: Hi Philip, Thank you a lot for these helpful clarifications. You are right, I definitely need to jump on a dedicated OS thread. It is a pity the -XstartOnFirstThread does not do it. We may probably use JOGL's OSXUtil class that does a good job at handling this already. The only limitation is that getting OSXUtil requires depending on all JOGL which additionally requires tweaks to avoid hangs and the like. Regards, Martin ------- Original Message ------- Le mardi 18 avril 2023 ? 19:52, Philip Race a ?crit : > 1) -XstartOnFirstThread should be thought of more as -XdontStartAnEventLoop > And with no event loop running, yes, UI apps hang. > To understand why the option is named as it is, you need to know that on most platforms > and situations the application's "main" method will run on the first thread that is started > But on macOS in order to allow the event loop to run on that thread, it hops over to another > thread that is created. But with this special option, that doesn't happen, so some other code > has a chance to use it for that. > The reason for it is that a toolkit like SWT may come along later and start a loop. > It is possible to check there's already a loop (AWT + JavaFX both do) but perhaps SWT doesn't ? > In summary this option is not (SFAICS) for your use case and that bug is "not a bug" and I've closed it. > > 2) The class referenced by Sergey > > https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/opengl/OGLUtilities.java > > isn't one I know anything about. I can see it pre-dates us even having a macOS port, and its completely > unsupported, probably unsupportable, no idea if it actually works, especially on macOS. > Not sure if its even a direction you should head down. Caveat emptor. Big time. > > 3) JAWT is a JDK native API that lets you use native code to draw into a Java-owned window. > https://docs.oracle.com/en/java/javase/17/docs/specs/AWT_Native_Interface.html > It doesn't provide much more than that. Any rendering that needs to happen on a particular thread > etc is out of scope of what it provides. > > 4) Your error isn't obviously directly opengl related even though it mentions "GLUT". Its more about the toolkit. > > java[92246:2751169] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: NSWindow drag regions should only be invalidated on the Main Thread! > > I would have thought that the advice which I think you need (in this somewhat confusing thread) people > have already offered and this is to jump onto the main thread when needed. > You can look at the code in the JDK's libosxapp/ThreadUtilities.m as a sample to see how you'd do this. > Do not rely on JDK internals. Ultimately you will need to end up using this Apple macOS API - > https://developer.apple.com/documentation/objectivec/nsobject/1414900-performselectoronmainthread > - if you aren't already on the main thread that is. > If there's some complication with that which I'm not understanding, I don't know what you'd do instead. > > I don't have time to look into this any more deeply so this reply must be taken as not fully researched, > but it is the best I can offer you. > > -Phil > > On 3/23/23 4:00 AM, Martin Pernollet wrote: > >>> Start another java process -XstartOnMainThread that does the OpenGL part from a Swing application? >> >> Sorry I do not understand your question. If you speak about triggering two process with -XstartOnFirstThread, I think they might both freeze. Or worse, one freeze and the other one get kick/stopped by the former. >> >> I can try this next week because I do not have a macOS with me up to next thursday. >> >>> One hang up there though might be that I don?t think java applications that include the java native commands are allowed in the Mac App Store. Another bug due to each command has it?s own unique CFBundleIdentifier but that identifier is always the same and Apple doesn?t allow duplicates in the App Store. >> >> Being able to deploy on App Store is not an immediate need for me but this is a very interesting point to consider. I'll try to understand how CFBundleIdentifier relates to -XstartOnFIrstThread. >> >> Regards, >> >> Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Tue May 23 11:25:16 2023 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 23 May 2023 06:25:16 -0500 Subject: JVM hang with Swing and macOS In-Reply-To: References: <1108127A-4940-4240-9853-D44F5A16C28F@cbfiddle.com> <7f370680-e1b5-c58a-5e0c-4df79094614a@amazon.com> <409A29DA-FB91-42E2-BF1F-16AB4C793D69@gmail.com> <3Z6cpEUUj9wFPGD38BGfeLvHTD3lnkpOPB8WEcVQDsFZ3-V-a67l9PtQr9-KSQLHA6PtZBbr4tf7ZilUJ1BScR0_OcW6NUFNBVxVnDMhpDE=@protonmail.com> <1C071B5D-9F5C-448E-92E5-7B36F4EC669A@gmail.com> <3cbe14ff-8a2f-eabc-6f2c-e5d38ffe1ee6@oracle.com> Message-ID: <33917324-84BC-47A3-ABA1-D350EEDAE9A7@gmail.com> > On May 23, 2023, at 5:54 AM, Martin Pernollet wrote: > > Hi Philip, > > Thank you a lot for these helpful clarifications. > > You are right, I definitely need to jump on a dedicated OS thread. It is a pity the -XstartOnFirstThread does not do it. > > We may probably use JOGL's OSXUtil class that does a good job at handling this already. The only limitation is that getting OSXUtil requires depending on all JOGL which additionally requires tweaks to avoid hangs and the like. > > Regards, > > Martin > > > ------- Original Message ------- > Le mardi 18 avril 2023 ? 19:52, Philip Race a ?crit : > Martin, A little strange you are replying to this one from April but not mine from 2 days ago? As I remember there were two show stopper issues. First OS/X OpenGL required -XstartOnFirstThread which didn?t work for Swing applications, and, Apple was discontinuing OpenGL support in favor of their own Metal API?s? In my post I mentioned that using a Mesa offscreen build I was able to run the demo creating an offscreen image and saving it to disk. As I remember your goal was to create an offscreen image and then copy it over to Swing. So, that?s done? I changed the Panama API?s you used from 19 to 20. Which you will have to do sometime? Other than that for OS/X supporting OpenGL api?s going forward for Swing, or probably JavaFX, what is wrong with what I have? Maybe I can fix it. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.pernollet at protonmail.com Tue May 23 14:26:34 2023 From: martin.pernollet at protonmail.com (Martin Pernollet) Date: Tue, 23 May 2023 14:26:34 +0000 Subject: JVM hang with Swing and macOS In-Reply-To: <33917324-84BC-47A3-ABA1-D350EEDAE9A7@gmail.com> References: <409A29DA-FB91-42E2-BF1F-16AB4C793D69@gmail.com> <3Z6cpEUUj9wFPGD38BGfeLvHTD3lnkpOPB8WEcVQDsFZ3-V-a67l9PtQr9-KSQLHA6PtZBbr4tf7ZilUJ1BScR0_OcW6NUFNBVxVnDMhpDE=@protonmail.com> <1C071B5D-9F5C-448E-92E5-7B36F4EC669A@gmail.com> <3cbe14ff-8a2f-eabc-6f2c-e5d38ffe1ee6@oracle.com> <33917324-84BC-47A3-ABA1-D350EEDAE9A7@gmail.com> Message-ID: Yep have been away from java and GL for some time hence answering oldest message first, but don't worry I will answer :) That is awesome if you had MESA working on macOS. I am curious how you solved the issue with library loading. If you bumped PanamaGL from Java 19 to 20 that is awesome. I was about to start this soon but I'd be glad to rather review your work through a PR on the gitlab projects. The more people able to commit to this code base, the best for this project. I'll answer more in depth to your recent message. Thank you a lot. ------- Original Message ------- Le mardi 23 mai 2023 ? 13:25, Michael Hall a ?crit : >> On May 23, 2023, at 5:54 AM, Martin Pernollet wrote: >> >> Hi Philip, >> >> Thank you a lot for these helpful clarifications. >> >> You are right, I definitely need to jump on a dedicated OS thread. It is a pity the -XstartOnFirstThread does not do it. >> >> We may probably use JOGL's OSXUtil class that does a good job at handling this already. The only limitation is that getting OSXUtil requires depending on all JOGL which additionally requires tweaks to avoid hangs and the like. >> >> Regards, >> >> Martin >> >> ------- Original Message ------- >> Le mardi 18 avril 2023 ? 19:52, Philip Race a ?crit : > > Martin, > > A little strange you are replying to this one from April but not mine from 2 days ago? > > As I remember there were two show stopper issues. First OS/X OpenGL required -XstartOnFirstThread which didn?t work for Swing applications, and, Apple was discontinuing OpenGL support in favor of their own Metal API?s? > > In my post I mentioned that using a Mesa offscreen build I was able to run the demo creating an offscreen image and saving it to disk. > > As I remember your goal was to create an offscreen image and then copy it over to Swing. So, that?s done? > > I changed the Panama API?s you used from 19 to 20. Which you will have to do sometime? > > Other than that for OS/X supporting OpenGL api?s going forward for Swing, or probably JavaFX, what is wrong with what I have? Maybe I can fix it. > > Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From aivanov at openjdk.org Tue May 23 15:13:30 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 23 May 2023 15:13:30 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v8] In-Reply-To: References: <4tS4xhEMMPxLcIvzhUws3c3lD7Bv5H87mH46iuuF51s=.54620da5-6b9f-44d1-a15b-aaf5ebee7c74@github.com> Message-ID: On Tue, 23 May 2023 08:32:53 GMT, Prasanta Sadhukhan wrote: > The current PR passes regression test along with jtreg/jck tests > The suggested changes above does not pass the regression test I haven't tested the code above, I wrote it off the top of my head right here. Anyway passing tests are a good baseline. Yet I am strongly against parsing the CSS string in `equals`, it has *already* been parsed. I'll get to it later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1202100159 From tr at openjdk.org Tue May 23 15:13:27 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 23 May 2023 15:13:27 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v4] In-Reply-To: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: <0T3k_H4tn9i-W8kmOGDMD-4gCGxoF5dOFCyKdHi-pg0=.78c652dd-3820-4230-bdb3-e0ef1e326a32@github.com> > This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. > The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13998/files - new: https://git.openjdk.org/jdk/pull/13998/files/5a791d0b..94798c3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=02-03 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13998/head:pull/13998 PR: https://git.openjdk.org/jdk/pull/13998 From azvegint at openjdk.org Tue May 23 15:15:29 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 23 May 2023 15:15:29 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v6] In-Reply-To: References: Message-ID: <3QEJBac8UZLkHTYjJKcCSyMleMK8iV1Dvlzwo9NXvwM=.e132b4cb-fb07-4503-bc9b-59129c9e360b@github.com> > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: awt.robot.screenshotMethod -> awt.robot.screenshotMethod, awt.robot.screencastDebug -> awt.robot.screenshotDebug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/53de29bf..c077dc7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=04-05 Stats: 16 lines in 2 files changed: 5 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From azvegint at openjdk.org Tue May 23 15:16:08 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 23 May 2023 15:16:08 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v5] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 22:34:17 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > Call loadGtk when awt.robot.gtk set to false The system properties have been renamed: `awt.robot.screenshotMethod` -> `awt.robot.screenshotMethod` `awt.robot.screencastDebug` -> `awt.robot.screenshotDebug` `awt.robot.screenshotMethod` - `dbusScreencast` defaults to Wayland session, `x11` defaults to X11 session, and to all other values except `dbusScreencast`. Note

    1. setting this to `x11` in a Wayland session means screen capture will always fail, as it does in earlier JDKs
    2. setting this to `dbusScreencast` in an X.org session should work but is only recommended for JDK debugging purposes
    3. The already existing `awt.robot.gtk` option is only valid for `x11` and has no effect for `dbusScreencast`.
    `awt.robot.screenshotDebug` - `false` by default, if `true` prints debug information related if any available. This may be needed for a smoother experience when we later want to get a screenshot via [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-Screenshot.Screenshot). (it requires Gnome 43+, Ubuntu 22.04 LTS has 42.5). So we can add `dbusScreenshot` option for the `awt.robot.screenshotMethod` later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1559507625 From psadhukhan at openjdk.org Tue May 23 16:44:20 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 23 May 2023 16:44:20 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v10] In-Reply-To: References: Message-ID: > Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. > In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. > Fixed by implementing the equality and hashCode method for CSS.FontSize class. > > All jtreg/jck tests are ok Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Optimize fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13405/files - new: https://git.openjdk.org/jdk/pull/13405/files/745fe232..423c1169 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=08-09 Stats: 17 lines in 1 file changed: 1 ins; 12 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13405/head:pull/13405 PR: https://git.openjdk.org/jdk/pull/13405 From dcubed at openjdk.org Tue May 23 20:48:16 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 23 May 2023 20:48:16 GMT Subject: Integrated: 8308716: ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64 Message-ID: Trivial fixes to ProblemList some tests: [JDK-8308716](https://bugs.openjdk.org/browse/JDK-8308716) ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64 [JDK-8308718](https://bugs.openjdk.org/browse/JDK-8308718) ProblemList three mlvm/indy/func/jvmti tests on windows-x64 in Xcomp mode [JDK-8308720](https://bugs.openjdk.org/browse/JDK-8308720) ProblemList java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java on macosx-x64 ------------- Commit messages: - 8308720: ProblemList java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java on macosx-x64 - 8308718: ProblemList three mlvm/indy/func/jvmti tests on windows-x64 in Xcomp mode - 8308716: ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64 Changes: https://git.openjdk.org/jdk/pull/14106/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14106&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308716 Stats: 6 lines in 3 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14106.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14106/head:pull/14106 PR: https://git.openjdk.org/jdk/pull/14106 From azvegint at openjdk.org Tue May 23 20:48:16 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 23 May 2023 20:48:16 GMT Subject: Integrated: 8308716: ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64 In-Reply-To: References: Message-ID: On Tue, 23 May 2023 20:24:18 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList some tests: > [JDK-8308716](https://bugs.openjdk.org/browse/JDK-8308716) ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64 > [JDK-8308718](https://bugs.openjdk.org/browse/JDK-8308718) ProblemList three mlvm/indy/func/jvmti tests on windows-x64 in Xcomp mode > [JDK-8308720](https://bugs.openjdk.org/browse/JDK-8308720) ProblemList java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java on macosx-x64 Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14106#pullrequestreview-1440533061 From darcy at openjdk.org Tue May 23 20:48:17 2023 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 23 May 2023 20:48:17 GMT Subject: Integrated: 8308716: ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64 In-Reply-To: References: Message-ID: On Tue, 23 May 2023 20:24:18 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList some tests: > [JDK-8308716](https://bugs.openjdk.org/browse/JDK-8308716) ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64 > [JDK-8308718](https://bugs.openjdk.org/browse/JDK-8308718) ProblemList three mlvm/indy/func/jvmti tests on windows-x64 in Xcomp mode > [JDK-8308720](https://bugs.openjdk.org/browse/JDK-8308720) ProblemList java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java on macosx-x64 Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14106#pullrequestreview-1440535048 From dcubed at openjdk.org Tue May 23 20:48:17 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 23 May 2023 20:48:17 GMT Subject: Integrated: 8308716: ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64 In-Reply-To: References: Message-ID: On Tue, 23 May 2023 20:39:02 GMT, Alexander Zvegintsev wrote: >> Trivial fixes to ProblemList some tests: >> [JDK-8308716](https://bugs.openjdk.org/browse/JDK-8308716) ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64 >> [JDK-8308718](https://bugs.openjdk.org/browse/JDK-8308718) ProblemList three mlvm/indy/func/jvmti tests on windows-x64 in Xcomp mode >> [JDK-8308720](https://bugs.openjdk.org/browse/JDK-8308720) ProblemList java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java on macosx-x64 > > Marked as reviewed by azvegint (Reviewer). @azvegint and @jddarcy - Thanks for the fast reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14106#issuecomment-1560097131 From dcubed at openjdk.org Tue May 23 20:48:18 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 23 May 2023 20:48:18 GMT Subject: Integrated: 8308716: ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64 In-Reply-To: References: Message-ID: On Tue, 23 May 2023 20:24:18 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList some tests: > [JDK-8308716](https://bugs.openjdk.org/browse/JDK-8308716) ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64 > [JDK-8308718](https://bugs.openjdk.org/browse/JDK-8308718) ProblemList three mlvm/indy/func/jvmti tests on windows-x64 in Xcomp mode > [JDK-8308720](https://bugs.openjdk.org/browse/JDK-8308720) ProblemList java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java on macosx-x64 This pull request has now been integrated. Changeset: ed0e956f Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/ed0e956fc28a54a0eb49bab70a7d010095ce2544 Stats: 6 lines in 3 files changed: 6 ins; 0 del; 0 mod 8308716: ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64 8308718: ProblemList three mlvm/indy/func/jvmti tests on windows-x64 in Xcomp mode 8308720: ProblemList java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java on macosx-x64 Reviewed-by: azvegint, darcy ------------- PR: https://git.openjdk.org/jdk/pull/14106 From serb at openjdk.org Wed May 24 02:54:07 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 May 2023 02:54:07 GMT Subject: RFR: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11 sessions [v6] In-Reply-To: References: Message-ID: <2OVjbGwSZ2_6q-SCG8cSfXbi0K4kBOVVzeYkJAnHLsc=.fb2d86d8-80d0-4455-ab3e-bdfe591673d3@github.com> On Thu, 4 May 2023 08:06:11 GMT, Maxim Kartashev wrote: >> Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish. >> >> On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration. >> >> A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year. > > Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision: > > Double-checked locking for insets and less synchronization for bounds The latest version looks fine. ------------- Marked as reviewed by serb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13346#pullrequestreview-1440858185 From serb at openjdk.org Wed May 24 02:59:12 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 May 2023 02:59:12 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v13] In-Reply-To: References: Message-ID: <303MmiaIkgVNj2mw4slnzlP0afCZnrfeUjV92g8G8vA=.00bcdd47-eb08-430f-aee7-f9bcfa0dd21a@github.com> On Mon, 22 May 2023 14:36:08 GMT, Tejesh R wrote: >> Open source few AWT ScrollPane related tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments test/jdk/java/awt/ScrollPane/ScrollPositionIntact.java line 91: > 89: int i = (int) (sp.getScrollPosition().getX()); > 90: if (i == 0) { > 91: // actual position MAY be not equal to X_POS; still, it must be > 0. If the valid value is "> 0" only, then we should throw an exception if the value is "<=0" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1203340563 From serb at openjdk.org Wed May 24 03:03:59 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 May 2023 03:03:59 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v4] In-Reply-To: References: Message-ID: On Fri, 12 May 2023 05:32:14 GMT, Tejesh R wrote: >> Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 30: > 28: @summary Checks that popup menu stay open after a triggering click. > 29: @key headful > 30: @run main/othervm -Dsun.java2d.uiScale=1 PopupMenuStayOpen Why do you need to set uiscale=1 in this test? test/jdk/java/awt/Robot/RobotMoveMultiscreen.java line 82: > 80: robot.waitForIdle(); > 81: > 82: if (testCondition == false) { testCondition is set on EDT and used on the main thread here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1203342226 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1203342735 From serb at openjdk.org Wed May 24 03:04:01 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 May 2023 03:04:01 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v4] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 17:57:33 GMT, Phil Race wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/java/awt/Scrollbar/ScrollbarKeyControlTest.java line 61: > >> 59: System.out.println("This test is for XAWT only."); >> 60: return; >> 61: } > > This is largely pointless since you have requires os==linux. > Perhaps its from when we had MToolkit. > If you keep it, then I'd make it just check the "os.name" and not the toolkit Does this test work on mac or windows? if not any reason why? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1203343990 From kbarrett at openjdk.org Wed May 24 03:16:04 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 24 May 2023 03:16:04 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> Message-ID: On Mon, 22 May 2023 07:09:30 GMT, JoKern65 wrote: >> The final suggested change (to direct-value-initialize the object) seems to have *not* been made. >> >> However, I think it doesn't matter. The mentioned restriction against being non-empty until C23 is not relevant. >> This is C++, not C. Empty initializers are, and have always been, permitted by C++. > > Strange the last resulting change I see is > `struct shmid_ds shm_buf{};` That's not what I see in this PR, and not what I see in the repository after the integration. Where are you seeing that? (If in your local repository, maybe you forgot a push to the PR?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1203353066 From tr at openjdk.org Wed May 24 03:27:55 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 24 May 2023 03:27:55 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v4] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 02:58:54 GMT, Sergey Bylokhov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 30: > >> 28: @summary Checks that popup menu stay open after a triggering click. >> 29: @key headful >> 30: @run main/othervm -Dsun.java2d.uiScale=1 PopupMenuStayOpen > > Why do you need to set uiscale=1 in this test? If the uiscale is not set then the position of popup menu varies according to display screen, like may not be always from bottom-left of cursor (when mouse click happens). Since we are only open sourcing the test, so had to set the scale to 1 so that it passes in all conditions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1203361682 From tr at openjdk.org Wed May 24 03:43:08 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 24 May 2023 03:43:08 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v14] In-Reply-To: References: Message-ID: > Open source few AWT ScrollPane related tests. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13621/files - new: https://git.openjdk.org/jdk/pull/13621/files/84c0961c..bdda9760 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13621&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13621/head:pull/13621 PR: https://git.openjdk.org/jdk/pull/13621 From tr at openjdk.org Wed May 24 03:43:11 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 24 May 2023 03:43:11 GMT Subject: RFR: 8306137: Open source several AWT ScrollPane related tests [v13] In-Reply-To: <303MmiaIkgVNj2mw4slnzlP0afCZnrfeUjV92g8G8vA=.00bcdd47-eb08-430f-aee7-f9bcfa0dd21a@github.com> References: <303MmiaIkgVNj2mw4slnzlP0afCZnrfeUjV92g8G8vA=.00bcdd47-eb08-430f-aee7-f9bcfa0dd21a@github.com> Message-ID: On Wed, 24 May 2023 02:56:30 GMT, Sergey Bylokhov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/java/awt/ScrollPane/ScrollPositionIntact.java line 91: > >> 89: int i = (int) (sp.getScrollPosition().getX()); >> 90: if (i == 0) { >> 91: // actual position MAY be not equal to X_POS; still, it must be > 0. > > If the valid value is "> 0" only, then we should throw an exception if the value is "<=0" Yes, right. Updated the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13621#discussion_r1203369592 From tr at openjdk.org Wed May 24 03:45:50 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 24 May 2023 03:45:50 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v5] In-Reply-To: References: Message-ID: > Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13828/files - new: https://git.openjdk.org/jdk/pull/13828/files/c102c912..bb9356ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13828&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13828&range=03-04 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13828.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13828/head:pull/13828 PR: https://git.openjdk.org/jdk/pull/13828 From tr at openjdk.org Wed May 24 03:45:53 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 24 May 2023 03:45:53 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v4] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 02:59:39 GMT, Sergey Bylokhov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/java/awt/Robot/RobotMoveMultiscreen.java line 82: > >> 80: robot.waitForIdle(); >> 81: >> 82: if (testCondition == false) { > > testCondition is set on EDT and used on the main thread here. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1203373245 From duke at openjdk.org Wed May 24 07:29:57 2023 From: duke at openjdk.org (lawrence.andrews) Date: Wed, 24 May 2023 07:29:57 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame Message-ID: 1) Used builder pattern 2) Tested AWT tests and it passed ------------- Commit messages: - minor changes - Used builder pattern for PassFailJFrame.java - Merge branch 'master' into PassFailJFrame_Screen_Shot - Fixed review comments - Added screen shot functionality to PassFailJFrame.java Changes: https://git.openjdk.org/jdk/pull/14094/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14094&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294535 Stats: 212 lines in 3 files changed: 205 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/14094.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14094/head:pull/14094 PR: https://git.openjdk.org/jdk/pull/14094 From psadhukhan at openjdk.org Wed May 24 09:09:27 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 24 May 2023 09:09:27 GMT Subject: RFR: 8306119: Many components respond to a mouse event by requesting focus without supplying the MOUSE_EVENT cause [v2] In-Reply-To: References: Message-ID: <9lTwYTVoCdyGRJbOibcn4LyjKIXYimyByRVzAeOE0Z0=.c76d0cea-3cfb-4bb8-9725-cf53fea109fe@github.com> > Many Swing components request a focus transfer in response to a mouse event, but fail to supply a Cause when requesting focus. A focus event listener will find the cause to be UNKNOWN, but MOUSE_EVENT would be more appropriate. > Fixed by adding MOUSE_EVENT cause to requestFocus() when it is called for mouse events... > > All jtreg/jck tests are ok.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14004/files - new: https://git.openjdk.org/jdk/pull/14004/files/2c11ea27..1118436f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14004&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14004&range=00-01 Stats: 103 lines in 1 file changed: 103 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14004.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14004/head:pull/14004 PR: https://git.openjdk.org/jdk/pull/14004 From psadhukhan at openjdk.org Wed May 24 10:41:09 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 24 May 2023 10:41:09 GMT Subject: RFR: 8306119: Many components respond to a mouse event by requesting focus without supplying the MOUSE_EVENT cause [v3] In-Reply-To: References: Message-ID: > Many Swing components request a focus transfer in response to a mouse event, but fail to supply a Cause when requesting focus. A focus event listener will find the cause to be UNKNOWN, but MOUSE_EVENT would be more appropriate. > Fixed by adding MOUSE_EVENT cause to requestFocus() when it is called for mouse events... > > All jtreg/jck tests are ok.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: test fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14004/files - new: https://git.openjdk.org/jdk/pull/14004/files/1118436f..ee4afbbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14004&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14004&range=01-02 Stats: 10 lines in 1 file changed: 0 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/14004.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14004/head:pull/14004 PR: https://git.openjdk.org/jdk/pull/14004 From psadhukhan at openjdk.org Wed May 24 12:05:03 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 24 May 2023 12:05:03 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v8] In-Reply-To: References: <4tS4xhEMMPxLcIvzhUws3c3lD7Bv5H87mH46iuuF51s=.54620da5-6b9f-44d1-a15b-aaf5ebee7c74@github.com> Message-ID: On Tue, 23 May 2023 11:12:16 GMT, Alexey Ivanov wrote: >> The current PR passes regression test along with jtreg/jck tests >> The suggested changes above does not pass the regression test > >> The current PR passes regression test along with jtreg/jck tests >> The suggested changes above does not pass the regression test > > I haven't tested the code above, I wrote it off the top of my head right here. Anyway passing tests are a good baseline. > > Yet I am strongly against parsing the CSS string in `equals`, it has *already* been parsed. I'll get to it later. Fix is optimized w.r.t parsing.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1203990354 From mkartashev at openjdk.org Wed May 24 12:52:07 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Wed, 24 May 2023 12:52:07 GMT Subject: Integrated: 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11 sessions In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 08:19:50 GMT, Maxim Kartashev wrote: > Getting bounds of a `GraphicsDevice` and insets of a screen are fairly frequent operations. When working over the network (remote X session), those can take several *seconds* to complete, introducing repeated freezes even when typing in an editor feels only slightly sluggish. > > On the other hand, neither bounds nor insets change very often - if at all - during the lifetime of an application. So caching their values seems like a natural solution to the problem. The caches need to be reset only when there's a possibility of change in the screens configuration. > > A similar patch has been living in [JetBrains Runtime](https://github.com/JetBrains/JetBrainsRuntime/) for well over a year. This pull request has now been integrated. Changeset: d7245f70 Author: Maxim Kartashev Committer: Alexey Ushakov URL: https://git.openjdk.org/jdk/commit/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2 Stats: 59 lines in 2 files changed: 54 ins; 1 del; 4 mod 8305578: X11GraphicsDevice.pGetBounds() is slow in remote X11 sessions Reviewed-by: avu, serb ------------- PR: https://git.openjdk.org/jdk/pull/13346 From jwaters at openjdk.org Wed May 24 14:04:03 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 24 May 2023 14:04:03 GMT Subject: RFR: 8308780: Fix the Java Integer types on Windows Message-ID: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code ------------- Commit messages: - Fix the Java Integer types on Windows Changes: https://git.openjdk.org/jdk/pull/14125/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308780 Stats: 24 lines in 11 files changed: 0 ins; 5 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/14125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125 PR: https://git.openjdk.org/jdk/pull/14125 From aivanov at openjdk.org Wed May 24 14:20:58 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 May 2023 14:20:58 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> Message-ID: <9CYm1ES0qMrb-t6K6q6xWqB9SK8TmF91Mg7Ccp-euB4=.18b0c646-55d5-4daa-93d0-476045e65d68@github.com> On Mon, 22 May 2023 16:07:30 GMT, Tejesh R wrote: >> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 725: >> >>> 723: || (chooser.isDirectorySelectionEnabled() >>> 724: && (fsv.isFileSystem(f) >>> 725: || (fsv.isLink(f) && Files.isSymbolicLink(f.toPath()))) >> >> I don't think it's correct. >> >> `Files.isSymbolicLink` should only be called for objects for which `fsv.isFileSystem(f)` returns `true`. >> >> `fsv.isLink(f)` returns `true` for `.lnk` files which are the common Windows shortcuts; such a file can also be a symbolic link. > > `Files.isSymbolicLink` takes path as argument to check if its a symbolic link. For certain windows specific files as explained the path won't be exact path, rather a hex values. So directly validating with path is causing an exception. So `fsv.isLink()` is used as a first level validation which uses File to check if its valid. I didn't find any other alternatives to validate the file path, so used `fsv.isLink` as first level validation along with Symbolic Link check. I understand that, virtual folders don't have a filesystem path, this is why `fsv.isFileSystem(f)` should handle this situation. The implementation of `FileSystemView.isFileSystem` explicitly excludes such files which are both `isLink` and `isDirectory`: https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java#L382-L388 Let's look deeper: https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L591-L597 https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L860-L866 The `hasAttribute` method uses `getAttributes0` which calls [`IShellFolder::GetAttributesOf`](https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-ishellfolder-getattributesof) which returns [`SFGAO`](https://learn.microsoft.com/en-us/windows/win32/shell/sfgao). The attribute `SFGAO_LINK` which corresponds to `ATTRIB_LINK` in Java is described as _?The specified items are shortcuts.?_ That is it is a shell folder shortcut with `.lnk` file extension, which used to be the case. However, now this attribute is set for both [_symbolic links_](https://learn.microsoft.com/en-us/windows/win32/fileio/creating-symbolic-links) and [_junctions_](https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions#junctions). Here's what different methods return: file: C:\test\symbolic-links\jdk - junction isFileSystem false isLink true isDirectory true isSymbolicLink false Absolute Path : null file: C:\test\symbolic-links\jdk - symbolic isFileSystem false isLink true isDirectory true isSymbolicLink true Absolute Path : C:\test\symbolic-links\jdk - symbolic file: C:\test\symbolic-links\jdk - shortcut.lnk isFileSystem false isLink true isDirectory true isSymbolicLink false Absolute Path : null In the three cases above, `isFileSystem` returns `false` even though all the three objects point to a filesystem directory, the first two are fully transparent for apps whereas the `.lnk` shortcut needs special handling. If `JFileChooser` is in directory-only mode, selecting a junction or `.lnk` file results in selected file being to `null`; symbolic links are supported with your fix. So, **I propose modifying the implementation of `FileSystemView.isFileSystem`** so that it returns only `sf.isFileSystem()` or filters out the `.lnk` shortcuts only. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1204238269 From jiangli at openjdk.org Wed May 24 15:01:01 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 24 May 2023 15:01:01 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79. > > I ran this patch in our internal build and test system and got failures on macos and windows. I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in. > > > [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error > [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data > [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed > [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1 Hi @erikj79 Please let me know if you have any additional comments for the PR. Could you please also help run through testing for the latest version? Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561320098 From aivanov at openjdk.org Wed May 24 15:50:58 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 May 2023 15:50:58 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: <9CYm1ES0qMrb-t6K6q6xWqB9SK8TmF91Mg7Ccp-euB4=.18b0c646-55d5-4daa-93d0-476045e65d68@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> <9CYm1ES0qMrb-t6K6q6xWqB9SK8TmF91Mg7Ccp-euB4=.18b0c646-55d5-4daa-93d0-476045e65d68@github.com> Message-ID: On Wed, 24 May 2023 14:18:02 GMT, Alexey Ivanov wrote: >> `Files.isSymbolicLink` takes path as argument to check if its a symbolic link. For certain windows specific files as explained the path won't be exact path, rather a hex values. So directly validating with path is causing an exception. So `fsv.isLink()` is used as a first level validation which uses File to check if its valid. I didn't find any other alternatives to validate the file path, so used `fsv.isLink` as first level validation along with Symbolic Link check. > > I understand that, virtual folders don't have a filesystem path, this is why `fsv.isFileSystem(f)` should handle this situation. The implementation of `FileSystemView.isFileSystem` explicitly excludes such files which are both `isLink` and `isDirectory`: > https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java#L382-L388 > > Let's look deeper: > https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L591-L597 > > https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L860-L866 > > The `hasAttribute` method uses `getAttributes0` which calls [`IShellFolder::GetAttributesOf`](https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-ishellfolder-getattributesof) which returns [`SFGAO`](https://learn.microsoft.com/en-us/windows/win32/shell/sfgao). The attribute `SFGAO_LINK` which corresponds to `ATTRIB_LINK` in Java is described as _?The specified items are shortcuts.?_ That is it is a shell folder shortcut with `.lnk` file extension, which used to be the case. > > However, now this attribute is set for both [_symbolic links_](https://learn.microsoft.com/en-us/windows/win32/fileio/creating-symbolic-links) and [_junctions_](https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions#junctions). > > Here's what different methods return: > > file: C:\test\symbolic-links\jdk - junction > isFileSystem false > isLink true > isDirectory true > isSymbolicLink false > Absolute Path : null > > file: C:\test\symbolic-links\jdk - symbolic > isFileSystem false > isLink true > isDirectory true > isSymbolicLink true > Absolute Path : C:\test\symbolic-links\jdk - symbolic > > file: C:\test\symbolic-links\jdk - shortcut.lnk > isFileSystem false > isLink true > isDirectory true > isSymbolicLink false > Absolute Path : null > > > In the three cases above, `isFileSystem` returns `false` even though all the three objects point to a filesystem directory, the first two are fully transparent for apps whereas the `.lnk` shortcut needs special handling. > > If `JFileChooser` is in directory-only mode, selecting a junction or `.lnk` file results in selected file being to `null`; symbolic links are supported with your fix. > > So, **I propose mod... Handling `.lnk` files on Windows doesn't seem right: `JFileChooser` allows selecting such a file. * If it's a shortcut to a directory, clicking Open in the file chooser or double-clicking it in the list navigates to the target. * If it's a shortcut to a regular file, `JFileChooser` returns this file which isn't helpful, it's not what the user usually wants, the target of the shortcut should be returned. This is what happens if the user selects a shortcut file (`.lnk`) in the native file chooser. In addition to that, the shortcuts are filtered based on the file types. For example, if select the *Open* command in Notepad, the file chooser shows only shortcuts to `.txt` files (as well as `.txt` files), it hides shortcuts to other file types. But `JFileChooser` doesn't show `.lnk` files at all if an extension filter is set. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1204423861 From rmahajan at openjdk.org Wed May 24 18:46:13 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Wed, 24 May 2023 18:46:13 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v3] In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: > Problem: > > Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: > > - Scrawly ticks in checkboxes; > - Wrong circle relations in selected radio buttons. > > Root-cause: > We open theme on AWT Toolkit Window which always has Primary Monitor DPI. > Due to this when the app window goes to Secondary Screen with different DPI UI buttons > appear incorrectly rendered. > Following is a list proposed changes to fix this issue. > > > Proposed Fix with Summary of changes: > > 1. Open a new Theme Handle per the DPI of the Screen where the App window is. > --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. > window is. > > 2. GetPartSize() of icons returns size based on standard size = 96 DPI. > --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. > > 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. > -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. > > 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. > --> This helps make sure that for .25s scaling we get better rendering. > This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. > > As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. > > > Testing: > > Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. > > ___________________________________ > Monitor 1 | Monitor 2 > (Primary) | > | > 125% | 175% > 150% | 175% > 150% | 225% > 175% | 175% > 175% | 150% > 175% | 225% > _____________________ |_____________ > > Also tested on setup with scaling values of up-to 350%. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: changes suggested in code review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13701/files - new: https://git.openjdk.org/jdk/pull/13701/files/60839780..179faf6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=01-02 Stats: 10 lines in 1 file changed: 2 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13701.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701 PR: https://git.openjdk.org/jdk/pull/13701 From rmahajan at openjdk.org Wed May 24 18:55:35 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Wed, 24 May 2023 18:55:35 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v4] In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: > Problem: > > Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: > > - Scrawly ticks in checkboxes; > - Wrong circle relations in selected radio buttons. > > Root-cause: > We open theme on AWT Toolkit Window which always has Primary Monitor DPI. > Due to this when the app window goes to Secondary Screen with different DPI UI buttons > appear incorrectly rendered. > Following is a list proposed changes to fix this issue. > > > Proposed Fix with Summary of changes: > > 1. Open a new Theme Handle per the DPI of the Screen where the App window is. > --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. > window is. > > 2. GetPartSize() of icons returns size based on standard size = 96 DPI. > --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. > > 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. > -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. > > 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. > --> This helps make sure that for .25s scaling we get better rendering. > This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. > > As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. > > > Testing: > > Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. > > ___________________________________ > Monitor 1 | Monitor 2 > (Primary) | > | > 125% | 175% > 150% | 175% > 150% | 225% > 175% | 175% > 175% | 150% > 175% | 225% > _____________________ |_____________ > > Also tested on setup with scaling values of up-to 350%. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: Update src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13701/files - new: https://git.openjdk.org/jdk/pull/13701/files/179faf6a..00ce4978 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13701.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701 PR: https://git.openjdk.org/jdk/pull/13701 From dnguyen at openjdk.org Wed May 24 19:08:55 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 24 May 2023 19:08:55 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: References: Message-ID: On Tue, 23 May 2023 02:52:03 GMT, lawrence.andrews wrote: > 1) Used builder pattern > 2) Tested AWT tests and it passed I looked at the JBS issue and this PR's description but when I look at the changes, there are changes to tests as well, like the awt TrayIcon one. Is that meant to be included? Or is that a separate change that accidentally got bundled with this change to PassFailJFrame? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14094#issuecomment-1561787957 From erikj at openjdk.org Wed May 24 19:16:58 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 24 May 2023 19:16:58 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: <4DLj_HAFFpv2ZhVaat71afM_xf3BPQ9sRW0FQOcRfr4=.8aac858e-55a9-4ed1-b397-ef84e73af2cc@github.com> On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79. > > I ran this patch in our internal build and test system and got failures on macos and windows. I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in. > > > [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error > [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data > [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed > [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1 > Hi @erikj79 Please let me know if you have any additional comments for the PR. Could you please also help run through testing for the latest version? Thanks I'm running a full set of builds now, but in my initial local build on mac, I see a lot of warnings like this: .../Xcode/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/libc++.tbd, ignoring unexpected dylib text stub file Any idea what that could be caused by or if it's possible to eliminate? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561798109 From aivanov at openjdk.org Wed May 24 19:17:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 May 2023 19:17:56 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: References: Message-ID: On Wed, 24 May 2023 19:06:06 GMT, Damon Nguyen wrote: > I looked at the JBS issue and this PR's description but when I look at the changes, there are changes to tests as well, like the awt TrayIcon one. Is that meant to be included? Or is that a separate change that accidentally got bundled with this change to PassFailJFrame? I believe this is intended to demonstrate the usage of the screenshot feature. Yet it may be a hindrance for backporting? if the modified tests don't exist in previous versions or there are other differences? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14094#issuecomment-1561798444 From aivanov at openjdk.org Wed May 24 19:45:01 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 May 2023 19:45:01 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: References: Message-ID: <9fZwcg7-Tdm7naKW5dPxJAFPdcTKso35SVV7tHz-jQU=.04193ab7-23d2-4cf6-8f0d-788dad78b57d@github.com> On Tue, 23 May 2023 02:52:03 GMT, lawrence.andrews wrote: > 1) Used builder pattern > 2) Tested AWT tests and it passed I really like your idea with *builder pattern* for creating `PassFailJFrame`. Well done! Is the purpose of screenshot in `PrintLatinCJKTest` to capture how the printed document looks in a PDF viewer? @honkar-jdk could you take a look? You've been involved in early development and updating of the manual testing framework, and you've used it extensively. test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 271: > 269: } catch (AWTException e) { > 270: String errorMsg = "Failed to create the " + > 271: "instance of Robot."; Suggestion: String errorMsg = "Failed to create an " + "instance of Robot."; Maybe make it a constant? Or wrap the entire string to avoid breaking it? Suggestion: String errorMsg = "Failed to create an instance of Robot."; test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 281: > 279: List imageList = > 280: multiResolutionImage.getResolutionVariants(); > 281: Image image = imageList.get(imageList.size() - 1); Suggestion: MultiResolutionImage mri = robot.createMultiResolutionScreenCapture(bounds); List imageList = mri.getResolutionVariants(); Image image = imageList.get(imageList.size() - 1); `mri` is a common abbreviation of `MultiResolutionImage`, it's much shorter. Alternatively, you may inline the two calls: Suggestion: List imageList = robot.createMultiResolutionScreenCapture(bounds) .getResolutionVariants(); Image image = imageList.get(imageList.size() - 1); test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 287: > 285: ImageIO.write((RenderedImage) image, "png", file); > 286: } catch (IOException e) { > 287: throw new RuntimeException(e.getMessage()); You shouldn't throw away the original exception, it may be useful in diagnosing the problem. Suggestion: throw new RuntimeException(e); Show message to the user? Or, add a try-catch inside `captureScreen` to show this message. test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 297: > 295: .map(GraphicsDevice::getDefaultConfiguration) > 296: .map(GraphicsConfiguration::getBounds) > 297: .forEach(PassFailJFrame::captureScreen); Suggestion: Arrays.stream(GraphicsEnvironment.getLocalGraphicsEnvironment() .getScreenDevices()) .map(GraphicsDevice::getDefaultConfiguration) .map(GraphicsConfiguration::getBounds) .forEach(PassFailJFrame::captureScreen); Align the dots of the chained calls, which is especially important for `getScreenDevices` where it's called on the result of `getLocalGraphicsEnvironment()` so that the stream is created on `getScreenDevices`. test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 304: > 302: .filter(Window::isShowing) > 303: .map(Window::getBounds) > 304: .forEach(PassFailJFrame::captureScreen); Suggestion: windowList.stream() .filter(Window::isShowing) .map(Window::getBounds) .forEach(PassFailJFrame::captureScreen); Align the dots for wrapped calls. test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 306: > 304: .forEach(PassFailJFrame::captureScreen); > 305: } > 306: Maybe use `switch` statement with a `default` case which throws an exception rather than shows success message. (`if else if else` will also do.) Yeah, it's a private method yet it's better to handle an unexpected value. test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 309: > 307: JOptionPane.showMessageDialog(frame, "Screen Captured " + > 308: "Successfully", "Screen Capture", > 309: JOptionPane.INFORMATION_MESSAGE); Suggestion: JOptionPane.showMessageDialog(frame, "Screen captured successfully", "Screen Capture", JOptionPane.INFORMATION_MESSAGE); It's better not to split strings unnecessarily. The messages usually use regular capitalisation as opposed to title capitalisation. test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 601: > 599: if (this.instructions == null || this.instructions.length() == 0) { > 600: throw new RuntimeException("Please provide the test " + > 601: "instruction for this manual test"); Is `IllegalStateException` or `IllegalArgumentException` better than a generic `RuntimeException`? ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14094#pullrequestreview-1442592961 PR Comment: https://git.openjdk.org/jdk/pull/14094#issuecomment-1561829381 PR Review Comment: https://git.openjdk.org/jdk/pull/14094#discussion_r1204655826 PR Review Comment: https://git.openjdk.org/jdk/pull/14094#discussion_r1204659400 PR Review Comment: https://git.openjdk.org/jdk/pull/14094#discussion_r1204662983 PR Review Comment: https://git.openjdk.org/jdk/pull/14094#discussion_r1204665042 PR Review Comment: https://git.openjdk.org/jdk/pull/14094#discussion_r1204665704 PR Review Comment: https://git.openjdk.org/jdk/pull/14094#discussion_r1204667803 PR Review Comment: https://git.openjdk.org/jdk/pull/14094#discussion_r1204669333 PR Review Comment: https://git.openjdk.org/jdk/pull/14094#discussion_r1204670709 From aivanov at openjdk.org Wed May 24 19:55:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 May 2023 19:55:56 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: References: Message-ID: On Wed, 24 May 2023 19:14:56 GMT, Alexey Ivanov wrote: > Yet it may be a hindrance for backporting? if the modified tests don't exist in previous versions or there are other differences? To facilitate backporting, this PR may be broken into two PRs: the first one which updates the API of `PassFailJFrame`, the second, dependent, PR updates the tests. I faced some difficulties when I was backporting `PassFailJFrame` to 17u and 11u because some changes to the framework were combined with tests. The `PrintLatinCJKTest` test that is modified here isn't backported to 17u or 11u. I will definitely want to backport these changes to previous versions of JDK, so I am for *splitting the PR*. Thank you, @DamonGuy, for bringing this up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14094#issuecomment-1561843925 From aivanov at openjdk.org Wed May 24 20:16:03 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 24 May 2023 20:16:03 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v4] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Wed, 24 May 2023 18:55:35 GMT, Rajat Mahajan wrote: >> Problem: >> >> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: >> >> - Scrawly ticks in checkboxes; >> - Wrong circle relations in selected radio buttons. >> >> Root-cause: >> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. >> Due to this when the app window goes to Secondary Screen with different DPI UI buttons >> appear incorrectly rendered. >> Following is a list proposed changes to fix this issue. >> >> >> Proposed Fix with Summary of changes: >> >> 1. Open a new Theme Handle per the DPI of the Screen where the App window is. >> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. >> window is. >> >> 2. GetPartSize() of icons returns size based on standard size = 96 DPI. >> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. >> >> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. >> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. >> >> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. >> --> This helps make sure that for .25s scaling we get better rendering. >> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. >> >> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. >> >> >> Testing: >> >> Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. >> >> ___________________________________ >> Monitor 1 | Monitor 2 >> (Primary) | >> | >> 125% | 175% >> 150% | 175% >> 150% | 225% >> 175% | 175% >> 175% | 150% >> 175% | 225% >> _____________________ |_____________ >> >> Also tested on setup with scaling values of up-to 350%. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java > > Co-authored-by: Andrey Turbanov src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java line 60: > 58: > 59: import java.util.HashMap; > 60: import javax.swing.AbstractButton; I find it very uncommon to have blank line not between `java.*` and `javax.*` imports. I suggest combining `HashMap` with other `java.*` and adding a blank line after `HashMap`. src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 106: > 104: } > 105: > 106: dpiAwareWidgetToTheme.computeIfAbsent(dpi, key->new HashMap<>()).put(widget, theme); Suggestion: dpiAwareWidgetToTheme.computeIfAbsent(dpi, key -> new HashMap<>()).put(widget, theme); There are usually spaces around `->` in lambda expressions. src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 125: > 123: // Close old themes. > 124: if (!dpiAwareWidgetToTheme.isEmpty()) { > 125: for (Map dpiVal: dpiAwareWidgetToTheme.values()) { Suggestion: for (Map dpiVal : dpiAwareWidgetToTheme.values()) { No space between type and its type arguments; spaces around `:` in for-each loop. src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 145: > 143: > 144: if (dpiAwareWidgetToTheme.get(dpi) != null) > 145: { Suggestion: if (dpiAwareWidgetToTheme.get(dpi) != null) { For consistent Java style. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1204694047 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1204707624 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1204711820 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1204713180 From erikj at openjdk.org Wed May 24 20:31:57 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 24 May 2023 20:31:57 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Mon, 22 May 2023 21:27:58 GMT, Jiangli Zhou wrote: >> Original description for JDK-8307194 change: >> ----- >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS >> ----- >> >> Updates to address build failures reported on macosx- platforms: >> >> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. >> >> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. >> >> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79. My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so make/common/NativeCompilation.gmk line 1210: > 1208: ifneq ($(findstring $(TOOLCHAIN_TYPE), gcc clang), ) > 1209: $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \ > 1210: $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \ Mac builds failed in our distributed system. I believe this will fix it: Suggestion: $(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; ) \ $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \ It also looks like the indentation in this block is off, 3 spaces instead of 4. ------------- PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1442698087 PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1204726154 From jiangli at openjdk.org Wed May 24 21:02:00 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 24 May 2023 21:02:00 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v5] In-Reply-To: References: Message-ID: > Original description for JDK-8307194 change: > ----- > This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: > > - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target > > - For libjvm.a specifically, exclude operator_new.o > > - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols > - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled > - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a > > - Handle long arguments case for static build in make/common/NativeCompilation.gmk > > - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS > ----- > > Updates to address build failures reported on macosx- platforms: > > - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. > > The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. > > The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update make/common/NativeCompilation.gmk Thanks you! Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14064/files - new: https://git.openjdk.org/jdk/pull/14064/files/695bda5e..93366e38 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064 PR: https://git.openjdk.org/jdk/pull/14064 From erikj at openjdk.org Wed May 24 21:02:01 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 24 May 2023 21:02:01 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 20:29:09 GMT, Erik Joelsson wrote: > My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: > > ``` > [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so > ``` If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561910764 From jiangli at openjdk.org Wed May 24 21:02:01 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 24 May 2023 21:02:01 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 20:52:38 GMT, Erik Joelsson wrote: >> My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: >> >> >> [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so > >> My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: >> >> ``` >> [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so >> ``` > > If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems. > > Hi @erikj79 Please let me know if you have any additional comments for the PR. Could you please also help run through testing for the latest version? Thanks > > I'm running a full set of builds now, but in my initial local build on mac, I see a lot of warnings like this: > > ``` > .../Xcode/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/libc++.tbd, ignoring unexpected dylib text stub file > ``` > > Any idea what that could be caused by or if it's possible to eliminate? I observed the same warnings on my macosx-x86_64 local build. It's from the partial linking step. Not much information yielded when I searched for `ignoring unexpected dylib text stub file`. Search found https://opensource.apple.com/source/ld64/ld64-609/src/ld/InputFiles.cpp with the linker code throwing the warning (`dylibsNotAllowed` is true if `_options.outputKind` is `Options::kObjectFile`, which is related to what we are observing). I tried linking a `javastatic` executable using the static libraries created with partial linking on macosx-x86_64 last week. I was able to execute `javastatic` in my quick test but didn't go further for more verification, as the runtime didn't work with the static build yet. Haven't found any information on how to suppress the warning either. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561913004 From rmahajan at openjdk.org Wed May 24 21:17:11 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Wed, 24 May 2023 21:17:11 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v5] In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: > Problem: > > Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: > > - Scrawly ticks in checkboxes; > - Wrong circle relations in selected radio buttons. > > Root-cause: > We open theme on AWT Toolkit Window which always has Primary Monitor DPI. > Due to this when the app window goes to Secondary Screen with different DPI UI buttons > appear incorrectly rendered. > Following is a list proposed changes to fix this issue. > > > Proposed Fix with Summary of changes: > > 1. Open a new Theme Handle per the DPI of the Screen where the App window is. > --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. > window is. > > 2. GetPartSize() of icons returns size based on standard size = 96 DPI. > --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. > > 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. > -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. > > 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. > --> This helps make sure that for .25s scaling we get better rendering. > This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. > > As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. > > > Testing: > > Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. > > ___________________________________ > Monitor 1 | Monitor 2 > (Primary) | > | > 125% | 175% > 150% | 175% > 150% | 225% > 175% | 175% > 175% | 150% > 175% | 225% > _____________________ |_____________ > > Also tested on setup with scaling values of up-to 350%. Rajat Mahajan has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java Co-authored-by: Alexey Ivanov - Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13701/files - new: https://git.openjdk.org/jdk/pull/13701/files/00ce4978..8cfb4134 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13701.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701 PR: https://git.openjdk.org/jdk/pull/13701 From jiangli at openjdk.org Wed May 24 21:50:55 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 24 May 2023 21:50:55 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 20:52:38 GMT, Erik Joelsson wrote: > > My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: > > ``` > > [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so > > ``` > > If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems. The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation. Is it possible `$$($1_SYSROOT_LDFLAGS)` pulled in `libstdc++.so` as part of the input for partial linking with the linux-aarch64 cross build? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561969001 From serb at openjdk.org Wed May 24 21:59:57 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 May 2023 21:59:57 GMT Subject: RFR: 8307132: Cleanup the code of sun.java2d.cmm.lcms package [v3] In-Reply-To: References: <_LRz2K4G7ZNjIO9C_5z2N9xWTfz25uUtRmefY2FRfkA=.d111a3fc-4264-43fb-a238-dc7129c61506@github.com> Message-ID: On Mon, 22 May 2023 17:20:22 GMT, Sergey Bylokhov wrote: >> The description from big to small: >> >> - Our code to handle the image types we support is too generic, the LCMSImageLayout class can handle, byte, short, int, and double types, and many various properties of the image layout. As a result, we pass a couple of good parameters to the LCMSImageLayout and have to use safeXX methods in it to calculate the final layout, and then validate it. >> This patch moves the layout properties calculation to one place - the constructor of LCMSImageLayout, and from the outside of the class, we now pass only the data array and the number of components per pixel: >> - The usage of Double type is removed, we do not use that type currently, and do not plan to support it in the future. Note that we support the float type, and I tried to implement it, but unfortunately, it is [intentionally ](https://github.com/mm2/Little-CMS/issues/356)slow. So will continue to use short type instead of float. >> - Discussed a few times the `do { } while (false);` block is removed. > > Sergey Bylokhov 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 six additional commits since the last revision: > > - Merge branch 'openjdk:master' into cms_cleanup_v3 > - split type and size > - add a comment > - Merge branch 'master' into cms_cleanup_v3 > - Merge branch 'master' into cms_cleanup_v3 > - 8307132: Cleanup the code of sun.java2d.cmm.lcms package @prrace The PR is updated, and the tests are green. Please take a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13732#issuecomment-1561978573 From prr at openjdk.org Wed May 24 22:30:59 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 24 May 2023 22:30:59 GMT Subject: RFR: 8307132: Cleanup the code of sun.java2d.cmm.lcms package [v3] In-Reply-To: References: <_LRz2K4G7ZNjIO9C_5z2N9xWTfz25uUtRmefY2FRfkA=.d111a3fc-4264-43fb-a238-dc7129c61506@github.com> Message-ID: <64Ift_O0PyGGV59CeVQbNNLn48q1oZOch-ZhEcbORD0=.7ce3fe9f-8edd-4b36-ae37-b8fd4c32b2e9@github.com> On Mon, 22 May 2023 17:20:22 GMT, Sergey Bylokhov wrote: >> The description from big to small: >> >> - Our code to handle the image types we support is too generic, the LCMSImageLayout class can handle, byte, short, int, and double types, and many various properties of the image layout. As a result, we pass a couple of good parameters to the LCMSImageLayout and have to use safeXX methods in it to calculate the final layout, and then validate it. >> This patch moves the layout properties calculation to one place - the constructor of LCMSImageLayout, and from the outside of the class, we now pass only the data array and the number of components per pixel: >> - The usage of Double type is removed, we do not use that type currently, and do not plan to support it in the future. Note that we support the float type, and I tried to implement it, but unfortunately, it is [intentionally ](https://github.com/mm2/Little-CMS/issues/356)slow. So will continue to use short type instead of float. >> - Discussed a few times the `do { } while (false);` block is removed. > > Sergey Bylokhov 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 six additional commits since the last revision: > > - Merge branch 'openjdk:master' into cms_cleanup_v3 > - split type and size > - add a comment > - Merge branch 'master' into cms_cleanup_v3 > - Merge branch 'master' into cms_cleanup_v3 > - 8307132: Cleanup the code of sun.java2d.cmm.lcms package Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13732#pullrequestreview-1442831111 From honkar at openjdk.org Wed May 24 23:09:54 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 24 May 2023 23:09:54 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: References: Message-ID: On Tue, 23 May 2023 02:52:03 GMT, lawrence.andrews wrote: > 1) Used builder pattern > 2) Tested AWT tests and it passed @lawrence-andrew Here is a consolidated review and few suggestions - - Firstly, the use of builder pattern for screenshot capability looks well structured and clean. It is easy for extensibility and does not break the existing functionality. That being said, the screenshot capability can additionally be helpful for automated tests too. - Screenshot capability might be more helpful in case of Client CI / Automated Testing since this feature will make it easier to capture screenshots at different instances when running the test. There are few automated tests currently that capture screenshot when the test fails. The screen capture code is repetitive and redundant and can be changed to use the common functionality that you have designed. - In case it is decided to extend this functionality to automated tests then having this is `regtesthelpers/Util` instead of PassFailJFrame would be more appropriate since PassFailJFrame is more of a manual framework and moving the functionality to Util will look cleaner. - Is the screenshot saved to the test source or jtreg scratch directory? Saving it to scratch would be ideal. - Additionally you could add the screenshot img filename to the JOptionPane that shows up the "Screenshot successfully captured" message. ------------- PR Review: https://git.openjdk.org/jdk/pull/14094#pullrequestreview-1442859692 From honkar at openjdk.org Wed May 24 23:19:54 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 24 May 2023 23:19:54 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: References: Message-ID: On Wed, 24 May 2023 19:53:00 GMT, Alexey Ivanov wrote: >>> I looked at the JBS issue and this PR's description but when I look at the changes, there are changes to tests as well, like the awt TrayIcon one. Is that meant to be included? Or is that a separate change that accidentally got bundled with this change to PassFailJFrame? >> >> I believe this is intended to demonstrate the usage of the screenshot feature. >> >> Yet it may be a hindrance for backporting? if the modified tests don't exist in previous versions or there are other differences? > >> Yet it may be a hindrance for backporting? if the modified tests don't exist in previous versions or there are other differences? > > To facilitate backporting, this PR may be broken into two PRs: the first one which updates the API of `PassFailJFrame`, the second, dependent, PR updates the tests. > > I faced some difficulties when I was backporting `PassFailJFrame` to 17u and 11u because some changes to the framework were combined with tests. The `PrintLatinCJKTest` test that is modified here isn't backported to 17u or 11u. > > I will definitely want to backport these changes to previous versions of JDK, so I am for *splitting the PR*. Thank you, @DamonGuy, for bringing this up. @aivanov-jdk > Yet it may be a hindrance for backporting? if the modified tests don't exist in previous versions or there are other differences? I agree, framework changes and test changes can be separated for easier back-porting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14094#issuecomment-1562043802 From jiangli at openjdk.org Thu May 25 01:22:02 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 25 May 2023 01:22:02 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 21:47:49 GMT, Jiangli Zhou wrote: > > > My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: > > > ``` > > > [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so > > > ``` > > > > > > If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems. > > The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation. > > Is it possible `$$($1_SYSROOT_LDFLAGS)` pulled in `libstdc++.so` as part of the input for partial linking with the linux-aarch64 cross build? Another possibility might be the user provided `BUILD_LDCXX` includes extra options in the testing build (?). If that's the case, we probably could define a separate `BUILD_LD_PARTIAL` with no added options. In our prototype on JDK 11, we define a separate one for partial linking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1562128417 From dholmes at openjdk.org Thu May 25 01:36:55 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 May 2023 01:36:55 GMT Subject: RFR: 8308780: Fix the Java Integer types on Windows In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com> References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com> Message-ID: On Wed, 24 May 2023 13:56:05 GMT, Julian Waters wrote: > On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code I think the JNI type definition change is okay. However many of the other changes appear to me to not involve Java variables and so don't need to be Java types i.e they should be `int` rather than `jint` - though as these are native Windows types there may not actually be any reason to change them from `long`. This is for the client-libs folk to decide. src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 325: > 323: } > 324: > 325: jint sx, sy, ex, ey; These are not Java variables. They get passed to the win32 GDI Arc function below which expects `int`. src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 605: > 603: return; > 604: } > 605: jint sx, sy, ex, ey; Again these don't seem to need to be Java types. ------------- PR Review: https://git.openjdk.org/jdk/pull/14125#pullrequestreview-1442950619 PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1204903525 PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1204904147 From duke at openjdk.org Thu May 25 06:02:07 2023 From: duke at openjdk.org (ScientificWare) Date: Thu, 25 May 2023 06:02:07 GMT Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v13] In-Reply-To: References: Message-ID: On Sun, 5 Feb 2023 09:55:27 GMT, ScientificWare wrote: >> This is referenced in Java Bug Database as >> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776) >> >> This is tracked in JBS as >> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776) >> >> Adds the 4 and 8 digits color hex notations to CSS.java, as described in : >> CSS Color Module Level 4 >> W3C Candidate Recommendation Snapshot, 5 July 2022 >> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation) >> >> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13) > > ScientificWare has updated the pull request incrementally with two additional commits since the last revision: > > - Updates copyright date. > > Updates copyright date to 2023. > - Updates copyright date. > > Updates copyright date to 2023. Delay due to the reorganization of my contribution schedule caused by new requests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/10317#issuecomment-1562320008 From duke at openjdk.org Thu May 25 06:02:12 2023 From: duke at openjdk.org (ScientificWare) Date: Thu, 25 May 2023 06:02:12 GMT Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4 [v29] In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 21:56:28 GMT, ScientificWare wrote: >> This is referenced in Java Bug Database as >> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276) >> >> This is tracked in JBS as >> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276) >> >> Adds missing color names, defined by CSS Level 4, in CSS.java : >> CSS Color Module Level 4 >> W3C Candidate Recommendation Snapshot, 5 July 2022 >> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color) >> >> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12) > > ScientificWare has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java > > Remove space. > > Co-authored-by: Alexey Ivanov Delay due to the reorganization of my contribution schedule caused by new requests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/9825#issuecomment-1562320559 From psadhukhan at openjdk.org Thu May 25 06:05:05 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 25 May 2023 06:05:05 GMT Subject: Withdrawn: 4130823: Not painting focus when the radio button has only icon In-Reply-To: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com> References: <2UVtDmQT6z_jef3OdPfY2WRE1enpPpdwYDkpZToY7gM=.10f6e589-5a03-4ca9-8dc9-aecd41921d67@github.com> Message-ID: On Thu, 23 Mar 2023 06:17:18 GMT, Prasanta Sadhukhan wrote: > Although the issue here is asking about not painting focus when it has icon, however it seems Windows does not draw focus rect for radiobutton at all so instead of closing this as "Not an issue" it is made to not draw the focusrect even when there is text > > This is what can be seen in windows system setting > > ![systemsetting-nofocusrect](https://user-images.githubusercontent.com/43534309/227118784-97d6231d-beb4-4fc9-b760-c47e95817592.png) > > and notepad > > ![notepad-nofocus](https://user-images.githubusercontent.com/43534309/227118824-9d02329f-396d-43b3-aa68-927009a1bd57.png) > > We have currently > > ![beforefix-dashrect](https://user-images.githubusercontent.com/43534309/227119231-19feb2fd-203b-48a2-9e59-62ab63b51ccc.png) > > > and after fix > > ![afterfix-nodashrect](https://user-images.githubusercontent.com/43534309/227119263-09be94e2-c6cc-4d7b-9449-a860aabca572.png) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13153 From tr at openjdk.org Thu May 25 07:17:58 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 25 May 2023 07:17:58 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> <9CYm1ES0qMrb-t6K6q6xWqB9SK8TmF91Mg7Ccp-euB4=.18b0c646-55d5-4daa-93d0-476045e65d68@github.com> Message-ID: On Wed, 24 May 2023 15:48:34 GMT, Alexey Ivanov wrote: >> I understand that, virtual folders don't have a filesystem path, this is why `fsv.isFileSystem(f)` should handle this situation. The implementation of `FileSystemView.isFileSystem` explicitly excludes such files which are both `isLink` and `isDirectory`: >> https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java#L382-L388 >> >> Let's look deeper: >> https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L591-L597 >> >> https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L860-L866 >> >> The `hasAttribute` method uses `getAttributes0` which calls [`IShellFolder::GetAttributesOf`](https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-ishellfolder-getattributesof) which returns [`SFGAO`](https://learn.microsoft.com/en-us/windows/win32/shell/sfgao). The attribute `SFGAO_LINK` which corresponds to `ATTRIB_LINK` in Java is described as _?The specified items are shortcuts.?_ That is it is a shell folder shortcut with `.lnk` file extension, which used to be the case. >> >> However, now this attribute is set for both [_symbolic links_](https://learn.microsoft.com/en-us/windows/win32/fileio/creating-symbolic-links) and [_junctions_](https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions#junctions). >> >> Here's what different methods return: >> >> file: C:\test\symbolic-links\jdk - junction >> isFileSystem false >> isLink true >> isDirectory true >> isSymbolicLink false >> Absolute Path : null >> >> file: C:\test\symbolic-links\jdk - symbolic >> isFileSystem false >> isLink true >> isDirectory true >> isSymbolicLink true >> Absolute Path : C:\test\symbolic-links\jdk - symbolic >> >> file: C:\test\symbolic-links\jdk - shortcut.lnk >> isFileSystem false >> isLink true >> isDirectory true >> isSymbolicLink false >> Absolute Path : null >> >> >> In the three cases above, `isFileSystem` returns `false` even though all the three objects point to a filesystem directory, the first two are fully transparent for apps whereas the `.lnk` shortcut needs special handling. >> >> If `JFileChooser` is in directory-only mode, selecting a junction or `.lnk` file results in selected file being to `null`; symbolic links are support... > > Handling `.lnk` files on Windows doesn't seem right: `JFileChooser` allows selecting such a file. > > * If it's a shortcut to a directory, clicking Open in the file chooser or double-clicking it in the list navigates to the target. > * If it's a shortcut to a regular file, `JFileChooser` returns this file which isn't helpful, it's not what the user usually wants, the target of the shortcut should be returned. This is what happens if the user selects a shortcut file (`.lnk`) in the native file chooser. > > In addition to that, the shortcuts are filtered based on the file types. For example, if select the *Open* command in Notepad, the file chooser shows only shortcuts to `.txt` files (as well as `.txt` files), it hides shortcuts to other file types. > > But `JFileChooser` doesn't show `.lnk` files at all if an extension filter is set. > I understand that, virtual folders don't have a filesystem path, this is why `fsv.isFileSystem(f)` should handle this situation. The implementation of `FileSystemView.isFileSystem` explicitly excludes such files which are both `isLink` and `isDirectory`: > > https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java#L382-L388 > > Let's look deeper: > > https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L591-L597 > > https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L860-L866 > > The `hasAttribute` method uses `getAttributes0` which calls [`IShellFolder::GetAttributesOf`](https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-ishellfolder-getattributesof) which returns [`SFGAO`](https://learn.microsoft.com/en-us/windows/win32/shell/sfgao). The attribute `SFGAO_LINK` which corresponds to `ATTRIB_LINK` in Java is described as _?The specified items are shortcuts.?_ That is it is a shell folder shortcut with `.lnk` file extension, which used to be the case. > > However, now this attribute is set for both [_symbolic links_](https://learn.microsoft.com/en-us/windows/win32/fileio/creating-symbolic-links) and [_junctions_](https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions#junctions). > > Here's what different methods return: > > ``` > file: C:\test\symbolic-links\jdk - junction > isFileSystem false > isLink true > isDirectory true > isSymbolicLink false > Absolute Path : null > > file: C:\test\symbolic-links\jdk - symbolic > isFileSystem false > isLink true > isDirectory true > isSymbolicLink true > Absolute Path : C:\test\symbolic-links\jdk - symbolic > > file: C:\test\symbolic-links\jdk - shortcut.lnk > isFileSystem false > isLink true > isDirectory true > isSymbolicLink false > Absolute Path : null > ``` > > In the three cases above, `isFileSystem` returns `false` even though all the three objects point to a filesystem directory, the first two are fully transparent for apps whereas the `.lnk` shortcut needs special handling. > > If `JFileChooser` is in directory-only mode, selecting a junction or `.lnk` file results in selected file being to `null`; symbolic links are supported with your fix. > > So, **I propose modifying the implementation of `FileSystemView.isFileSystem`** so that it returns only `sf.isFileSystem()` or filters out the `.lnk` shortcuts only. Since `FileSystemView.isFileSystem` is used in many places for particular Look and Feel, there might be chances of regression. So how about checking for shell folder first and if yes then can combine the `shell.isFileSystem()` with `isSymbolicLink()` in BasicFileChooser class.......? If its not a shell folder then directly we can check for `isSymbolicLink()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1205092918 From duke at openjdk.org Thu May 25 07:20:09 2023 From: duke at openjdk.org (JoKern65) Date: Thu, 25 May 2023 07:20:09 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> Message-ID: On Wed, 24 May 2023 03:13:34 GMT, Kim Barrett wrote: >> Strange the last resulting change I see is >> `struct shmid_ds shm_buf{};` > > That's not what I see in this PR, and not what I see in the repository after the integration. Where are you seeing > that? (If in your local repository, maybe you forgot a push to the PR?) I checked it directly in repository [https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp) And there I see the desired `struct shmid_ds shm_buf{};` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1205094231 From jwaters at openjdk.org Thu May 25 07:25:54 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 25 May 2023 07:25:54 GMT Subject: RFR: 8308780: Fix the Java Integer types on Windows In-Reply-To: References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com> Message-ID: On Thu, 25 May 2023 01:34:15 GMT, David Holmes wrote: > I think the JNI type definition change is okay. > > However many of the other changes appear to me to not involve Java variables and so don't need to be Java types i.e they should be `int` rather than `jint` - though as these are native Windows types there may not actually be any reason to change them from `long`. This is for the client-libs folk to decide. All the changes from long were done since there was conversion from or to a jint somewhere down the line, and the compilation would fail if not done otherwise. I also changed them to jint rather than int so there wouldn't be a need to keep the variables in sync with the jni.h declarations, but I guess I'll wait for more reviews to see what to do here ------------- PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1562408466 From jwaters at openjdk.org Thu May 25 07:28:57 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 25 May 2023 07:28:57 GMT Subject: RFR: 8308780: Fix the Java Integer types on Windows In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com> References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com> Message-ID: On Wed, 24 May 2023 13:56:05 GMT, Julian Waters wrote: > On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code Going to page for @aivanov-jdk for `client-libs` review ------------- PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1562412122 From dholmes at openjdk.org Thu May 25 07:33:54 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 May 2023 07:33:54 GMT Subject: RFR: 8308780: Fix the Java Integer types on Windows In-Reply-To: References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com> Message-ID: <3gHtTfGRCwS2s9JxA8cpAdZmaw9ShU1v1VPIT--Rn5I=.2414e309-e34f-437d-b4dd-6a734e5bb88f@github.com> On Thu, 25 May 2023 07:22:50 GMT, Julian Waters wrote: > All the changes from long were done since there was conversion from or to a jint somewhere down the line, Okay I see that now. It is a messy situation - at some point the incoming jint's need to be "converted" to a native type. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1562418414 From jwaters at openjdk.org Thu May 25 08:51:55 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 25 May 2023 08:51:55 GMT Subject: RFR: 8308780: Fix the Java Integer types on Windows In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com> References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com> Message-ID: On Wed, 24 May 2023 13:56:05 GMT, Julian Waters wrote: > On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code I'll see what I can do, I'll check the parameter type for the methods that are called in relevant code, though if they take an int as an argument I'm not really sure what to change ------------- PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1562526271 From tr at openjdk.org Thu May 25 09:01:25 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 25 May 2023 09:01:25 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v5] In-Reply-To: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: > This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. > The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Alternate Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13998/files - new: https://git.openjdk.org/jdk/pull/13998/files/94798c3c..ee1acb4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=03-04 Stats: 13 lines in 1 file changed: 9 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13998/head:pull/13998 PR: https://git.openjdk.org/jdk/pull/13998 From tr at openjdk.org Thu May 25 09:10:09 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 25 May 2023 09:10:09 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v6] In-Reply-To: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: <9WfeFud6WEGlu-Z0s3beBLfVq5a4xA579EGSaH980Fs=.d0ccf334-ff2a-4ce4-9dc4-d7dedda9ddae@github.com> > This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. > The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: White space fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13998/files - new: https://git.openjdk.org/jdk/pull/13998/files/ee1acb4a..9dee0730 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13998/head:pull/13998 PR: https://git.openjdk.org/jdk/pull/13998 From tr at openjdk.org Thu May 25 09:10:30 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 25 May 2023 09:10:30 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> Message-ID: On Mon, 22 May 2023 15:55:41 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > Changes requested by aivanov (Reviewer). @aivanov-jdk The alternative fix validates symbolic along with path virtual folder validation. When it comes to Symbolic link check, I hope this fix does the job and works as expected too. Let me know if its fine? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13998#issuecomment-1562551614 From kbarrett at openjdk.org Thu May 25 09:13:13 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 25 May 2023 09:13:13 GMT Subject: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2] In-Reply-To: References: <3Df_OMjrX5Dhiso_trqoXPNIq2B0sbhfOmGPDWAY3-I=.ffd967c3-d1a3-45ac-82c0-39f1885c45bb@github.com> <_iLBokObnsgDeHfGIDZ2BmAg7xx6LkpGnLH6GhN_xPo=.a836570a-0fae-4af3-a09a-a8466694de06@github.com> Message-ID: On Thu, 25 May 2023 07:16:29 GMT, JoKern65 wrote: >> That's not what I see in this PR, and not what I see in the repository after the integration. Where are you seeing >> that? (If in your local repository, maybe you forgot a push to the PR?) > > I checked it directly in repository > [https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp) > And there I see the desired > `struct shmid_ds shm_buf{};` Weird! I see: https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp#L467 (permalink:) `https://github.com/openjdk/jdk/blob/d87713440a1ddb830e87171b009efe9507e644cb/src/hotspot/os/aix/os_aix.cpp#L467` https://github.com/openjdk/jdk/blob/d87713440a1ddb830e87171b009efe9507e644cb/src/hotspot/os/aix/os_aix.cpp#L467 struct shmid_ds shm_buf = { }; (above line was cut-and-pasted) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13953#discussion_r1205226537 From jwaters at openjdk.org Thu May 25 09:25:59 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 25 May 2023 09:25:59 GMT Subject: RFR: 8308780: Fix the Java Integer types on Windows In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com> References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com> Message-ID: <18Hb8qz70ED7U2vLbTCN11B28K117KPmEh8CIVASDMk=.136e983b-1cad-43e5-b8c9-b9495a60ff84@github.com> On Wed, 24 May 2023 13:56:05 GMT, Julian Waters wrote: > On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code For reference as to what types the calls in affected code accepts as parameters, so any future reviews don't need to dig through the code GDIRenderer.cpp: - Java_sun_java2d_windows_GDIRenderer_doFillArc * AngleToCoord takes jints as arguments * ::Pie takes ints as arguments - Java_sun_java2d_windows_GDIRenderer_doDrawArc * AngleToCoord takes jints as arguments * ::Arc takes ints as arguments GDIWindowSurfaceData.cpp: - GDIWinSD_GetRasInfo * SurfaceDataRasInfo's lutBase field is a jint* awt_MenuBar.cpp (Encompasses the changes in awt_Menu.h and awt_MenuBar.h as well): - AwtMenuBar::GetItem passes the only relevant jint (formerly long) into env->CallObjectMethod() AccessInfo.cpp - getAccessibleInfo * start and end (both formerly long) are both passed to GetAccessibleTextLineBounds and GetAccessibleTextRange which take jints Only outlier is jaccesswalker, which I think I may have edited wrongly ------------- PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1562575536 From duke at openjdk.org Thu May 25 09:28:22 2023 From: duke at openjdk.org (JoKern65) Date: Thu, 25 May 2023 09:28:22 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code Message-ID: When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". Some of those are in shared codebase and could be addressed by small adjustments. A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. ------------- Commit messages: - white space - JDK-8308288 Changes: https://git.openjdk.org/jdk/pull/14146/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14146&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308288 Stats: 52 lines in 11 files changed: 46 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14146/head:pull/14146 PR: https://git.openjdk.org/jdk/pull/14146 From serb at openjdk.org Thu May 25 09:39:07 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 25 May 2023 09:39:07 GMT Subject: Integrated: 8307132: Cleanup the code of sun.java2d.cmm.lcms package In-Reply-To: <_LRz2K4G7ZNjIO9C_5z2N9xWTfz25uUtRmefY2FRfkA=.d111a3fc-4264-43fb-a238-dc7129c61506@github.com> References: <_LRz2K4G7ZNjIO9C_5z2N9xWTfz25uUtRmefY2FRfkA=.d111a3fc-4264-43fb-a238-dc7129c61506@github.com> Message-ID: On Fri, 28 Apr 2023 21:34:36 GMT, Sergey Bylokhov wrote: > The description from big to small: > > - Our code to handle the image types we support is too generic, the LCMSImageLayout class can handle, byte, short, int, and double types, and many various properties of the image layout. As a result, we pass a couple of good parameters to the LCMSImageLayout and have to use safeXX methods in it to calculate the final layout, and then validate it. > This patch moves the layout properties calculation to one place - the constructor of LCMSImageLayout, and from the outside of the class, we now pass only the data array and the number of components per pixel: > - The usage of Double type is removed, we do not use that type currently, and do not plan to support it in the future. Note that we support the float type, and I tried to implement it, but unfortunately, it is [intentionally ](https://github.com/mm2/Little-CMS/issues/356)slow. So will continue to use short type instead of float. > - Discussed a few times the `do { } while (false);` block is removed. This pull request has now been integrated. Changeset: f27bc59f Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/f27bc59f85d5ea3df1f6b0b0a3932bab37d74709 Stats: 209 lines in 3 files changed: 11 ins; 116 del; 82 mod 8307132: Cleanup the code of sun.java2d.cmm.lcms package Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/13732 From aturbanov at openjdk.org Thu May 25 10:23:01 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 25 May 2023 10:23:01 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v6] In-Reply-To: <3QEJBac8UZLkHTYjJKcCSyMleMK8iV1Dvlzwo9NXvwM=.e132b4cb-fb07-4503-bc9b-59129c9e360b@github.com> References: <3QEJBac8UZLkHTYjJKcCSyMleMK8iV1Dvlzwo9NXvwM=.e132b4cb-fb07-4503-bc9b-59129c9e360b@github.com> Message-ID: <1MlRHUmykupjleuDLBKEmSlIlH3Aeat1zjN5013U5dE=.48688040-62f5-4d63-9c92-18708eff78c3@github.com> On Tue, 23 May 2023 15:15:29 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > awt.robot.screenshotMethod -> awt.robot.screenshotMethod, awt.robot.screencastDebug -> awt.robot.screenshotDebug src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 108: > 106: Rectangle captureArea = new Rectangle(x, y, width, height); > 107: > 108: List affectedScreenBounds = getSystemScreensBounds() nit Suggestion: List affectedScreenBounds = getSystemScreensBounds() ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1205310080 From aivanov at openjdk.org Thu May 25 10:41:09 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 25 May 2023 10:41:09 GMT Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4 [v29] In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 21:56:28 GMT, ScientificWare wrote: >> This is referenced in Java Bug Database as >> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276) >> >> This is tracked in JBS as >> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276) >> >> Adds missing color names, defined by CSS Level 4, in CSS.java : >> CSS Color Module Level 4 >> W3C Candidate Recommendation Snapshot, 5 July 2022 >> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color) >> >> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12) > > ScientificWare has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java > > Remove space. > > Co-authored-by: Alexey Ivanov It's not a problem even if it gets closed. You will reopen it with the [`/open`](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/open) command. ------------- PR Comment: https://git.openjdk.org/jdk/pull/9825#issuecomment-1562677376 From aivanov at openjdk.org Thu May 25 11:27:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 25 May 2023 11:27:56 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: References: Message-ID: On Wed, 24 May 2023 23:07:11 GMT, Harshitha Onkar wrote: > Here is a consolidated review and few suggestions - > > Firstly, the use of builder pattern for screenshot capability looks well structured and clean. It is easy for extensibility and does not break the existing functionality. This is the idea. New tests can use newer syntax, the old tests don't need any modifications. With a couple more updates which are planned, the usage will be even more streamlined. > That being said, the screenshot capability can additionally be helpful for automated tests too. It's a good point. However, taking screenshots doesn't require a lot of code and the screenshot could be limited to the relevant portion of the screen or displayed UI. > Screenshot capability might be more helpful in case of Client CI / Automated Testing since this feature will make it easier to capture screenshots at different instances when running the test. There are few automated tests currently that capture screenshot when the test fails. The screen capture code is repetitive and redundant and can be changed to use the common functionality that you have designed. This is one of the problems? A really stand-alone test which has _no dependencies_ is easier to run: compile and run; as of Java 17 you can even skip the compile step and pass the `.java` file directly to `java` launcher which compiles it for you without creating the external `.class` file(s). If there are dependencies, you have to employ _tricks_ to run the test. Overall, all GUI tests are somewhat repetitive, tests have duplicate code. It is possible to abstract this into helper classes. In fact, we have such classes: [`SwingTestHelper`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/regtesthelpers/SwingTestHelper.java), [`JRobot`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/regtesthelpers/JRobot.java), already mentioned [`Util`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/regtesthelpers/Util.java)? I don't say it's bad. I'm for avoiding code duplication. Yet I also appreciate the easiest way possible to run a test. The simpler and easier, the better. It's especially important during code reviews. > In case it is decided to extend this functionality to automated tests then having this is `regtesthelpers/Util` instead of PassFailJFrame would be more appropriate since PassFailJFrame is more of a manual framework and moving the functionality to Util will look cleaner. This can easily be done in a follow-up PR. The only thing that can really be abstracted is the call to `Robot.createScreenCapture` or `Robot.createMultiResolutionScreenCapture` and saving to a file. Well, yes, taking the screenshots of the entire screen can be a utility method. Then, the jtreg framework does make screenshots in the CI if headful test fails. I've seen it multiple times. They're not always useful because the test UI is usually closed by the time when screenshot is taken. Yet you can see if there are other windows open on the system which could interfere with the test. > Is the screenshot saved to the test source or jtreg scratch directory? Saving it to scratch would be ideal. It saves the images to _the current directory_. When the test is run by jtreg, the current directory is the `scratch` directory. > Additionally you could add the screenshot img filename to the JOptionPane that shows up the "Screenshot successfully captured" message. There could be multiple files. In fact, I question the need for a modal dialog confirming that the operation completed successfully. If an error occurs, a modal dialog is a good way of notifying. If no error occurs, the message is somewhat redundant. If the displayed message isn't modal, like a tooltip or a notification which disappears automatically after a certain time, it could be better appreciated. But it's harder to implement. What could be helpful though is an option to open the current directory in File Explorer, Finder? to allow viewing the collected screenshots. It's more helpful than displaying file names, isn't it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14094#issuecomment-1562735444 From aivanov at openjdk.org Thu May 25 11:41:57 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 25 May 2023 11:41:57 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> <9CYm1ES0qMrb-t6K6q6xWqB9SK8TmF91Mg7Ccp-euB4=.18b0c646-55d5-4daa-93d0-476045e65d68@github.com> Message-ID: On Thu, 25 May 2023 07:15:10 GMT, Tejesh R wrote: > Since `FileSystemView.isFileSystem` is used in many places for particular Look and Feel, there might be chances of regression. So how about checking for shell folder first and if yes then can combine the `shell.isFileSystem()` with `isSymbolicLink()` in BasicFileChooser class.......? If its not a shell folder then directly we can check for `isSymbolicLink()`. I guess what I proposed is riskier but _it's better_. It resolves the problem why junctions and symbolic links aren't accepted. It will also handle junctions correctly, now, as I showed above, selecting a junction results in the selected file being set to `null` just like it was for symbolic links before your first fix. Another thing to try is to modify `Win32ShellFolder2.isLink` so that it returns `true` only for Windows shortcuts that is for `.lnk` files. In this case, the behaviour will be the same as it was on previous versions of Windows where neither junctions nor symbolic links were considered a link. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1205388746 From mbaesken at openjdk.org Thu May 25 12:57:55 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 25 May 2023 12:57:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code In-Reply-To: References: Message-ID: On Thu, 25 May 2023 09:14:14 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Some of those are in shared codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. In the macro define checks, you both check macros _AIX and AIX, sometimes this, sometimes that. Might be possible to just use one of the two for consistency, but I am fine with using both as well, leave this up to you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1562859320 From aivanov at openjdk.org Thu May 25 13:44:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 25 May 2023 13:44:56 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> <9CYm1ES0qMrb-t6K6q6xWqB9SK8TmF91Mg7Ccp-euB4=.18b0c646-55d5-4daa-93d0-476045e65d68@github.com> Message-ID: On Thu, 25 May 2023 11:39:33 GMT, Alexey Ivanov wrote: >>> I understand that, virtual folders don't have a filesystem path, this is why `fsv.isFileSystem(f)` should handle this situation. The implementation of `FileSystemView.isFileSystem` explicitly excludes such files which are both `isLink` and `isDirectory`: >>> >>> https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java#L382-L388 >>> >>> Let's look deeper: >>> >>> https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L591-L597 >>> >>> https://github.com/openjdk/jdk/blob/d7245f70e7bac1236bbcdcd9b25346ca22ab8bb2/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java#L860-L866 >>> >>> The `hasAttribute` method uses `getAttributes0` which calls [`IShellFolder::GetAttributesOf`](https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-ishellfolder-getattributesof) which returns [`SFGAO`](https://learn.microsoft.com/en-us/windows/win32/shell/sfgao). The attribute `SFGAO_LINK` which corresponds to `ATTRIB_LINK` in Java is described as _?The specified items are shortcuts.?_ That is it is a shell folder shortcut with `.lnk` file extension, which used to be the case. >>> >>> However, now this attribute is set for both [_symbolic links_](https://learn.microsoft.com/en-us/windows/win32/fileio/creating-symbolic-links) and [_junctions_](https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions#junctions). >>> >>> Here's what different methods return: >>> >>> ``` >>> file: C:\test\symbolic-links\jdk - junction >>> isFileSystem false >>> isLink true >>> isDirectory true >>> isSymbolicLink false >>> Absolute Path : null >>> >>> file: C:\test\symbolic-links\jdk - symbolic >>> isFileSystem false >>> isLink true >>> isDirectory true >>> isSymbolicLink true >>> Absolute Path : C:\test\symbolic-links\jdk - symbolic >>> >>> file: C:\test\symbolic-links\jdk - shortcut.lnk >>> isFileSystem false >>> isLink true >>> isDirectory true >>> isSymbolicLink false >>> Absolute Path : null >>> ``` >>> >>> In the three cases above, `isFileSystem` returns `false` even though all the three objects point to a filesystem directory, the first two are fully transparent for apps whereas the `.lnk` shortcut needs special handling. >>> >>> If `JFileChooser` is in directory-only mode, selecting a junction or `.lnk` file results in ... > >> Since `FileSystemView.isFileSystem` is used in many places for particular Look and Feel, there might be chances of regression. So how about checking for shell folder first and if yes then can combine the `shell.isFileSystem()` with `isSymbolicLink()` in BasicFileChooser class.......? If its not a shell folder then directly we can check for `isSymbolicLink()`. > > I guess what I proposed is riskier but _it's better_. It resolves the problem why junctions and symbolic links aren't accepted. It will also handle junctions correctly, now, as I showed above, selecting a junction results in the selected file being set to `null` just like it was for symbolic links before your first fix. > > Another thing to try is to modify `Win32ShellFolder2.isLink` so that it returns `true` only for Windows shortcuts that is for `.lnk` files. In this case, the behaviour will be the same as it was on previous versions of Windows where neither junctions nor symbolic links were considered a link. As for other Look-and-Feels, `isFileSystem` is used for the same purpose that it's used in the code you're modifying: if a selected object in the list is a file system object (a directory), the text field to the path of the selected object; otherwise, set the text field to `null`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1205541978 From tr at openjdk.org Thu May 25 14:01:00 2023 From: tr at openjdk.org (Tejesh R) Date: Thu, 25 May 2023 14:01:00 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> <9CYm1ES0qMrb-t6K6q6xWqB9SK8TmF91Mg7Ccp-euB4=.18b0c646-55d5-4daa-93d0-476045e65d68@github.com> Message-ID: <-wdzUmGqS7uN5Mrs3xaw20DKKeifUXqmAnDkWS0E0rM=.29ceb60a-ed4f-41c0-af74-4585ee9fe956@github.com> On Thu, 25 May 2023 13:42:29 GMT, Alexey Ivanov wrote: >>> Since `FileSystemView.isFileSystem` is used in many places for particular Look and Feel, there might be chances of regression. So how about checking for shell folder first and if yes then can combine the `shell.isFileSystem()` with `isSymbolicLink()` in BasicFileChooser class.......? If its not a shell folder then directly we can check for `isSymbolicLink()`. >> >> I guess what I proposed is riskier but _it's better_. It resolves the problem why junctions and symbolic links aren't accepted. It will also handle junctions correctly, now, as I showed above, selecting a junction results in the selected file being set to `null` just like it was for symbolic links before your first fix. >> >> Another thing to try is to modify `Win32ShellFolder2.isLink` so that it returns `true` only for Windows shortcuts that is for `.lnk` files. In this case, the behaviour will be the same as it was on previous versions of Windows where neither junctions nor symbolic links were considered a link. > > As for other Look-and-Feels, `isFileSystem` is used for the same purpose that it's used in the code you're modifying: if a selected object in the list is a file system object (a directory), the text field to the path of the selected object; otherwise, set the text field to `null`. Ok, then let me work the proposed fix. As per the proposed fix, `FileSystemView.isFileSystem ` has to return if its fileSystem or not......? What about .ink? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1205563299 From kbarrett at openjdk.org Thu May 25 15:23:58 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 25 May 2023 15:23:58 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code In-Reply-To: References: Message-ID: On Thu, 25 May 2023 09:14:14 GMT, JoKern65 wrote: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Some of those are in shared codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. Sorry, but I can't review the warning suppressions. Without more information about exactly what warnings are being suppressed and where, I have no way to evaluate whether suppression is an appropriate response. It could be that some of the warnings are correctly pointing out (possibly serious) flaws that really need to be fixed. Continuing to hide them doesn't seem like a winning strategy to me. I also suggest avoiding omnibus changes like this when possible (which it is here). Just because it's all about removing warnings from a new toolchain doesn't make it a cohesive change. That makes it harder to review and to manage the review, because it is larger and affects a wide range of areas, so may need many reviewers. And the whole thing might get stalled by discussion of one piece. make/modules/java.desktop/lib/Awt2dLibraries.gmk line 706: > 704: # temporarily disable PNG_POWERPC_VSX_OPT which would be set, because > 705: # if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) > 706: # is true, the then needed libpng function .png_init_filter_functions_vsx s/then// src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47: > 45: #undef malloc > 46: extern void *malloc(size_t) asm("vec_malloc"); > 47: #endif Wow! And I don't mean that in a good way. I'm not questioning whether this is correct, just commenting on how crazy it seems that such a thing might be needed. test/jdk/java/io/File/libGetXSpace.c line 128: > 126: #else > 127: struct statfs buf; > 128: int result = statfs((char*)chars, &buf); Is this working around a bug in IBM's declaration? Also, pre-existing, the cast seems really suspicious. The type of `chars` is `jchar*`, which is a sequence of 16bit characters. Does this actually work? If so, how? ------------- PR Review: https://git.openjdk.org/jdk/pull/14146#pullrequestreview-1444057072 PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205622153 PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205655676 PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205673657 From duke at openjdk.org Thu May 25 16:16:57 2023 From: duke at openjdk.org (JoKern65) Date: Thu, 25 May 2023 16:16:57 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code In-Reply-To: References: Message-ID: On Thu, 25 May 2023 15:18:41 GMT, Kim Barrett wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > test/jdk/java/io/File/libGetXSpace.c line 128: > >> 126: #else >> 127: struct statfs buf; >> 128: int result = statfs((char*)chars, &buf); > > Is this working around a bug in IBM's declaration? > > Also, pre-existing, the cast seems really suspicious. The type of `chars` is `jchar*`, which is a > sequence of 16bit characters. Does this actually work? If so, how? This is IBMs declaration of statfs `extern int statfs(char *, struct statfs *);` So the compiler will not accept a `const char*` Indeed I do not know if this ever worked, but my change makes it not worse. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205745144 From azvegint at openjdk.org Thu May 25 16:29:39 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 25 May 2023 16:29:39 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: References: Message-ID: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: rework token storage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/c077dc7a..1bd099cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=05-06 Stats: 459 lines in 3 files changed: 358 ins; 38 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From psadhukhan at openjdk.org Thu May 25 16:46:04 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 25 May 2023 16:46:04 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v5] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 03:45:50 GMT, Tejesh R wrote: >> Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 65: > 63: frame.setSize(300, 300); > 64: frame.setLocation(20, 300); > 65: frame.setLocationRelativeTo(null); it will override the previous setLocation so that can be removed.. test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 103: > 101: robot.delay(500); > 102: > 103: EventQueue.invokeAndWait(() -> { why is it under EDT? you can make the variable volatile and remove EDT test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 118: > 116: } > 117: > 118: public static Point getLocation(Component co) throws RuntimeException { I guess you can remove this method and use `frame.getLocationOnScreen` instead test/jdk/java/awt/Robot/RobotMoveMultiscreen.java line 44: > 42: public class RobotMoveMultiscreen { > 43: static int x_dest = 20; > 44: static int y_dest = 20; these are accessed in 2 threads, you need to make it volatile test/jdk/java/awt/Robot/RobotMoveMultiscreen.java line 79: > 77: robot.waitForIdle(); > 78: robot.mouseMove(x_dest+50, y_dest+50); > 79: robot.delay(1000); I dont think we need to wait for 1sec after mouseMove, you can just have `waitForIdle` test/jdk/java/awt/Scrollbar/ScrollbarKeyControlTest.java line 62: > 60: } > 61: > 62: public void init() throws Exception { you can move the contents into main test/jdk/java/awt/Scrollbar/ScrollbarKeyControlTest.java line 84: > 82: }); > 83: robot = new Robot(); > 84: testOneScrollbar(scrollbarV); you should need to add robot.delay(1000) after frame is visible before commencing test ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1205762575 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1205764460 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1205768223 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1205770151 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1205771198 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1205774807 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1205777846 From azvegint at openjdk.org Thu May 25 16:49:02 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 25 May 2023 16:49:02 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 16:29:39 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > rework token storage Token storage now does not use Preferences API and serialization. (there were some problems with missing token during automated testing). Properties API is now used: No more writing to file if token data was not updated. Detect external changes to the file, and update the token data if it was updated. If we can't save the data, we can still use the received token, but we won't keep it between runs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1563212589 From honkar at openjdk.org Thu May 25 17:50:56 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 25 May 2023 17:50:56 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: References: Message-ID: On Thu, 25 May 2023 11:24:42 GMT, Alexey Ivanov wrote: >> @lawrence-andrew >> >> Here is a consolidated review and few suggestions - >> >> - Firstly, the use of builder pattern for screenshot capability looks well structured and clean. It is easy for extensibility and does not break the existing functionality. That being said, the screenshot capability can additionally be helpful for automated tests too. >> >> - Screenshot capability might be more helpful in case of Client CI / Automated Testing since this feature will make it easier to capture screenshots at different instances when running the test. There are few automated tests currently that capture screenshot when the test fails. The screen capture code is repetitive and redundant and can be changed to use the common functionality that you have designed. >> >> - In case it is decided to extend this functionality to automated tests then having this is `regtesthelpers/Util` instead of PassFailJFrame would be more appropriate since PassFailJFrame is more of a manual framework and moving the functionality to Util will look cleaner. >> >> - Is the screenshot saved to the test source or jtreg scratch directory? Saving it to scratch would be ideal. >> >> - Additionally you could add the screenshot img filename to the JOptionPane that shows up the "Screenshot successfully captured" message. > >> Here is a consolidated review and few suggestions - >> >> Firstly, the use of builder pattern for screenshot capability looks well structured and clean. It is easy for extensibility and does not break the existing functionality. > > This is the idea. New tests can use newer syntax, the old tests don't need any modifications. > > With a couple more updates which are planned, the usage will be even more streamlined. > >> That being said, the screenshot capability can additionally be helpful for automated tests too. > > It's a good point. However, taking screenshots doesn't require a lot of code and the screenshot could be limited to the relevant portion of the screen or displayed UI. > >> Screenshot capability might be more helpful in case of Client CI / Automated Testing since this feature will make it easier to capture screenshots at different instances when running the test. There are few automated tests currently that capture screenshot when the test fails. The screen capture code is repetitive and redundant and can be changed to use the common functionality that you have designed. > > This is one of the problems? A really stand-alone test which has _no dependencies_ is easier to run: compile and run; as of Java 17 you can even skip the compile step and pass the `.java` file directly to `java` launcher which compiles it for you without creating the external `.class` file(s). > > If there are dependencies, you have to employ _tricks_ to run the test. > > Overall, all GUI tests are somewhat repetitive, tests have duplicate code. It is possible to abstract this into helper classes. In fact, we have such classes: [`SwingTestHelper`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/regtesthelpers/SwingTestHelper.java), [`JRobot`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/regtesthelpers/JRobot.java), already mentioned [`Util`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/regtesthelpers/Util.java)? > > I don't say it's bad. I'm for avoiding code duplication. Yet I also appreciate the easiest way possible to run a test. The simpler and easier, the better. It's especially important during code reviews. > >> In case it is decided to extend this functionality to automated tests then having this is `regtesthelpers/Util` instead of PassFailJFrame would be more appropriate since PassFailJFrame is more of a manual framework and moving the functionality to Util will look cleaner. > > This can easily be done in a follow-... @aivanov-jdk > This can easily be done in a follow-up PR. > > The only thing that can really be abstracted is the call to `Robot.createScreenCapture` or `Robot.createMultiResolutionScreenCapture` and saving to a file. Well, yes, taking the screenshots of the entire screen can be a utility method. Sounds good. > It saves the images to _the current directory_. When the test is run by jtreg, the current directory is the `scratch` directory. For me, the generated screenshot was being saved to the test folder, as I was running it as standalone test. I had issues running it as jtreg test, but this is probably due to some config issue on my end and nothing related to code changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14094#issuecomment-1563284316 From mdoerr at openjdk.org Thu May 25 18:21:58 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 25 May 2023 18:21:58 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code In-Reply-To: References: Message-ID: On Thu, 25 May 2023 15:04:32 GMT, Kim Barrett wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47: > >> 45: #undef malloc >> 46: extern void *malloc(size_t) asm("vec_malloc"); >> 47: #endif > > Wow! And I don't mean that in a good way. I'm not questioning whether this is correct, just commenting > on how crazy it seems that such a thing might be needed. The crazy thing is that `malloc` is defined! That means all places where we use the term malloc are getting replaced without such a workaround. (E.g. for log tags.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205867287 From dcubed at openjdk.org Thu May 25 21:40:18 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 25 May 2023 21:40:18 GMT Subject: Integrated: 8308907: ProblemList java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java on linux-x64 Message-ID: Trivial fixes to ProblemList a few tests: [JDK-8308907](https://bugs.openjdk.org/browse/JDK-8308907) ProblemList java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java on linux-x64 [JDK-8308908](https://bugs.openjdk.org/browse/JDK-8308908) ProblemList javax/sound/sampled/Clip/ClipIsRunningAfterStop.java on linux-x64 [JDK-8308909](https://bugs.openjdk.org/browse/JDK-8308909) ProblemList sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java on linux-x64 ------------- Commit messages: - 8308909: ProblemList sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java on linux-x64 - 8308908: ProblemList javax/sound/sampled/Clip/ClipIsRunningAfterStop.java on linux-x64 - 8308907: ProblemList java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java on linux-x64 Changes: https://git.openjdk.org/jdk/pull/14163/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14163&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308907 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14163.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14163/head:pull/14163 PR: https://git.openjdk.org/jdk/pull/14163 From mikael at openjdk.org Thu May 25 21:40:18 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Thu, 25 May 2023 21:40:18 GMT Subject: Integrated: 8308907: ProblemList java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java on linux-x64 In-Reply-To: References: Message-ID: On Thu, 25 May 2023 21:21:18 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a few tests: > [JDK-8308907](https://bugs.openjdk.org/browse/JDK-8308907) ProblemList java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java on linux-x64 > [JDK-8308908](https://bugs.openjdk.org/browse/JDK-8308908) ProblemList javax/sound/sampled/Clip/ClipIsRunningAfterStop.java on linux-x64 > [JDK-8308909](https://bugs.openjdk.org/browse/JDK-8308909) ProblemList sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java on linux-x64 Marked as reviewed by mikael (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14163#pullrequestreview-1444684740 From dcubed at openjdk.org Thu May 25 21:40:19 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 25 May 2023 21:40:19 GMT Subject: Integrated: 8308907: ProblemList java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java on linux-x64 In-Reply-To: References: Message-ID: On Thu, 25 May 2023 21:31:54 GMT, Mikael Vidstedt wrote: >> Trivial fixes to ProblemList a few tests: >> [JDK-8308907](https://bugs.openjdk.org/browse/JDK-8308907) ProblemList java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java on linux-x64 >> [JDK-8308908](https://bugs.openjdk.org/browse/JDK-8308908) ProblemList javax/sound/sampled/Clip/ClipIsRunningAfterStop.java on linux-x64 >> [JDK-8308909](https://bugs.openjdk.org/browse/JDK-8308909) ProblemList sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java on linux-x64 > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the lightning fast review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14163#issuecomment-1563531582 From dcubed at openjdk.org Thu May 25 21:40:19 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 25 May 2023 21:40:19 GMT Subject: Integrated: 8308907: ProblemList java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java on linux-x64 In-Reply-To: References: Message-ID: <034abLsKYlMCdC0XW_pw3q43EJrjzot6We8DUNjfpNk=.8670fd2c-82a8-4ccf-a9db-da520002334e@github.com> On Thu, 25 May 2023 21:21:18 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a few tests: > [JDK-8308907](https://bugs.openjdk.org/browse/JDK-8308907) ProblemList java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java on linux-x64 > [JDK-8308908](https://bugs.openjdk.org/browse/JDK-8308908) ProblemList javax/sound/sampled/Clip/ClipIsRunningAfterStop.java on linux-x64 > [JDK-8308909](https://bugs.openjdk.org/browse/JDK-8308909) ProblemList sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java on linux-x64 This pull request has now been integrated. Changeset: ee321c70 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/ee321c70e57669fa88fb41afb6dc1832cfa36e71 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8308907: ProblemList java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java on linux-x64 8308908: ProblemList javax/sound/sampled/Clip/ClipIsRunningAfterStop.java on linux-x64 8308909: ProblemList sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java on linux-x64 Reviewed-by: mikael ------------- PR: https://git.openjdk.org/jdk/pull/14163 From aivanov at openjdk.org Thu May 25 22:52:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 25 May 2023 22:52:56 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: References: Message-ID: <2GB64uy9IDQZ19G42BbZ-8Og0fsOiXKezfxuazDoQSU=.04bd2e64-6266-48a1-b3b3-914786af473a@github.com> On Thu, 25 May 2023 17:47:59 GMT, Harshitha Onkar wrote: > > It saves the images to _the current directory_. When the test is run by jtreg, the current directory is the `scratch` directory. > > For me, the generated screenshot was being saved to the test folder, as I was running it as standalone test. Which is expected because you were running the test as a standalone test. Whatever the current directory is, the images are put in the current directory. The jtreg framework sets the current directory to `scratch`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14094#issuecomment-1563602553 From rmahajan at openjdk.org Fri May 26 01:18:02 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 26 May 2023 01:18:02 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v5] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> <5ZKvFHDZf3Ec5NUqnKHn37IqaWYysui5bkRLFQLt2yY=.4ccce055-1f55-4046-b216-c8ff3ce98809@github.com> <58Kg02u2XeyJ1e8sjdT8ov_jBaVEDqkABA8oNfZ1abA=.e6a97bd3-e5d1-4762-bba5-0bb2e55497d6@github.com> Message-ID: On Thu, 18 May 2023 23:00:25 GMT, Sergey Bylokhov wrote: >> Perhaps, this needs additional details. The size of checkbox and radio button is 13 as reported by Theme API for the standard DPI of 96. Being a prime number, 13 doesn't scale well, there's always fractional part unless the scale is whole. Thus, the scaled size never matches. >> >> As the result, `CachedPainter` seems to apply a scale to compensate for that ? whether we choose ceil or floor. The above formula gives better results. >> >> The entire thing should have been simpler: a `MultiResolutionImage` which paints the background according to the scale requested. Yet it proved to be not as simple. We're planning to look further into simplifying it if possible and, alternatively or in addition to, considering [dynamic layout based on graphics configuration](https://github.com/openjdk/jdk/pull/13701#discussion_r1187985627) as you suggested above. >> >> The current solution may be not perfect but it provides better rendering compared to what we have now: *the controls look crisp only on the main display*. > > But still why the size on the components are so different? is it really caused by one "pixel/unit" we requested from the native? So, basically for w,h =19 we calculate a DPI of 140 and Dimension d = getPartSize(getTheme(widget, dpi), part, state); at line 172 of ThemeReader.java call returns a part size of 13 x 13 provided by windows as it is closer to DPI=120 (for 125% scaling). While for w,h =20 we calculate a DPI of 147 and Dimension d = getPartSize(getTheme(widget, dpi), part, state); at line 172 of ThemeReader.java call returns a part size of 20 x 20 provided by windows as it is closer to DPI=144 (for 150% scaling). Thus part size calculated by us and provided by Windows matches and hence we see bigger properly rendered buttons while for the w,h=19 case we have 19x19 , while windows gives 13x13 and hence you see scaled down buttons with bad rendering. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1206133530 From mbaesken at openjdk.org Fri May 26 07:14:55 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 May 2023 07:14:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code In-Reply-To: References: Message-ID: On Thu, 25 May 2023 16:13:49 GMT, JoKern65 wrote: >> test/jdk/java/io/File/libGetXSpace.c line 128: >> >>> 126: #else >>> 127: struct statfs buf; >>> 128: int result = statfs((char*)chars, &buf); >> >> Is this working around a bug in IBM's declaration? >> >> Also, pre-existing, the cast seems really suspicious. The type of `chars` is `jchar*`, which is a >> sequence of 16bit characters. Does this actually work? If so, how? > > This is IBMs declaration of statfs > `extern int statfs(char *, struct statfs *);` > So the compiler will not accept a `const char*` > Indeed I do not know if this ever worked, but my change makes it not worse. Here is the documentation of statfs on AIX https://www.ibm.com/docs/en/aix/7.2?topic=s-statfs-fstatfs-statfs64-fstatfs64-ustat-subroutine (showing the IBM declaration Joachim told us) . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1206326207 From tr at openjdk.org Fri May 26 07:23:54 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 26 May 2023 07:23:54 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v6] In-Reply-To: References: Message-ID: <4Vs7QKG5SmFdiBJu4E5BqUIzQ-TTxHAfnxHfSz0eBzk=.6d32189c-a798-4598-a0f8-0ac3409eecab@github.com> > Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13828/files - new: https://git.openjdk.org/jdk/pull/13828/files/bb9356ec..beb200e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13828&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13828&range=04-05 Stats: 29 lines in 3 files changed: 3 ins; 21 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13828.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13828/head:pull/13828 PR: https://git.openjdk.org/jdk/pull/13828 From tr at openjdk.org Fri May 26 07:36:05 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 26 May 2023 07:36:05 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v5] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 16:29:13 GMT, Prasanta Sadhukhan wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 65: > >> 63: frame.setSize(300, 300); >> 64: frame.setLocation(20, 300); >> 65: frame.setLocationRelativeTo(null); > > it will override the previous setLocation so that can be removed.. Updated. > test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 103: > >> 101: robot.delay(500); >> 102: >> 103: EventQueue.invokeAndWait(() -> { > > why is it under EDT? you can make the variable volatile and remove EDT I have updated the variable, but still it has to be under EDT right? Since it is shared. > test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 118: > >> 116: } >> 117: >> 118: public static Point getLocation(Component co) throws RuntimeException { > > I guess you can remove this method and use `frame.getLocationOnScreen` instead Updated. > test/jdk/java/awt/Robot/RobotMoveMultiscreen.java line 44: > >> 42: public class RobotMoveMultiscreen { >> 43: static int x_dest = 20; >> 44: static int y_dest = 20; > > these are accessed in 2 threads, you need to make it volatile Updated. > test/jdk/java/awt/Robot/RobotMoveMultiscreen.java line 79: > >> 77: robot.waitForIdle(); >> 78: robot.mouseMove(x_dest+50, y_dest+50); >> 79: robot.delay(1000); > > I dont think we need to wait for 1sec after mouseMove, you can just have `waitForIdle` Updated. > test/jdk/java/awt/Scrollbar/ScrollbarKeyControlTest.java line 62: > >> 60: } >> 61: >> 62: public void init() throws Exception { > > you can move the contents into main Means, should I make everything static and then change the Listener's references? > test/jdk/java/awt/Scrollbar/ScrollbarKeyControlTest.java line 84: > >> 82: }); >> 83: robot = new Robot(); >> 84: testOneScrollbar(scrollbarV); > > you should need to add robot.delay(1000) after frame is visible before commencing test Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1206343117 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1206343821 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1206344028 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1206345886 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1206344201 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1206345515 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1206344479 From djelinski at openjdk.org Fri May 26 07:50:56 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 26 May 2023 07:50:56 GMT Subject: RFR: 8308286 Fix clang warnings in linux code In-Reply-To: References: Message-ID: On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov wrote: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. According to our docs, [clang is a supported compiler for Linux](https://github.com/openjdk/jdk/blob/master/doc/building.md#native-compiler-toolchain-requirements). Here's an example how warning exclusion is implemented today: https://github.com/openjdk/jdk/blob/master/make/modules/java.desktop/lib/Awt2dLibraries.gmk#L827 ------------- PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1563956337 From tr at openjdk.org Fri May 26 07:53:25 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 26 May 2023 07:53:25 GMT Subject: Integrated: 8306137: Open source several AWT ScrollPane related tests In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 17:39:17 GMT, Tejesh R wrote: > Open source few AWT ScrollPane related tests. This pull request has now been integrated. Changeset: 4becb7bc Author: Tejesh R URL: https://git.openjdk.org/jdk/commit/4becb7bcb6d8c24db5209dade77dbf2be057b2b0 Stats: 752 lines in 6 files changed: 752 ins; 0 del; 0 mod 8306137: Open source several AWT ScrollPane related tests Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/13621 From mbaesken at openjdk.org Fri May 26 07:55:56 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 May 2023 07:55:56 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code In-Reply-To: References: Message-ID: On Fri, 26 May 2023 07:12:07 GMT, Matthias Baesken wrote: >> This is IBMs declaration of statfs >> `extern int statfs(char *, struct statfs *);` >> So the compiler will not accept a `const char*` >> Indeed I do not know if this ever worked, but my change makes it not worse. > > Here is the documentation of statfs on AIX https://www.ibm.com/docs/en/aix/7.2?topic=s-statfs-fstatfs-statfs64-fstatfs64-ustat-subroutine (showing the IBM declaration Joachim told us) . > Also, pre-existing, the cast seems really suspicious. The type of `chars` is `jchar*`, which is a sequence of 16bit characters. Does this actually work? If so, how? Probably a jchar to char conversion would be needed for the array elements, maybe like this here (or is there a better utility function in the codebase) ? See jCharArrayToCKCharArray https://github.com/openjdk/jdk/blob/199b1bf5009120efd1fd37a1ddabc0c6fb84f62c/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c#L644 I am not aware of an AIX statfs for wchars but maybe I miss something. But it is a separate issue of Java_GetXSpace_getSpace0 anyway and should be handled in another bug. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1206370114 From psadhukhan at openjdk.org Fri May 26 08:13:10 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 26 May 2023 08:13:10 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v5] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 07:30:59 GMT, Tejesh R wrote: >> test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 103: >> >>> 101: robot.delay(500); >>> 102: >>> 103: EventQueue.invokeAndWait(() -> { >> >> why is it under EDT? you can make the variable volatile and remove EDT > > I have updated the variable, but still it has to be under EDT right? Since it is shared. No, you have made the variable volatile which indicates it can be sharable across threads, also there is no widgets being accessed so no need of EDT >> test/jdk/java/awt/Scrollbar/ScrollbarKeyControlTest.java line 62: >> >>> 60: } >>> 61: >>> 62: public void init() throws Exception { >> >> you can move the contents into main > > Means, should I make everything static and then change the Listener's references? ok. I guess this should be good enough as it has listener ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1206367141 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1206390244 From psadhukhan at openjdk.org Fri May 26 08:13:06 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 26 May 2023 08:13:06 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v6] In-Reply-To: <4Vs7QKG5SmFdiBJu4E5BqUIzQ-TTxHAfnxHfSz0eBzk=.6d32189c-a798-4598-a0f8-0ac3409eecab@github.com> References: <4Vs7QKG5SmFdiBJu4E5BqUIzQ-TTxHAfnxHfSz0eBzk=.6d32189c-a798-4598-a0f8-0ac3409eecab@github.com> Message-ID: On Fri, 26 May 2023 07:23:54 GMT, Tejesh R wrote: >> Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Also confirm mach5 is green with this change test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 64: > 62: frame.setTitle(nm); > 63: frame.setSize(300, 300); > 64: frame.setLocation(20, 300); I was thinking it would be better to keep `setLocationRelativeTo` than specific location, it may have issue with linux where we have taskbar at left.. ------------- PR Review: https://git.openjdk.org/jdk/pull/13828#pullrequestreview-1445485554 PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1206394189 From tr at openjdk.org Fri May 26 08:25:05 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 26 May 2023 08:25:05 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v7] In-Reply-To: References: Message-ID: <7zvpF_zfH5u516Cmk54-1qVJpFXn7WeHJI8od-CdXls=.6fcf4aa0-ce35-4ffe-b23c-ec5bd373c604@github.com> > Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13828/files - new: https://git.openjdk.org/jdk/pull/13828/files/beb200e2..515726a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13828&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13828&range=05-06 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13828.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13828/head:pull/13828 PR: https://git.openjdk.org/jdk/pull/13828 From tr at openjdk.org Fri May 26 08:25:08 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 26 May 2023 08:25:08 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v6] In-Reply-To: References: <4Vs7QKG5SmFdiBJu4E5BqUIzQ-TTxHAfnxHfSz0eBzk=.6d32189c-a798-4598-a0f8-0ac3409eecab@github.com> Message-ID: <6ASGLmAjBNlkaPAWg7-j3Y8b9b0OFEDI04iGOEdMkC8=.905ea682-2925-4e3d-ae0f-6383e0cdd140@github.com> On Fri, 26 May 2023 08:09:06 GMT, Prasanta Sadhukhan wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 64: > >> 62: frame.setTitle(nm); >> 63: frame.setSize(300, 300); >> 64: frame.setLocation(20, 300); > > I was thinking it would be better to keep `setLocationRelativeTo` than specific location, it may have issue with linux where we have taskbar at left.. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1206405905 From tr at openjdk.org Fri May 26 08:25:09 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 26 May 2023 08:25:09 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v6] In-Reply-To: <6ASGLmAjBNlkaPAWg7-j3Y8b9b0OFEDI04iGOEdMkC8=.905ea682-2925-4e3d-ae0f-6383e0cdd140@github.com> References: <4Vs7QKG5SmFdiBJu4E5BqUIzQ-TTxHAfnxHfSz0eBzk=.6d32189c-a798-4598-a0f8-0ac3409eecab@github.com> <6ASGLmAjBNlkaPAWg7-j3Y8b9b0OFEDI04iGOEdMkC8=.905ea682-2925-4e3d-ae0f-6383e0cdd140@github.com> Message-ID: On Fri, 26 May 2023 08:17:55 GMT, Tejesh R wrote: >> test/jdk/java/awt/PopupMenu/PopupMenuStayOpen.java line 64: >> >>> 62: frame.setTitle(nm); >>> 63: frame.setSize(300, 300); >>> 64: frame.setLocation(20, 300); >> >> I was thinking it would be better to keep `setLocationRelativeTo` than specific location, it may have issue with linux where we have taskbar at left.. > > Updated. Sure, will test it in CI before I integrate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13828#discussion_r1206406823 From mkartashev at openjdk.org Fri May 26 08:26:33 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Fri, 26 May 2023 08:26:33 GMT Subject: RFR: 8308875: java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java failed with 'Cannot invoke "sun.awt.X11GraphicsDevice.getInsets()" because "device" is null' Message-ID: 8308875 is a regression after the recent [fix for 8305578](https://github.com/openjdk/jdk/commit/d7245f70) that effectively undid a part of [another, older, change](https://github.com/openjdk/jdk/commit/40f6d697d25293282e3d3ee695ef8cd9a5494799), the one made to fix [8233573](https://bugs.openjdk.org/browse/JDK-8233573). This commits brings that part back and passes the test `java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java` on Linux, so the test is also removed from the ProblemList file. ------------- Commit messages: - 8308875: java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java failed with 'Cannot invoke "sun.awt.X11GraphicsDevice.getInsets()" because "device" is null' Changes: https://git.openjdk.org/jdk/pull/14170/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14170&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308875 Stats: 15 lines in 2 files changed: 5 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14170/head:pull/14170 PR: https://git.openjdk.org/jdk/pull/14170 From duke at openjdk.org Fri May 26 08:31:46 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 26 May 2023 08:31:46 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: > When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". > Some of those are in shared codebase and could be addressed by small adjustments. > A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. JoKern65 has updated the pull request incrementally with one additional commit since the last revision: forgotton _ ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14146/files - new: https://git.openjdk.org/jdk/pull/14146/files/2699fdce..da38fb2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14146&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14146&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14146/head:pull/14146 PR: https://git.openjdk.org/jdk/pull/14146 From duke at openjdk.org Fri May 26 10:12:55 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 26 May 2023 10:12:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > forgotton _ Here are the reasons for the disabled warnings in make/modules/java.base/Lib.gmk DISABLED_WARNINGS_clang_aix_DefaultProxySelector.c := deprecated-non-prototype, \ DISABLED_WARNINGS_clang_aix_NetworkInterface.c := gnu-pointer-arith, \ DISABLED_WARNINGS_clang_aix_UnixNativeDispatcher.c := undef, \ src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error); ^ src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] end = (void *)nddp + size; ~~~~~~~~~~~~ ^ src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef] #elif _ALLBSD_SOURCE ^ ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564143664 From tr at openjdk.org Fri May 26 10:16:00 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 26 May 2023 10:16:00 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v7] In-Reply-To: <7zvpF_zfH5u516Cmk54-1qVJpFXn7WeHJI8od-CdXls=.6fcf4aa0-ce35-4ffe-b23c-ec5bd373c604@github.com> References: <7zvpF_zfH5u516Cmk54-1qVJpFXn7WeHJI8od-CdXls=.6fcf4aa0-ce35-4ffe-b23c-ec5bd373c604@github.com> Message-ID: On Fri, 26 May 2023 08:25:05 GMT, Tejesh R wrote: >> Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments CI testing is green after the updated fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13828#issuecomment-1564157996 From duke at openjdk.org Fri May 26 10:20:58 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 26 May 2023 10:20:58 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com> On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > forgotton _ Here are the reasons for the disabled warnings in make/modules/java.base/lib/CoreLibraries.gmk DISABLED_WARNINGS_clang_aix_ProcessHandleImpl_unix.c := sign-compare, \ DISABLED_WARNINGS_clang_aix := gnu-pointer-arith, \ DISABLED_WARNINGS_clang := gnu-pointer-arith format-nonliteral deprecated-non-prototype, \ src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long' if (ret < sizeof(psinfo_t)) { ^ src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith] addr < p->ldinfo_textorg + p->ldinfo_textsize) { ~~~~~~~~~~~~~~~~~ ^ src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype] void ZLIB_INTERNAL inflate_fast(strm, start) ^ src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] vfprintf(stderr, fmt, vl); ^~~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564165195 From psadhukhan at openjdk.org Fri May 26 10:21:02 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 26 May 2023 10:21:02 GMT Subject: RFR: 8306812: Open source several AWT Miscellaneous tests [v7] In-Reply-To: <7zvpF_zfH5u516Cmk54-1qVJpFXn7WeHJI8od-CdXls=.6fcf4aa0-ce35-4ffe-b23c-ec5bd373c604@github.com> References: <7zvpF_zfH5u516Cmk54-1qVJpFXn7WeHJI8od-CdXls=.6fcf4aa0-ce35-4ffe-b23c-ec5bd373c604@github.com> Message-ID: On Fri, 26 May 2023 08:25:05 GMT, Tejesh R wrote: >> Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13828#pullrequestreview-1445906570 From mbaesken at openjdk.org Fri May 26 10:24:55 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 May 2023 10:24:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 10:05:56 GMT, JoKern65 wrote: > src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef] > #elif _ALLBSD_SOURCE > Should probably better be `#elif defined(_ALLBSD_SOURCE)` ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564168769 From mbaesken at openjdk.org Fri May 26 10:47:55 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 May 2023 10:47:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com> References: <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com> Message-ID: On Fri, 26 May 2023 10:18:37 GMT, JoKern65 wrote: > src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] vfprintf(stderr, fmt, vl); ^~~ We disable this warning too for clang on all platforms in BUILD_LIBJLI ( DISABLED_WARNINGS_clang := **format-nonlitera**l deprecated-non-prototype, \ ), so I think we should do it the same way for BUILD_LIBJLI_STATIC on AIX. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564193886 From tr at openjdk.org Fri May 26 10:54:12 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 26 May 2023 10:54:12 GMT Subject: Integrated: 8306812: Open source several AWT Miscellaneous tests In-Reply-To: References: Message-ID: On Fri, 5 May 2023 09:54:36 GMT, Tejesh R wrote: > Open source few AWT Miscellaneous ( Panel, Popup, robot and scrollbar) tests. This pull request has now been integrated. Changeset: c494770c Author: Tejesh R URL: https://git.openjdk.org/jdk/commit/c494770ca0662d95ed35f9244a7a9e012aab61a7 Stats: 515 lines in 5 files changed: 515 ins; 0 del; 0 mod 8306812: Open source several AWT Miscellaneous tests Reviewed-by: psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/13828 From mbaesken at openjdk.org Fri May 26 10:55:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 May 2023 10:55:02 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com> References: <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com> Message-ID: On Fri, 26 May 2023 10:18:37 GMT, JoKern65 wrote: > Here are the reasons for the disabled warnings in make/modules/java.base/lib/CoreLibraries.gmk DISABLED_WARNINGS_clang_aix_ProcessHandleImpl_unix.c := sign-compare, DISABLED_WARNINGS_clang_aix := gnu-pointer-arith, DISABLED_WARNINGS_clang := gnu-pointer-arith format-nonliteral deprecated-non-prototype, \ > > src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long' if (ret < sizeof(psinfo_t)) { ^ > `fread` returns a `size_t ` on Linux and AIX, could you please check Mac/BSD too ? https://github.com/openjdk/jdk/blob/d3b9b364da8c11c9b4dd14a6451a7b24f41202e7/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c#L636 We should probably change to size_t ret (from type int), then the warning would not occur, correct ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564207011 From duke at openjdk.org Fri May 26 12:19:55 2023 From: duke at openjdk.org (JoKern65) Date: Fri, 26 May 2023 12:19:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > forgotton _ Here are the reasons for the disabled warnings in make/modules/java.desktop/lib/Awt2dLibraries.gmk /data/d042520/pr/jdk/src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h:53:12: error: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C2x, conflicting with a previous declaration [-Werror,-Wdeprecated-non-prototype] extern int XShmQueryExtension(); ^ /usr/include/X11/extensions/XShm.h:91:6: note: conflicting prototype is here Bool XShmQueryExtension( ^ solved by adding line (generic, because several source files are involved) DISABLED_WARNINGS_clang_aix := deprecated-non-prototype, \ src/java.desktop/unix/native/libawt_xawt/xawt/awt_Taskbar.c:158:11: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] if (m = fp_unity_launcher_entry_get_quicklist(entry)) { ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ solved by adding line DISABLED_WARNINGS_clang_aix_awt_Taskbar.c := parentheses, \ src/java.desktop/share/native/common/java2d/opengl/OGLPaints.c:581:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral] snprintf(cycleCode, sizeof(cycleCode), noCycleCode, texCoordCalcCode); ^~~~~~~~~~~ solved by adding line DISABLED_WARNINGS_clang_aix_OGLPaints.c := format-nonliteral, \ src/java.desktop/share/native/common/java2d/opengl/OGLBufImgOps.c:153:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral] snprintf(finalSource, sizeof(finalSource), convolveShaderSource, ^~~~~~~~~~~~~~~~~~~~ solved by adding line DISABLED_WARNINGS_clang_aix_OGLBufImgOps.c := format-nonliteral, \ src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1095:41: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses] if ((synth_state & MOUSE_OVER) != 0 && (synth_state & PRESSED) == 0 || ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1180:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] if (init_result = (NULL == gtk2_widgets[_GTK_CHECK_MENU_ITEM_TYPE])) ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ solved by adding line DISABLED_WARNINGS_clang_aix_gtk2_interface.c := parentheses logical-op-parentheses, \ src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:903:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] if (init_result = (NULL == gtk3_widgets[_GTK_BUTTON_TYPE])) ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ solved by adding line DISABLED_WARNINGS_clang_aix_gtk3_interface.c := parentheses, \ src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c:87:26: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] if (pendingException = (*env)->ExceptionOccurred(env)) { ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ solved by adding line DISABLED_WARNINGS_clang_aix_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \ src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c:1969:32: error: comparison of integers of different signs: 'Window' (aka 'unsigned long') and 'jlong' (aka 'long') [-Werror,-Wsign-compare] if (currentFocusWindow != w) { ~~~~~~~~~~~~~~~~~~ ^ ~ solved by adding line DISABLED_WARNINGS_clang_aix_awt_InputMethod.c := sign-compare, \ Here is the reason for the disabled warning in make/modules/java.security.jgss/Lib.gmk src/java.security.jgss/share/native/libj2gss/NativeUtil.h:30: /data/d042520/pr/jdk/src/java.security.jgss/share/native/libj2gss/gssapi.h:48:5: error: 'TARGET_OS_MAC' is not defined, evaluates to 0 [-Werror,-Wundef] #if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || defined(__i386__) || defined(__x86_64__)) ^ make/modules/java.security.jgss/Lib.gmk add line DISABLED_WARNINGS_clang_aix := undef, \ Here is the reason for the disabled warning in make/modules/jdk.jdwp.agent/Lib.gmk src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c:718:33: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces] struct in6_addr mappedAny = IN6ADDR_ANY_INIT; ^~~~~~~~~~~~~~~~ /usr/include/netinet/in.h:454:32: note: expanded from macro 'IN6ADDR_ANY_INIT' #define IN6ADDR_ANY_INIT {0, 0, 0, 0} solved by adding line DISABLED_WARNINGS_clang_aix := missing-braces, \ ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564303459 PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564304989 PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564306115 From mdoerr at openjdk.org Fri May 26 13:37:55 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 26 May 2023 13:37:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > forgotton _ Just a side note: The warning elimination is new for AIX compilers. We had given it up at earlier times: https://bugs.openjdk.org/browse/JDK-8202325 I still appreciate if we can get warning free and it makes sense to review all of them. But, I wouldn't require it for JDK21. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564406986 From aivanov at openjdk.org Fri May 26 14:02:57 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 26 May 2023 14:02:57 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: <-wdzUmGqS7uN5Mrs3xaw20DKKeifUXqmAnDkWS0E0rM=.29ceb60a-ed4f-41c0-af74-4585ee9fe956@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> <9CYm1ES0qMrb-t6K6q6xWqB9SK8TmF91Mg7Ccp-euB4=.18b0c646-55d5-4daa-93d0-476045e65d68@github.com> <-wdzUmGqS7uN5Mrs3xaw20DKKeifUXqmAnDkWS0E0rM=.29ceb60a-ed4f-41c0-af74-4585ee9fe956@github.com> Message-ID: On Thu, 25 May 2023 13:58:17 GMT, Tejesh R wrote: >> As for other Look-and-Feels, `isFileSystem` is used for the same purpose that it's used in the code you're modifying: if a selected object in the list is a file system object (a directory), the text field to the path of the selected object; otherwise, set the text field to `null`. > > Ok, then let me work the proposed fix. As per the proposed fix, `FileSystemView.isFileSystem ` has to return if its fileSystem or not......? What about .ink? No, what I'm proposing is to modify `isLink` only so that it returns `true` if and only if the file is a Windows shortcut `.lnk` file. --- Another option is to modify `isFileSystem` so that it returns `true` for all filesystem objects, excluding the added condition that it should be not a link to directory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1206832172 From aivanov at openjdk.org Fri May 26 14:09:58 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 26 May 2023 14:09:58 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> <9CYm1ES0qMrb-t6K6q6xWqB9SK8TmF91Mg7Ccp-euB4=.18b0c646-55d5-4daa-93d0-476045e65d68@github.com> <-wdzUmGqS7uN5Mrs3xaw20DKKeifUXqmAnDkWS0E0rM=.29ceb60a-ed4f-41c0-af74-4585ee9fe956@github.com> Message-ID: On Fri, 26 May 2023 14:00:16 GMT, Alexey Ivanov wrote: > Another option is to modify `isFileSystem` so that it returns `true` for all filesystem objects, excluding the added condition that it should be not a link to directory. I assume this is required to ensure `JFileChooser` doesn't return `.lnk` file when in directory-only selection mode, and probably doesn't report is directory is selected when you select `.lnk` file. Double-clicking the `.lnk` file resolves to its target, then the directory can be safely returned. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1206841598 From tr at openjdk.org Fri May 26 14:29:56 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 26 May 2023 14:29:56 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> <9CYm1ES0qMrb-t6K6q6xWqB9SK8TmF91Mg7Ccp-euB4=.18b0c646-55d5-4daa-93d0-476045e65d68@github.com> <-wdzUmGqS7uN5Mrs3xaw20DKKeifUXqmAnDkWS0E0rM=.29ceb60a-ed4f-41c0-af74-4585ee9fe956@github.com> Message-ID: On Fri, 26 May 2023 14:07:12 GMT, Alexey Ivanov wrote: >> No, what I'm proposing is to modify `isLink` only so that it returns `true` if and only if the file is a Windows shortcut `.lnk` file. >> >> --- >> >> Another option is to modify `isFileSystem` so that it returns `true` for all filesystem objects, excluding the added condition that it should be not a link to directory. > >> Another option is to modify `isFileSystem` so that it returns `true` for all filesystem objects, excluding the added condition that it should be not a link to directory. > > I assume this is required to ensure `JFileChooser` doesn't return `.lnk` file when in directory-only selection mode, and probably doesn't report is directory is selected when you select `.lnk` file. Double-clicking the `.lnk` file resolves to its target, then the directory can be safely returned. So now two modifications are required. 1. Modify `isLink` of win32ShellFolder class to return true only if its `.lnk`. 2. `isFileSystem` of FileSystemView to return true only if its valid fileSystem, except `isLink` which actually solves the problem of `isFileSystem ` returning false for links (hard/soft). Am I right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1206871175 From aivanov at openjdk.org Fri May 26 14:32:57 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 26 May 2023 14:32:57 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> <9CYm1ES0qMrb-t6K6q6xWqB9SK8TmF91Mg7Ccp-euB4=.18b0c646-55d5-4daa-93d0-476045e65d68@github.com> <-wdzUmGqS7uN5Mrs3xaw20DKKeifUXqmAnDkWS0E0rM=.29ceb60a-ed4f-41c0-af74-4585ee9fe956@github.com> Message-ID: On Fri, 26 May 2023 14:27:22 GMT, Tejesh R wrote: > So now two modifications are required. > > 1. Modify `isLink` of win32ShellFolder class to return true only if its `.lnk`. This should be enough to fix this bug. And this should enable the support for Windows junctions too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1206875617 From tr at openjdk.org Fri May 26 14:42:08 2023 From: tr at openjdk.org (Tejesh R) Date: Fri, 26 May 2023 14:42:08 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> <9CYm1ES0qMrb-t6K6q6xWqB9SK8TmF91Mg7Ccp-euB4=.18b0c646-55d5-4daa-93d0-476045e65d68@github.com> <-wdzUmGqS7uN5Mrs3xaw20DKKeifUXqmAnDkWS0E0rM=.29ceb60a-ed4f-41c0-af74-4585ee9fe956@github.com> Message-ID: On Fri, 26 May 2023 14:30:29 GMT, Alexey Ivanov wrote: >> So now two modifications are required. >> 1. Modify `isLink` of win32ShellFolder class to return true only if its `.lnk`. >> 2. `isFileSystem` of FileSystemView to return true only if its valid fileSystem, except `isLink` which actually solves the problem of `isFileSystem ` returning false for links (hard/soft). >> Am I right? > >> So now two modifications are required. >> >> 1. Modify `isLink` of win32ShellFolder class to return true only if its `.lnk`. > > This should be enough to fix this bug. > > This should enable the support for Windows junctions too. > >> 2. isFileSystem of FileSystemView to return true only if its valid fileSystem, except isLink which actually solves the problem of isFileSystem returning false for links (hard/soft). > > This is automatically resolved by the first change. > > Currently, `isFileSystem` returns `false` when both `isLink` and `isDirectory` return `true`, which is the case for symbolic links and junctions. > > Then you have to remove the additional conditions that you added in [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966). Yeah, this should do the work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1206889350 From aivanov at openjdk.org Fri May 26 14:53:56 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 26 May 2023 14:53:56 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> <9CYm1ES0qMrb-t6K6q6xWqB9SK8TmF91Mg7Ccp-euB4=.18b0c646-55d5-4daa-93d0-476045e65d68@github.com> <-wdzUmGqS7uN5Mrs3xaw20DKKeifUXqmAnDkWS0E0rM=.29ceb60a-ed4f-41c0-af74-4585ee9fe956@github.com> Message-ID: <0Jvp75AGE6H0V9CRnUpH4y5mRgmXD0WWaMBLMirJ3jQ=.81538d8a-d1b1-4c8f-835a-1e85723a4b5f@github.com> On Fri, 26 May 2023 14:38:54 GMT, Tejesh R wrote: >>> So now two modifications are required. >>> >>> 1. Modify `isLink` of win32ShellFolder class to return true only if its `.lnk`. >> >> This should be enough to fix this bug. >> >> This should enable the support for Windows junctions too. >> >>> 2. isFileSystem of FileSystemView to return true only if its valid fileSystem, except isLink which actually solves the problem of isFileSystem returning false for links (hard/soft). >> >> This is automatically resolved by the first change. >> >> Currently, `isFileSystem` returns `false` when both `isLink` and `isDirectory` return `true`, which is the case for symbolic links and junctions. >> >> Then you have to remove the additional conditions that you added in [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966). > > Yeah, this should do the work. To re-iterate: > Currently, `isFileSystem` returns `false` when both `isLink` and `isDirectory` return `true`, which is the case for symbolic links and junctions. This is the root cause why symbolic links need special handling. So, if you make `isLink` return `false` for symbolic links and junctions, `isFileSystem` will return `true`. That's what we want: neither symbolic links nor junctions need special handling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1206905684 From mkartashev at openjdk.org Fri May 26 15:36:00 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Fri, 26 May 2023 15:36:00 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: References: Message-ID: <1wgLMR5-P0FK3ZAoncmfyyyZrorua3lb9nyx8-zAO3Q=.bbc72712-af1e-41d8-896d-3391b8455e77@github.com> On Thu, 25 May 2023 16:29:39 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > rework token storage Tried running this version on my machine (Ubuntu 22.04, two displays with 100% and 200% scaling). A few observations: 1. I couldn't get any of the screenshot tests working through `jtreg` (screenshots are all black, no permission is ever asked). Does anybody know how to do that properly? Can this be made to work out of the box? 2. Running manually is OK for the most part except for some tests in certain configurations: * Test `test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java` consistently fails with `sun.java2d.uiScale` other than `1`. For example, $ java -Dsun.java2d.uiScale=3 ScreenCaptureGtkTest.java Creating screen capture of java.awt.Rectangle[x=89,y=99,width=100,height=100] Exception in thread "main" java.lang.SecurityException: Screen Capture in the selected area was not allowed at java.desktop/sun.awt.screencast.ScreencastHelper.getRGBPixels(ScreencastHelper.java:161) at java.desktop/sun.awt.X11.XRobotPeer.getRGBPixels(XRobotPeer.java:139) at java.desktop/java.awt.Robot.createCompatibleImage(Robot.java:606) at java.desktop/java.awt.Robot.createScreenCapture(Robot.java:477) at ScreenCaptureGtkTest.captureImageOf(ScreenCaptureGtkTest.java:130) at ScreenCaptureGtkTest.main(ScreenCaptureGtkTest.java:96) and this is when I allow both screens to be captured in the system dialog that appears after the start of the test. The same failure can be observed with `java -Dsun.java2d.uiScale=2 HiDPIRobotScreenCaptureTest.java`. Both tests hang after throwing those exceptions, by the way. * The same test fails in a different fashion with `-Djdk.gtk.version=2`. For example: $ java -Djdk.gtk.version=2 -Dsun.java2d.uiScale=1 ScreenCaptureGtkTest.java WARNING: the GTK 2 library is deprecated and its support will be removed in a future release Gtk-Message: 19:17:15.122: Failed to load module "canberra-gtk-module" Creating screen capture of java.awt.Rectangle[x=89,y=99,width=100,height=100] Could not load native libraries for ScreencastHelper Checking color at 139, 149 to be equal to java.awt.Color[r=0,g=255,b=0]... Mismatch: found java.awt.Color[r=0,g=0,b=0] instead Check image.png Exception in thread "main" java.lang.RuntimeException: Wrong screen pixel color at ScreenCaptureGtkTest.checkPixelColors(ScreenCaptureGtkTest.java:115) at ScreenCaptureGtkTest.main(ScreenCaptureGtkTest.java:100) * Test `test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureResolutionTest.java` fails and hangs like so: $ java ScreenCaptureResolutionTest.java Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Exception while validating ScreenCapture at ScreenCaptureResolutionTest$2.run(ScreenCaptureResolutionTest.java:75) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742) at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1564568586 From azvegint at openjdk.org Fri May 26 15:54:56 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 26 May 2023 15:54:56 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: <1wgLMR5-P0FK3ZAoncmfyyyZrorua3lb9nyx8-zAO3Q=.bbc72712-af1e-41d8-896d-3391b8455e77@github.com> References: <1wgLMR5-P0FK3ZAoncmfyyyZrorua3lb9nyx8-zAO3Q=.bbc72712-af1e-41d8-896d-3391b8455e77@github.com> Message-ID: On Fri, 26 May 2023 15:32:41 GMT, Maxim Kartashev wrote: > Tried running this version on my machine (Ubuntu 22.04, two displays with 100% and 200% scaling). A few observations: > > 1. I couldn't get any of the screenshot tests working through `jtreg` (screenshots are all black, no permission is ever asked). Does anybody know how to do that properly? Can this be made to work out of the box? jtreg strips env variables down to a very few. so providing following options should solve the issue: `jtreg -ea -e:DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS -e:WAYLAND_DISPLAY=$WAYLAND_DISPLAY ...` This is already addressed in jtreg 7.3 by [openjdk/jtreg/pull/152](https://github.com/openjdk/jtreg/pull/152) > 2. Running manually is OK for the most part except for some tests in certain configurations: > > > * Test `test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java` consistently fails with `sun.java2d.uiScale` other than `1`. For example, > > > ``` > $ java -Dsun.java2d.uiScale=3 ScreenCaptureGtkTest.java > Creating screen capture of java.awt.Rectangle[x=89,y=99,width=100,height=100] > Exception in thread "main" java.lang.SecurityException: Screen Capture in the selected area was not allowed > at java.desktop/sun.awt.screencast.ScreencastHelper.getRGBPixels(ScreencastHelper.java:161) > at java.desktop/sun.awt.X11.XRobotPeer.getRGBPixels(XRobotPeer.java:139) > at java.desktop/java.awt.Robot.createCompatibleImage(Robot.java:606) > at java.desktop/java.awt.Robot.createScreenCapture(Robot.java:477) > at ScreenCaptureGtkTest.captureImageOf(ScreenCaptureGtkTest.java:130) > at ScreenCaptureGtkTest.main(ScreenCaptureGtkTest.java:96) > ``` > > and this is when I allow both screens to be captured in the system dialog that appears after the start of the test. The same failure can be observed with `java -Dsun.java2d.uiScale=2 HiDPIRobotScreenCaptureTest.java`. Both tests hang after throwing those exceptions, by the way. > I'll take a look. > * The same test fails in a different fashion with `-Djdk.gtk.version=2`. For example: This is intended, GTK2 is not supported and deprecated for removal. [JDK-8280031](https://bugs.openjdk.org/browse/JDK-8280031) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1564594406 From mkartashev at openjdk.org Fri May 26 16:16:00 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Fri, 26 May 2023 16:16:00 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 16:29:39 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > rework token storage > This is already addressed in jtreg 7.3 by https://github.com/openjdk/jtreg/pull/152 Thanks for the info! > This is intended, GTK2 is not supported and deprecated for removal. [JDK-8280031](https://bugs.openjdk.org/browse/JDK-8280031) That's fine, but the test still fails: Exception in thread "main" java.lang.RuntimeException: Wrong screen pixel color Deprecated shouldn't mean dysfunctional, so perhaps remove the line * @run main/othervm -Djdk.gtk.version=2 -Dsun.java2d.uiScale=1 ScreenCaptureGtkTest from the test if there's no intention to make it work even (and especially) in the future. It will always fail on XWayland. Or, if removing is hard for some reason, make it conditional and execute this test only in the pure X environment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1564621611 From stuefe at openjdk.org Fri May 26 17:01:57 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 26 May 2023 17:01:57 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 18:18:43 GMT, Martin Doerr wrote: >> src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47: >> >>> 45: #undef malloc >>> 46: extern void *malloc(size_t) asm("vec_malloc"); >>> 47: #endif >> >> Wow! And I don't mean that in a good way. I'm not questioning whether this is correct, just commenting >> on how crazy it seems that such a thing might be needed. > > The crazy thing is that `malloc` is defined! That means all places where we use the term malloc are getting replaced without such a workaround. (E.g. for log tags.) So, we do this only for malloc? Not for calloc, posix_memalign, realloc etc? What about free? As ugly as defining malloc is (and I remember QADRT), I hesitate about removing that define. Removing that define and hard-coding it here assumes 1) our replacement is equivalent (ok, easy to check) 2) it will always be equivalent in future AIX versions 3) pointers it returns work with the unchanged free() and realloc() the system provides, and will always do so. I don't know... I would not do this just to get rid of a warning. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1207078176 From honkar at openjdk.org Fri May 26 18:37:56 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 26 May 2023 18:37:56 GMT Subject: RFR: 8296920: Regression Test DialogOrient.java fails on MacOS In-Reply-To: References: Message-ID: On Fri, 12 May 2023 09:03:07 GMT, Prasanta Sadhukhan wrote: > Test was failing with PrinterException: Wrong Orientation since printing was done with default orientation. > Fix is made to set the printable with correct PageFormat > > It was not seen prior to [JDK-8262731](https://bugs.openjdk.org/browse/JDK-8262731) probably because the exception was being swallowed.. This can be taken up as a separate issue - The Standard Test Machinery can be removed and PassFailJFrame framework can be used to clean-up this test. Marked as reviewed by honkar (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13950#pullrequestreview-1446758180 PR Review: https://git.openjdk.org/jdk/pull/13950#pullrequestreview-1446765203 From dnguyen at openjdk.org Fri May 26 18:52:55 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 26 May 2023 18:52:55 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: <2GB64uy9IDQZ19G42BbZ-8Og0fsOiXKezfxuazDoQSU=.04bd2e64-6266-48a1-b3b3-914786af473a@github.com> References: <2GB64uy9IDQZ19G42BbZ-8Og0fsOiXKezfxuazDoQSU=.04bd2e64-6266-48a1-b3b3-914786af473a@github.com> Message-ID: On Thu, 25 May 2023 22:50:15 GMT, Alexey Ivanov wrote: > > > It saves the images to _the current directory_. When the test is run by jtreg, the current directory is the `scratch` directory. > > > > > > For me, the generated screenshot was being saved to the test folder, as I was running it as standalone test. > > Which is expected because you were running the test as a standalone test. Whatever the current directory is, the images are put in the current directory. The jtreg framework sets the current directory to `scratch`. I think the mixup is similar to what I implemented for my test ([https://github.com/openjdk/jdk/pull/7310](https://github.com/openjdk/jdk/pull/7310)) when trying to save an image. I was initially advised to set a testDir path to save the image to. But it sounds like it's not needed here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14094#issuecomment-1564794192 From honkar at openjdk.org Fri May 26 18:58:57 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 26 May 2023 18:58:57 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: References: Message-ID: On Thu, 25 May 2023 11:24:42 GMT, Alexey Ivanov wrote: > There could be multiple files. In fact, I question the need for a modal dialog confirming that the operation completed successfully. If an error occurs, a modal dialog is a good way of notifying. If no error occurs, the message is somewhat redundant. > > If the displayed message isn't modal, like a tooltip or a notification which disappears automatically after a certain time, it could be better appreciated. But it's harder to implement. > > What could be helpful though is an option to open the current directory in File Explorer, Finder? to allow viewing the collected screenshots. It's more helpful than displaying file names, isn't it? We can keep it as it is now or show message dialog only on failure, both sound okay. Maybe the File explorer and notification can be explored later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14094#issuecomment-1564799601 From honkar at openjdk.org Fri May 26 18:59:00 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 26 May 2023 18:59:00 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: <9fZwcg7-Tdm7naKW5dPxJAFPdcTKso35SVV7tHz-jQU=.04193ab7-23d2-4cf6-8f0d-788dad78b57d@github.com> References: <9fZwcg7-Tdm7naKW5dPxJAFPdcTKso35SVV7tHz-jQU=.04193ab7-23d2-4cf6-8f0d-788dad78b57d@github.com> Message-ID: On Wed, 24 May 2023 19:31:07 GMT, Alexey Ivanov wrote: >> 1) Used builder pattern >> 2) Tested AWT tests and it passed > > test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 306: > >> 304: .forEach(PassFailJFrame::captureScreen); >> 305: } >> 306: > > Maybe use `switch` statement with a `default` case which throws an exception rather than shows success message. (`if else if else` will also do.) > > Yeah, it's a private method yet it's better to handle an unexpected value. I agree switch statement could be used here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14094#discussion_r1207195923 From dnguyen at openjdk.org Fri May 26 19:03:54 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 26 May 2023 19:03:54 GMT Subject: RFR: 8296920: Regression Test DialogOrient.java fails on MacOS In-Reply-To: References: Message-ID: On Fri, 12 May 2023 09:03:07 GMT, Prasanta Sadhukhan wrote: > Test was failing with PrinterException: Wrong Orientation since printing was done with default orientation. > Fix is made to set the printable with correct PageFormat > > It was not seen prior to [JDK-8262731](https://bugs.openjdk.org/browse/JDK-8262731) probably because the exception was being swallowed.. Fix makes sense as the landscape var wasn't even used prior, which doesn't make sense as to why it was added in the first place. I tested with and without the change on my local MacOS machine and it now passes. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/13950#pullrequestreview-1446797969 From honkar at openjdk.org Fri May 26 19:33:56 2023 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 26 May 2023 19:33:56 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: <9fZwcg7-Tdm7naKW5dPxJAFPdcTKso35SVV7tHz-jQU=.04193ab7-23d2-4cf6-8f0d-788dad78b57d@github.com> References: <9fZwcg7-Tdm7naKW5dPxJAFPdcTKso35SVV7tHz-jQU=.04193ab7-23d2-4cf6-8f0d-788dad78b57d@github.com> Message-ID: On Wed, 24 May 2023 19:32:52 GMT, Alexey Ivanov wrote: >> 1) Used builder pattern >> 2) Tested AWT tests and it passed > > test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 309: > >> 307: JOptionPane.showMessageDialog(frame, "Screen Captured " + >> 308: "Successfully", "Screen Capture", >> 309: JOptionPane.INFORMATION_MESSAGE); > > Suggestion: > > JOptionPane.showMessageDialog(frame, > "Screen captured successfully", > "Screen Capture", > JOptionPane.INFORMATION_MESSAGE); > > It's better not to split strings unnecessarily. The messages usually use regular capitalisation as opposed to title capitalisation. @aivanov-jdk, @lawrence-andrew > If the displayed message isn't modal, like a tooltip or a notification which disappears automatically after a certain time, it could be better appreciated. But it's harder to implement. We could use Timer for disappearing messages, but might be an overkill here. JOptionPane pane = new JOptionPane("Screen capture successful", JOptionPane.INFORMATION_MESSAGE); final JDialog dialog = pane.createDialog("Screen Capture"); Timer timer = new Timer(2000, e -> dialog.dispose()); timer.setRepeats(false); timer.start(); dialog.setVisible(true); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14094#discussion_r1207245091 From aivanov at openjdk.org Fri May 26 19:45:54 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 26 May 2023 19:45:54 GMT Subject: RFR: 8294535 : Add screen capture functionality to PassFailJFrame In-Reply-To: References: <9fZwcg7-Tdm7naKW5dPxJAFPdcTKso35SVV7tHz-jQU=.04193ab7-23d2-4cf6-8f0d-788dad78b57d@github.com> Message-ID: <_abzbnVzNsvXK54mluxhUQ_lf6sdVWGdB6cXXZBV7Xg=.3a22bc38-fc01-44d1-8742-7c1b22ef15da@github.com> On Fri, 26 May 2023 19:30:36 GMT, Harshitha Onkar wrote: > > If the displayed message isn't modal, like a tooltip or a notification which disappears automatically after a certain time, it could be better appreciated. But it's harder to implement. > > We could use Timer for disappearing messages, but might be an overkill here. How else could one implement a disappearing message? This approach still shows a *modal* dialog box. While it's shown the user can't do anything but dispose the dialog. In my opinion, if we show the dialog, let the user to dismiss it. The message confirming screenshots are successfully taken should be non-intrusive, it may be displayed in a small (translucent) window close to the button which will automatically disappear after a specified timeout. An option to dismiss it before the timeout is even better. Yet it shouldn't prevent access to other UI elements so that the tester could click Fail right away. However, I may be overthinking it? Implementing such a UI is likely an overkill. Yet I'm still not convinced a modal dialog box is needed. Consider seeing a modal dialog box that says "File has been saved successfully" each time you select Save command in a text editor or any other editor. You expect it to succeed, thus notification is need only if an error occurred. As the result of the error message, you'll try saving the file again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14094#discussion_r1207258047 From jiangli at openjdk.org Fri May 26 20:28:55 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 26 May 2023 20:28:55 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 01:19:11 GMT, Jiangli Zhou wrote: > > > > My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message: > > > > ``` > > > > [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so > > > > ``` > > > > > > > > > If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems. > > > > > > The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation. > > Is it possible `$$($1_SYSROOT_LDFLAGS)` pulled in `libstdc++.so` as part of the input for partial linking with the linux-aarch64 cross build? > > Another possibility might be the user provided `BUILD_LDCXX` includes extra options in the testing build (?). If that's the case, we probably could define a separate `BUILD_LD_PARTIAL` with no added options. In our prototype on JDK 11, we define a separate one for partial linking. I tried building `static-libs-image` for linux-aarch64 on Ubuntu machine using `devkit` to reproduce the failure. Also tried building for `linux-ppc64le-server-release` target using `devkit` on Ubuntu. Both built successfully with using `devkit`. I could not build a `devkit` for arm32 (with `make TARGETS="arm-linux-gnueabihf" BASE_OS=Fedora BASE_OS_VERSION=17`, also tried with BASE_OS_VERSION=17). @erikj79 Could you please help provide additional insight for the build failure you found for arm32? `BUILD_LIBJVM_partial_link.cmdline` might help shed some light. For the `aarch64-linux-gnu` build using `devkit`, I see following, which is ok. No unexpected options are included. /.../bin/aarch64-linux-gnu-g++ -r --sysroot=/.../aarch64-linux-gnu/sysroot -o /...linux-aarch64-server-release/hotspot/variant-server/libjvm/objs/static/libjvm_relocatable.o @/.../hotspot/variant-server/libjvm/objs/static/_BUILD_LIBJVM_objectfilenames.txt ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1564908324 From mdoerr at openjdk.org Fri May 26 20:29:54 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 26 May 2023 20:29:54 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 16:58:41 GMT, Thomas Stuefe wrote: >> The crazy thing is that `malloc` is defined! That means all places where we use the term malloc are getting replaced without such a workaround. (E.g. for log tags.) > > So, we do this only for malloc? Not for calloc, posix_memalign, realloc etc? What about free? > > As ugly as defining malloc is (and I remember QADRT), I hesitate about removing that define. > > Removing that define and hard-coding it here assumes 1) our replacement is equivalent (ok, easy to check) 2) it will always be equivalent in future AIX versions 3) pointers it returns work with the unchanged free() and realloc() the system provides, and will always do so. > > I don't know... I would not do this just to get rid of a warning. This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1207308708 From jiangli at openjdk.org Fri May 26 20:39:57 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 26 May 2023 20:39:57 GMT Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v5] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 21:02:00 GMT, Jiangli Zhou wrote: >> Original description for JDK-8307194 change: >> ----- >> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries: >> >> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target >> >> - For libjvm.a specifically, exclude operator_new.o >> >> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols >> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled >> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a >> >> - Handle long arguments case for static build in make/common/NativeCompilation.gmk >> >> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS >> ----- >> >> Updates to address build failures reported on macosx- platforms: >> >> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. >> >> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx- builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`. >> >> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update make/common/NativeCompilation.gmk > > Thanks you! > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> `with `make TARGETS="arm-linux-gnueabihf" BASE_OS=Fedora BASE_OS_VERSION=17`, also tried with BASE_OS_VERSION=17` Fix typo: `also tried with BASE_OS_VERSION=18` ------------- PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1564919758 From prr at openjdk.org Fri May 26 21:52:56 2023 From: prr at openjdk.org (Phil Race) Date: Fri, 26 May 2023 21:52:56 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: References: Message-ID: On Thu, 25 May 2023 16:29:39 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > rework token storage macos builds are broken with this change. The problem is unix/classes/sun/awt/screencast, causing unix/classes/sun/awt/X11 to be built but it fails because we don't (and shouldn't) generate the XAWT source on macOS. You need to add screencast to the exclude list for macOS. git diff make/modules/java.desktop/Java.gmk diff --git a/make/modules/java.desktop/Java.gmk b/make/modules/java.desktop/Java.gmk index 19cd5b7da83..c9057c09c7f 100644 --- a/make/modules/java.desktop/Java.gmk +++ b/make/modules/java.desktop/Java.gmk @@ -68,6 +68,7 @@ EXCLUDE_FILES += \ ifeq ($(call isTargetOs, macosx), true) # exclude all X11 on Mac. EXCLUDES += \ + sun/awt/screencast \ sun/awt/X11 \ sun/java2d/x11 \ sun/java2d/jules \ ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1564995771 From azvegint at openjdk.org Sat May 27 01:25:40 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Sat, 27 May 2023 01:25:40 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v8] In-Reply-To: References: Message-ID: > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: fix macos build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/1bd099cd..257445f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=06-07 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From azvegint at openjdk.org Sat May 27 01:25:42 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Sat, 27 May 2023 01:25:42 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v7] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 21:50:15 GMT, Phil Race wrote: > macos builds are broken with this change. The problem is unix/classes/sun/awt/screencast, causing unix/classes/sun/awt/X11 to be built but it fails because we don't (and shouldn't) generate the XAWT source on macOS. > > You need to add screencast to the exclude list for macOS. Nice catch, fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1565133825 From stuefe at openjdk.org Sat May 27 11:28:54 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 27 May 2023 11:28:54 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com> On Fri, 26 May 2023 20:27:12 GMT, Martin Doerr wrote: > This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags. That does not invalidate my argument, nor does it answer my question. Those test errors could be also fixed by renaming the log tag. Maybe that would be the better way. Also, I'm curious, why does it not complain about "free", which is a logtag as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1207892378 From stuefe at openjdk.org Sat May 27 11:52:55 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 27 May 2023 11:52:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com> References: <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com> Message-ID: On Sat, 27 May 2023 11:25:41 GMT, Thomas Stuefe wrote: >> This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags. > >> This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags. > > That does not invalidate my argument, nor does it answer my question. Those test errors could be also fixed by renaming the log tag. Maybe that would be the better way. > > Also, I'm curious, why does it not complain about "free", which is a logtag as well? I am basically worried that undefining malloc, even if it seems harmless now, exposes us to difficult-to-investigate problems down the road, since it depends on how the libc devs will reform those macros in the future. I would prefer a simple solution that does not depend on how the libc includes evolve. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1207907447 From kbarrett at openjdk.org Sat May 27 15:36:55 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 27 May 2023 15:36:55 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com> Message-ID: On Sat, 27 May 2023 11:50:11 GMT, Thomas Stuefe wrote: >>> This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags. >> >> That does not invalidate my argument, nor does it answer my question. Those test errors could be also fixed by renaming the log tag. Maybe that would be the better way. >> >> Also, I'm curious, why does it not complain about "free", which is a logtag as well? > > I am basically worried that undefining malloc, even if it seems harmless now, exposes us to difficult-to-investigate problems down the road, since it depends on how the libc devs will reform those macros in the future. I would prefer a simple solution that does not depend on how the libc includes evolve. Is it possible to see the stdlib.h source code that is being a problem? Maybe more eyes can come up with a better solution, or at least come to a better understanding of why we have to go this way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1208039639 From kbarrett at openjdk.org Sun May 28 03:39:10 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 28 May 2023 03:39:10 GMT Subject: RFR: 8308286 Fix clang warnings in linux code In-Reply-To: References: Message-ID: <63Q15YTSJDgsIJb4fYQYdrtBYkSNebRm7Q8jVgzTiW8=.86a710d5-1930-4b3c-80a2-743a83653831@github.com> On Fri, 26 May 2023 07:48:06 GMT, Daniel Jeli?ski wrote: > According to our docs, [clang is a supported compiler for Linux](https://github.com/openjdk/jdk/blob/master/doc/building.md#native-compiler-toolchain-requirements). I think that's aspirational rather than actual. Clang has been included in that list for a long time (since at least JDK 9), but I think there's never been anyone claiming to provide such support, be a maintainer, or even build/test on some regular basis: https://wiki.openjdk.org/display/Build/Supported+Build+Platforms ------------- PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1565842012 From kbarrett at openjdk.org Sun May 28 04:14:04 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 28 May 2023 04:14:04 GMT Subject: RFR: 8308286 Fix clang warnings in linux code In-Reply-To: References: Message-ID: <_RQshJQSfZfWSXTPvIjEekBkNIJCGy6UPHo_94bE5IM=.afc7036a-4553-45f2-b5d2-76758e69dbb4@github.com> On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov wrote: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. All of the -Wformat-nonliteral changes make me wonder why we're seeing these with clang but not with gcc. Figuring that out will likely give a better chance of acceptance. src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c line 1163: > 1161: #if defined(__clang__) > 1162: #pragma clang diagnostic push > 1163: #pragma clang diagnostic ignored "-Wparentheses" I think this warning is because of the several `if (init_result = ...)`? Better would be to just add the extra parens. src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 575: > 573: if (ps_pdread(ph, (char *)link_map_addr + LINK_MAP_LD_OFFSET, > 574: &lib_ld, sizeof(uintptr_t)) != PS_OK) { > 575: #else What problem is being "fixed" by these? I'm dubious that this is the best solution to whatever the problem is, but can't evaluate or suggest alternatives without knowing what it is. ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1447852014 PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1208298799 PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1208302906 From rmahajan at openjdk.org Sun May 28 22:23:27 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Sun, 28 May 2023 22:23:27 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v6] In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: > Problem: > > Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: > > - Scrawly ticks in checkboxes; > - Wrong circle relations in selected radio buttons. > > Root-cause: > We open theme on AWT Toolkit Window which always has Primary Monitor DPI. > Due to this when the app window goes to Secondary Screen with different DPI UI buttons > appear incorrectly rendered. > Following is a list proposed changes to fix this issue. > > > Proposed Fix with Summary of changes: > > 1. Open a new Theme Handle per the DPI of the Screen where the App window is. > --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. > window is. > > 2. GetPartSize() of icons returns size based on standard size = 96 DPI. > --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. > > 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. > -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. > > 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. > --> This helps make sure that for .25s scaling we get better rendering. > This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. > > As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. > > > Testing: > > Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. > > ___________________________________ > Monitor 1 | Monitor 2 > (Primary) | > | > 125% | 175% > 150% | 175% > 150% | 225% > 175% | 175% > 175% | 150% > 175% | 225% > _____________________ |_____________ > > Also tested on setup with scaling values of up-to 350%. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: changes as siggested in review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13701/files - new: https://git.openjdk.org/jdk/pull/13701/files/8cfb4134..90db1b6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=04-05 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13701.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701 PR: https://git.openjdk.org/jdk/pull/13701 From jdv at openjdk.org Mon May 29 04:47:06 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 29 May 2023 04:47:06 GMT Subject: RFR: 8306119: Many components respond to a mouse event by requesting focus without supplying the MOUSE_EVENT cause [v3] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 10:41:09 GMT, Prasanta Sadhukhan wrote: >> Many Swing components request a focus transfer in response to a mouse event, but fail to supply a Cause when requesting focus. A focus event listener will find the cause to be UNKNOWN, but MOUSE_EVENT would be more appropriate. >> Fixed by adding MOUSE_EVENT cause to requestFocus() when it is called for mouse events... >> >> All jtreg/jck tests are ok.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > test fix I see concerns related to SwingUtilities2 and Accessibility in https://bugs.openjdk.org/browse/JDK-8306119 description. If we are not handling them in this fix, do we have separate JBS bug for them? src/java.desktop/macosx/classes/com/apple/laf/AquaSpinnerUI.java line 606: > 604: > 605: if (child != null && SwingUtilities.isDescendingFrom(child, spinner)) { > 606: child.requestFocus(FocusEvent.Cause.MOUSE_EVENT); I see that this function is called only from mousePressed. This seems fine. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicButtonListener.java line 325: > 323: model.setPressed(true); > 324: if(!b.hasFocus()) { > 325: b.requestFocus(FocusEvent.Cause.MOUSE_EVENT); Can this action be performed using a keyboard or this can be reached only using mouse press? If this actionPerformed can be reached using keyboard, i think we should add appropriate checks before throwing the focus event cause. src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 585: > 583: component.isRequestFocusEnabled()) { > 584: if (inWindow) { > 585: component.requestFocusInWindow(FocusEvent.Cause.MOUSE_EVENT); Looks like this function is also called only in case of mouse events from mousePressed()->adjustCaretAndFocus() and mouseClicked(). Seems fine. test/jdk/javax/swing/event/FocusEventCauseTest.java line 59: > 57: frame = new JFrame("FocusEventCauseTest"); > 58: JPanel panel = new JPanel(); > 59: button1 = new JButton("Button1"); Generic test comment. Its good if we can check focus event for all UI components that are getting updated. ------------- PR Review: https://git.openjdk.org/jdk/pull/14004#pullrequestreview-1448785377 PR Review Comment: https://git.openjdk.org/jdk/pull/14004#discussion_r1208862476 PR Review Comment: https://git.openjdk.org/jdk/pull/14004#discussion_r1208863379 PR Review Comment: https://git.openjdk.org/jdk/pull/14004#discussion_r1208874028 PR Review Comment: https://git.openjdk.org/jdk/pull/14004#discussion_r1208879547 From psadhukhan at openjdk.org Mon May 29 05:58:24 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 May 2023 05:58:24 GMT Subject: RFR: 8306119: Many components respond to a mouse event by requesting focus without supplying the MOUSE_EVENT cause [v3] In-Reply-To: References: Message-ID: On Mon, 29 May 2023 04:43:44 GMT, Jayathirth D V wrote: > I see concerns related to SwingUtilities2 and Accessibility in https://bugs.openjdk.org/browse/JDK-8306119 description. If we are not handling them in this fix, do we have separate JBS bug for them? As of now, I will let Accessibility team handle the change in a separate JBS issue. Also SwingUtilities concern is to add additonal method which will need CSR which should be handled as separate issue again, so not handled here.. > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicButtonListener.java line 325: > >> 323: model.setPressed(true); >> 324: if(!b.hasFocus()) { >> 325: b.requestFocus(FocusEvent.Cause.MOUSE_EVENT); > > Can this action be performed using a keyboard or this can be reached only using mouse press? > If this actionPerformed can be reached using keyboard, i think we should add appropriate checks before throwing the focus event cause. I have removed this contentious change as it probably can be used using keyboard too. For now, just kept the other mouse only focus event cause in this file.. > test/jdk/javax/swing/event/FocusEventCauseTest.java line 59: > >> 57: frame = new JFrame("FocusEventCauseTest"); >> 58: JPanel panel = new JPanel(); >> 59: button1 = new JButton("Button1"); > > Generic test comment. Its good if we can check focus event for all UI components that are getting updated. Actually, the fix is trivial, the test is only added to show how the cause whould be presented to the user using a widget. The other widgets would be same in showing focus cause event to be MOUSE_EVENT so not handled separately.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14004#issuecomment-1566588152 PR Review Comment: https://git.openjdk.org/jdk/pull/14004#discussion_r1208932596 PR Review Comment: https://git.openjdk.org/jdk/pull/14004#discussion_r1208931915 From psadhukhan at openjdk.org Mon May 29 05:58:24 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 May 2023 05:58:24 GMT Subject: RFR: 8306119: Many components respond to a mouse event by requesting focus without supplying the MOUSE_EVENT cause [v4] In-Reply-To: References: Message-ID: <54x54PoyWG1IJC7ALbSgPhXE_XwGM6dRphvBilL4C1o=.0539df7a-989b-476c-850c-f927c992e832@github.com> > Many Swing components request a focus transfer in response to a mouse event, but fail to supply a Cause when requesting focus. A focus event listener will find the cause to be UNKNOWN, but MOUSE_EVENT would be more appropriate. > Fixed by adding MOUSE_EVENT cause to requestFocus() when it is called for mouse events... > > All jtreg/jck tests are ok.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Keep mouse only focus events ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14004/files - new: https://git.openjdk.org/jdk/pull/14004/files/ee4afbbd..0ce48d00 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14004&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14004&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14004.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14004/head:pull/14004 PR: https://git.openjdk.org/jdk/pull/14004 From jdv at openjdk.org Mon May 29 06:41:56 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 29 May 2023 06:41:56 GMT Subject: RFR: 8306119: Many components respond to a mouse event by requesting focus without supplying the MOUSE_EVENT cause [v4] In-Reply-To: <54x54PoyWG1IJC7ALbSgPhXE_XwGM6dRphvBilL4C1o=.0539df7a-989b-476c-850c-f927c992e832@github.com> References: <54x54PoyWG1IJC7ALbSgPhXE_XwGM6dRphvBilL4C1o=.0539df7a-989b-476c-850c-f927c992e832@github.com> Message-ID: On Mon, 29 May 2023 05:58:24 GMT, Prasanta Sadhukhan wrote: >> Many Swing components request a focus transfer in response to a mouse event, but fail to supply a Cause when requesting focus. A focus event listener will find the cause to be UNKNOWN, but MOUSE_EVENT would be more appropriate. >> Fixed by adding MOUSE_EVENT cause to requestFocus() when it is called for mouse events... >> >> All jtreg/jck tests are ok.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Keep mouse only focus events Marked as reviewed by jdv (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14004#pullrequestreview-1448955231 From jdv at openjdk.org Mon May 29 06:41:58 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 29 May 2023 06:41:58 GMT Subject: RFR: 8306119: Many components respond to a mouse event by requesting focus without supplying the MOUSE_EVENT cause [v3] In-Reply-To: References: Message-ID: On Mon, 29 May 2023 05:50:13 GMT, Prasanta Sadhukhan wrote: > > I see concerns related to SwingUtilities2 and Accessibility in https://bugs.openjdk.org/browse/JDK-8306119 description. If we are not handling them in this fix, do we have separate JBS bug for them? > > As of now, I will let Accessibility team handle the change in a separate JBS issue. Also SwingUtilities concern is to add additonal method which will need CSR which should be handled as separate issue again, so not handled here.. Sure please raise appropriate JBS issues once we finalise the fix for this issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14004#issuecomment-1566633716 From psadhukhan at openjdk.org Mon May 29 08:45:12 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 May 2023 08:45:12 GMT Subject: RFR: 8306119: Many components respond to a mouse event by requesting focus without supplying the MOUSE_EVENT cause [v4] In-Reply-To: <54x54PoyWG1IJC7ALbSgPhXE_XwGM6dRphvBilL4C1o=.0539df7a-989b-476c-850c-f927c992e832@github.com> References: <54x54PoyWG1IJC7ALbSgPhXE_XwGM6dRphvBilL4C1o=.0539df7a-989b-476c-850c-f927c992e832@github.com> Message-ID: On Mon, 29 May 2023 05:58:24 GMT, Prasanta Sadhukhan wrote: >> Many Swing components request a focus transfer in response to a mouse event, but fail to supply a Cause when requesting focus. A focus event listener will find the cause to be UNKNOWN, but MOUSE_EVENT would be more appropriate. >> Fixed by adding MOUSE_EVENT cause to requestFocus() when it is called for mouse events... >> >> All jtreg/jck tests are ok.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Keep mouse only focus events I have raised [JDK-8309041](https://bugs.openjdk.org/browse/JDK-8309041) for SwingUtilities focus upgrade ------------- PR Comment: https://git.openjdk.org/jdk/pull/14004#issuecomment-1566767604 From psadhukhan at openjdk.org Mon May 29 08:45:14 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 May 2023 08:45:14 GMT Subject: Integrated: 8306119: Many components respond to a mouse event by requesting focus without supplying the MOUSE_EVENT cause In-Reply-To: References: Message-ID: On Tue, 16 May 2023 08:55:03 GMT, Prasanta Sadhukhan wrote: > Many Swing components request a focus transfer in response to a mouse event, but fail to supply a Cause when requesting focus. A focus event listener will find the cause to be UNKNOWN, but MOUSE_EVENT would be more appropriate. > Fixed by adding MOUSE_EVENT cause to requestFocus() when it is called for mouse events... > > All jtreg/jck tests are ok.. This pull request has now been integrated. Changeset: 70130d3b Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/70130d3b16e76364ede72dec421ed6e7c40467fe Stats: 128 lines in 12 files changed: 111 ins; 0 del; 17 mod 8306119: Many components respond to a mouse event by requesting focus without supplying the MOUSE_EVENT cause Reviewed-by: jdv ------------- PR: https://git.openjdk.org/jdk/pull/14004 From duke at openjdk.org Mon May 29 12:55:08 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 29 May 2023 12:55:08 GMT Subject: Integrated: 8289547 : Update javax/swing/Popup/TaskbarPositionTest.java In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 12:58:58 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > Noticed this test case not verifying all the cases which is intended. Modified it for improving the coverage for 3 type of popups (menu, context menu and combobox). > > Evaluating conditions: > 1. Not enough space for showing popup downwards(default layout), it should show upwards > 2. Window starts from negative position, Popup should show on visible area > > For achieving this following areas are modified > - Updated isPopupOnScreen by adding Additional checks (like the position of combobox popup is always verified) > - Menu creation made as function and reused for all menu creation. > - Updated ComboPopupCheckListener class and modified its popupMenuWillBecomeInvisible function. Made it as generic and it is capable to evaluate any combo box's position if this class set as its listener. > - This test case is not intended for multi monitor setup so added a check for identifying monitor, else error out. > - Updated CTRL_MASK to CTRL_DOWN_MASK for removing depreciation warnings and removed some other warnings. > > Please review this > > Regards, > Renjith. This pull request has now been integrated. Changeset: d73fc70e Author: Renjith Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/d73fc70ea272be6bf4f1c82608c73ff0a8f6032d Stats: 246 lines in 1 file changed: 132 ins; 54 del; 60 mod 8289547: Update javax/swing/Popup/TaskbarPositionTest.java Reviewed-by: aivanov, dmarkov, honkar ------------- PR: https://git.openjdk.org/jdk/pull/13578 From psadhukhan at openjdk.org Mon May 29 16:24:18 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 May 2023 16:24:18 GMT Subject: RFR: 8309060: Compilation Error in javax/swing/event/FocusEventCauseTest.java Message-ID: <8NO2u9exDCOescVLeOD3JfpT0jWTB7NVjlsVR16ZvWs=.dbe3f3a9-75a5-40b5-b1fd-b273547d801b@github.com> Inadvertent extraneous semicolon causing compilation error is fixed. ------------- Commit messages: - Test fix Changes: https://git.openjdk.org/jdk/pull/14206/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14206&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309060 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14206.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14206/head:pull/14206 PR: https://git.openjdk.org/jdk/pull/14206 From abhiscxk at openjdk.org Mon May 29 18:11:54 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 29 May 2023 18:11:54 GMT Subject: RFR: 8309060: Compilation Error in javax/swing/event/FocusEventCauseTest.java In-Reply-To: <8NO2u9exDCOescVLeOD3JfpT0jWTB7NVjlsVR16ZvWs=.dbe3f3a9-75a5-40b5-b1fd-b273547d801b@github.com> References: <8NO2u9exDCOescVLeOD3JfpT0jWTB7NVjlsVR16ZvWs=.dbe3f3a9-75a5-40b5-b1fd-b273547d801b@github.com> Message-ID: On Mon, 29 May 2023 16:16:57 GMT, Prasanta Sadhukhan wrote: > Inadvertent extraneous semicolon causing compilation error is fixed. Looks good to me. ------------- Marked as reviewed by abhiscxk (Committer). PR Review: https://git.openjdk.org/jdk/pull/14206#pullrequestreview-1449768147 From aivanov at openjdk.org Mon May 29 18:28:03 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 29 May 2023 18:28:03 GMT Subject: RFR: 8309060: Compilation Error in javax/swing/event/FocusEventCauseTest.java In-Reply-To: <8NO2u9exDCOescVLeOD3JfpT0jWTB7NVjlsVR16ZvWs=.dbe3f3a9-75a5-40b5-b1fd-b273547d801b@github.com> References: <8NO2u9exDCOescVLeOD3JfpT0jWTB7NVjlsVR16ZvWs=.dbe3f3a9-75a5-40b5-b1fd-b273547d801b@github.com> Message-ID: On Mon, 29 May 2023 16:16:57 GMT, Prasanta Sadhukhan wrote: > Inadvertent extraneous semicolon causing compilation error is fixed. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14206#pullrequestreview-1449776207 From psadhukhan at openjdk.org Mon May 29 18:28:04 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 29 May 2023 18:28:04 GMT Subject: Integrated: 8309060: Compilation Error in javax/swing/event/FocusEventCauseTest.java In-Reply-To: <8NO2u9exDCOescVLeOD3JfpT0jWTB7NVjlsVR16ZvWs=.dbe3f3a9-75a5-40b5-b1fd-b273547d801b@github.com> References: <8NO2u9exDCOescVLeOD3JfpT0jWTB7NVjlsVR16ZvWs=.dbe3f3a9-75a5-40b5-b1fd-b273547d801b@github.com> Message-ID: On Mon, 29 May 2023 16:16:57 GMT, Prasanta Sadhukhan wrote: > Inadvertent extraneous semicolon causing compilation error is fixed. This pull request has now been integrated. Changeset: a4bae3a9 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/a4bae3a9e2b8162d6dab0428fb90a67860bba1b7 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8309060: Compilation Error in javax/swing/event/FocusEventCauseTest.java Reviewed-by: abhiscxk, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/14206 From asemenov at openjdk.org Mon May 29 22:29:26 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Mon, 29 May 2023 22:29:26 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v2] In-Reply-To: References: Message-ID: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14033/files - new: https://git.openjdk.org/jdk/pull/14033/files/86077cdf..3f343c26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=00-01 Stats: 134 lines in 15 files changed: 12 ins; 122 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033 PR: https://git.openjdk.org/jdk/pull/14033 From tr at openjdk.org Tue May 30 07:08:47 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 30 May 2023 07:08:47 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v7] In-Reply-To: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: > This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. > The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. Tejesh R 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 eight additional commits since the last revision: - Updated new fix - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8307105 - White space fix - Alternate Fix - Updated based on review comments - Updated based on review comments - Updated based on review comments - Fix + Manual Test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13998/files - new: https://git.openjdk.org/jdk/pull/13998/files/9dee0730..a946c73a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=05-06 Stats: 606155 lines in 6803 files changed: 467459 ins; 83134 del; 55562 mod Patch: https://git.openjdk.org/jdk/pull/13998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13998/head:pull/13998 PR: https://git.openjdk.org/jdk/pull/13998 From tr at openjdk.org Tue May 30 07:45:03 2023 From: tr at openjdk.org (Tejesh R) Date: Tue, 30 May 2023 07:45:03 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v3] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <44OqUYxSGvWtapDQ2cU3kyzlKRNA3Rscc0I7ZwZ1dsU=.d147c1d5-a043-449f-be1f-2d80e94c7890@github.com> Message-ID: On Mon, 22 May 2023 15:55:41 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated based on review comments > > Changes requested by aivanov (Reviewer). As discuss with @aivanov-jdk , the fix validates shortcut links of format `.lnk` only, excluding both both [symbolic links](https://learn.microsoft.com/en-us/windows/win32/fileio/creating-symbolic-links) and [junctions](https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions#junctions). Since [IShellFolder::GetAttributesOf](https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-ishellfolder-getattributesof) checks only `.lnk` type of link, as we can seen from the attributes list provided by the native [ishellFolder interface](https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ishellfolder) which are in [Attributes List](https://learn.microsoft.com/en-us/windows/win32/shell/sfgao). The `path` validation is done through `isFileSystem()` and `getPath().toLowerCase().endsWith(".lnk")` validates if its a `.lnk` type without causing any regression (Which also fixes the bug - [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966), without the need use `Files.isSymbolicLink`) . ------------- PR Comment: https://git.openjdk.org/jdk/pull/13998#issuecomment-1567924357 From avu at openjdk.org Tue May 30 08:20:04 2023 From: avu at openjdk.org (Alexey Ushakov) Date: Tue, 30 May 2023 08:20:04 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v2] In-Reply-To: References: Message-ID: On Mon, 29 May 2023 22:29:26 GMT, Artem Semenov wrote: >> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". >> They can be fixed with small changes. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > update Changes requested by avu (Committer). src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 655: > 653: // linker loaded it. We use "base diff" in read_lib_segments call below. > 654: > 655: if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_ADDR_OFFSET, Extra white spaces before 'if' src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 662: > 660: > 661: // read address of the name > 662: if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NAME_OFFSET, Extra white-spaces before 'if' src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 717: > 715: > 716: // read next link_map address > 717: if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NEXT_OFFSET, Extra white-spaces before 'if' src/jdk.jpackage/share/native/common/tstrings.cpp line 60: > 58: #endif > 59: // With g++ this compiles only with '-std=gnu++0x' option > 60: ret = vsnprintf(&*fmtout.begin(), fmtout.size(), format, args); Extra white-spaces before 'ret' ------------- PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1450367357 PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209893589 PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209894667 PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209895275 PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209895801 From duke at openjdk.org Tue May 30 11:33:46 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 30 May 2023 11:33:46 GMT Subject: RFR: 8309095 : Remove UTF-8 character from TaskbarPositionTest.java Message-ID: Hi Reviewers, Removed UTF-8 character (?) from TaskbarPositionTest.java from the testcase. Please review this Regards, Renjith. ------------- Commit messages: - JDK-8309095:Remove UTF-8 character from TaskbarPositionTest.java Changes: https://git.openjdk.org/jdk/pull/14212/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14212&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309095 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14212.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14212/head:pull/14212 PR: https://git.openjdk.org/jdk/pull/14212 From aivanov at openjdk.org Tue May 30 11:33:47 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 May 2023 11:33:47 GMT Subject: RFR: 8309095 : Remove UTF-8 character from TaskbarPositionTest.java In-Reply-To: References: Message-ID: On Tue, 30 May 2023 11:22:06 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > Removed UTF-8 character (?) from TaskbarPositionTest.java from the testcase. > Please review this > Regards, > Renjith. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14212#pullrequestreview-1450720573 From duke at openjdk.org Tue May 30 12:15:05 2023 From: duke at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 30 May 2023 12:15:05 GMT Subject: Integrated: 8309095 : Remove UTF-8 character from TaskbarPositionTest.java In-Reply-To: References: Message-ID: On Tue, 30 May 2023 11:22:06 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > Removed UTF-8 character (?) from TaskbarPositionTest.java from the testcase. > Please review this > Regards, > Renjith. This pull request has now been integrated. Changeset: 07f20704 Author: Renjith Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/07f2070411b3bff5608166ceae0e0bdbf155e7c2 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8309095: Remove UTF-8 character from TaskbarPositionTest.java Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/14212 From kbarrett at openjdk.org Tue May 30 14:42:59 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 30 May 2023 14:42:59 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com> Message-ID: On Sat, 27 May 2023 15:33:37 GMT, Kim Barrett wrote: >> I am basically worried that undefining malloc, even if it seems harmless now, exposes us to difficult-to-investigate problems down the road, since it depends on how the libc devs will reform those macros in the future. I would prefer a simple solution that does not depend on how the libc includes evolve. > > Is it possible to see the stdlib.h source code that is being a problem? Maybe more eyes can come up > with a better solution, or at least come to a better understanding of why we have to go this way. Technically it's our fault. The standard library is permitted to provide a macro replacements for (nearly?) any function. (C99 7.1.3/1 3rd bullet) But it's really annoying. Presumably AIX is only doing so for a subset of the allocation functions, e.g. not "free" for example. Having "malloc" defined as a macro seems like it should raise all kinds of havoc, not just around log tags. Consider our "os::malloc" function? The preprocessor knows nothing about C++ namespace qualifiers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1210388482 From aivanov at openjdk.org Tue May 30 15:02:03 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 May 2023 15:02:03 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v6] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Sun, 28 May 2023 22:23:27 GMT, Rajat Mahajan wrote: >> Problem: >> >> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: >> >> - Scrawly ticks in checkboxes; >> - Wrong circle relations in selected radio buttons. >> >> Root-cause: >> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. >> Due to this when the app window goes to Secondary Screen with different DPI UI buttons >> appear incorrectly rendered. >> Following is a list proposed changes to fix this issue. >> >> >> Proposed Fix with Summary of changes: >> >> 1. Open a new Theme Handle per the DPI of the Screen where the App window is. >> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. >> window is. >> >> 2. GetPartSize() of icons returns size based on standard size = 96 DPI. >> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. >> >> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. >> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. >> >> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. >> --> This helps make sure that for .25s scaling we get better rendering. >> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. >> >> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. >> >> >> Testing: >> >> Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. >> >> ___________________________________ >> Monitor 1 | Monitor 2 >> (Primary) | >> | >> 125% | 175% >> 150% | 175% >> 150% | 225% >> 175% | 175% >> 175% | 150% >> 175% | 225% >> _____________________ |_____________ >> >> Also tested on setup with scaling values of up-to 350%. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > changes as siggested in review src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 92: > 90: if (dpiWidgetToTheme != null) { > 91: theme = dpiWidgetToTheme.get(widget); > 92: } It looks the the entire method could be implemented as a chained called to `computeIfAbsent`: return dpiAwareWidgetToTheme.computeIfAbsent(dpi, key -> new HashMap<>()) .computeIfAbsent(widget, w -> this::reallyOpenTheme); where `reallyOpenTheme` is a new helper method the body of which is that of the `if (theme == null)` block below. If implementable, it'll make the code shorter and, hopefully, more readable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1210416695 From aturbanov at openjdk.org Tue May 30 15:19:03 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 30 May 2023 15:19:03 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v6] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Sun, 28 May 2023 22:23:27 GMT, Rajat Mahajan wrote: >> Problem: >> >> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: >> >> - Scrawly ticks in checkboxes; >> - Wrong circle relations in selected radio buttons. >> >> Root-cause: >> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. >> Due to this when the app window goes to Secondary Screen with different DPI UI buttons >> appear incorrectly rendered. >> Following is a list proposed changes to fix this issue. >> >> >> Proposed Fix with Summary of changes: >> >> 1. Open a new Theme Handle per the DPI of the Screen where the App window is. >> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. >> window is. >> >> 2. GetPartSize() of icons returns size based on standard size = 96 DPI. >> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. >> >> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. >> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. >> >> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. >> --> This helps make sure that for .25s scaling we get better rendering. >> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. >> >> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. >> >> >> Testing: >> >> Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. >> >> ___________________________________ >> Monitor 1 | Monitor 2 >> (Primary) | >> | >> 125% | 175% >> 150% | 175% >> 150% | 225% >> 175% | 175% >> 175% | 150% >> 175% | 225% >> _____________________ |_____________ >> >> Also tested on setup with scaling values of up-to 350%. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > changes as siggested in review src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 146: > 144: if (dpiAwareWidgetToTheme.get(dpi) != null) > 145: { > 146: theme = dpiAwareWidgetToTheme.get(dpi).get(widget); avoid calling `dpiAwareWidgetToTheme.get(dpi)` twice. Assign to a variable and reuse ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1210441536 From aivanov at openjdk.org Tue May 30 15:24:01 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 May 2023 15:24:01 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v6] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Sun, 28 May 2023 22:23:27 GMT, Rajat Mahajan wrote: >> Problem: >> >> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: >> >> - Scrawly ticks in checkboxes; >> - Wrong circle relations in selected radio buttons. >> >> Root-cause: >> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. >> Due to this when the app window goes to Secondary Screen with different DPI UI buttons >> appear incorrectly rendered. >> Following is a list proposed changes to fix this issue. >> >> >> Proposed Fix with Summary of changes: >> >> 1. Open a new Theme Handle per the DPI of the Screen where the App window is. >> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. >> window is. >> >> 2. GetPartSize() of icons returns size based on standard size = 96 DPI. >> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. >> >> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. >> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. >> >> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. >> --> This helps make sure that for .25s scaling we get better rendering. >> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. >> >> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. >> >> >> Testing: >> >> Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. >> >> ___________________________________ >> Monitor 1 | Monitor 2 >> (Primary) | >> | >> 125% | 175% >> 150% | 175% >> 150% | 225% >> 175% | 175% >> 175% | 150% >> 175% | 225% >> _____________________ |_____________ >> >> Also tested on setup with scaling values of up-to 350%. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > changes as siggested in review src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 432: > 430: rect.top = 0; > 431: rect.bottom = rectBottom ; > 432: rect.right = rectRight; Suggestion: rect.bottom = rectBottom; rect.right = rectRight; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1210447086 From aivanov at openjdk.org Tue May 30 15:48:06 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 May 2023 15:48:06 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v6] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Sun, 28 May 2023 22:23:27 GMT, Rajat Mahajan wrote: >> Problem: >> >> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: >> >> - Scrawly ticks in checkboxes; >> - Wrong circle relations in selected radio buttons. >> >> Root-cause: >> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. >> Due to this when the app window goes to Secondary Screen with different DPI UI buttons >> appear incorrectly rendered. >> Following is a list proposed changes to fix this issue. >> >> >> Proposed Fix with Summary of changes: >> >> 1. Open a new Theme Handle per the DPI of the Screen where the App window is. >> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. >> window is. >> >> 2. GetPartSize() of icons returns size based on standard size = 96 DPI. >> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. >> >> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. >> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. >> >> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. >> --> This helps make sure that for .25s scaling we get better rendering. >> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. >> >> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. >> >> >> Testing: >> >> Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. >> >> ___________________________________ >> Monitor 1 | Monitor 2 >> (Primary) | >> | >> 125% | 175% >> 150% | 175% >> 150% | 225% >> 175% | 175% >> 175% | 150% >> 175% | 225% >> _____________________ |_____________ >> >> Also tested on setup with scaling values of up-to 350%. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > changes as siggested in review Changes requested by aivanov (Reviewer). src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 124: > 122: if (!valid) { > 123: // Close old themes. > 124: if (!dpiAwareWidgetToTheme.isEmpty()) { The `!isEmpty()` seems redundant. If the map is empty, `values()` returns empty set; iterating over empty set does nothing. src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 131: > 129: } > 130: dpiAwareWidgetToTheme.get(dpi).clear(); > 131: dpiAwareWidgetToTheme.clear(); Suggestion: for (Map dpiVal : dpiAwareWidgetToTheme.values()) { for (Long value : dpiVal.values()) { closeTheme(value); } dpiVal.clear(); } dpiAwareWidgetToTheme.clear(); Avoid additional call to `get`. src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 132: > 130: dpiAwareWidgetToTheme.get(dpi).clear(); > 131: dpiAwareWidgetToTheme.clear(); > 132: valid = true; The `valid` flag should be set to `true` even if the map was empty. Otherwise, it may never be set to `true`. One more point to dropping `if (!isEmpty())`. ------------- PR Review: https://git.openjdk.org/jdk/pull/13701#pullrequestreview-1451265920 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1210472806 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1210477915 PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1210476382 From aivanov at openjdk.org Tue May 30 16:08:02 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 May 2023 16:08:02 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v6] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Tue, 30 May 2023 15:43:57 GMT, Alexey Ivanov wrote: >> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: >> >> changes as siggested in review > > src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 131: > >> 129: } >> 130: dpiAwareWidgetToTheme.get(dpi).clear(); >> 131: dpiAwareWidgetToTheme.clear(); > > Suggestion: > > for (Map dpiVal : dpiAwareWidgetToTheme.values()) { > for (Long value : dpiVal.values()) { > closeTheme(value); > } > dpiVal.clear(); > } > dpiAwareWidgetToTheme.clear(); > > Avoid additional call to `get`. This is even more serious: all the theme handles are closed but the maps for DPIs other than the passed `dpi` aren't cleared. With `clear` inside the loop, maps for all DPIs are cleared. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1210504722 From rmahajan at openjdk.org Tue May 30 16:52:49 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Tue, 30 May 2023 16:52:49 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v7] In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: > Problem: > > Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: > > - Scrawly ticks in checkboxes; > - Wrong circle relations in selected radio buttons. > > Root-cause: > We open theme on AWT Toolkit Window which always has Primary Monitor DPI. > Due to this when the app window goes to Secondary Screen with different DPI UI buttons > appear incorrectly rendered. > Following is a list proposed changes to fix this issue. > > > Proposed Fix with Summary of changes: > > 1. Open a new Theme Handle per the DPI of the Screen where the App window is. > --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. > window is. > > 2. GetPartSize() of icons returns size based on standard size = 96 DPI. > --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. > > 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. > -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. > > 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. > --> This helps make sure that for .25s scaling we get better rendering. > This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. > > As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. > > > Testing: > > Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. > > ___________________________________ > Monitor 1 | Monitor 2 > (Primary) | > | > 125% | 175% > 150% | 175% > 150% | 225% > 175% | 175% > 175% | 150% > 175% | 225% > _____________________ |_____________ > > Also tested on setup with scaling values of up-to 350%. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: Update src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13701/files - new: https://git.openjdk.org/jdk/pull/13701/files/90db1b6f..a041d6b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13701.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701 PR: https://git.openjdk.org/jdk/pull/13701 From prr at openjdk.org Tue May 30 17:11:03 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 30 May 2023 17:11:03 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v10] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 16:44:20 GMT, Prasanta Sadhukhan wrote: >> Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. >> In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. >> Fixed by implementing the equality and hashCode method for CSS.FontSize class. >> >> All jtreg/jck tests are ok > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Optimize fix src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2219: > 2217: public int hashCode() { > 2218: return Float.hashCode(value); > 2219: } why isn't index and lu part of this ? src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2225: > 2223: return val instanceof CSS.FontSize size > 2224: && Objects.equals(size.svalue, svalue); > 2225: } This is an anomaly. In all the other cases below you are using the local fields not the original parsed string. src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2920: > 2918: @Override > 2919: public boolean equals(Object val) { > 2920: return val instanceof CSS.BackgroundPosition bp why isn't "relative" part of equals and hashCode()? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1210575727 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1210575057 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1210573415 From psadhukhan at openjdk.org Tue May 30 17:18:19 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 30 May 2023 17:18:19 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v11] In-Reply-To: References: Message-ID: <2txPa9xO0Ko2rFLe4847WP_gKgNEutFT0sqiDt0lqMk=.4a0bcf01-2f01-4447-9365-db8cadcbf81b@github.com> > Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. > In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. > Fixed by implementing the equality and hashCode method for CSS.FontSize class. > > All jtreg/jck tests are ok Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix optimization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13405/files - new: https://git.openjdk.org/jdk/pull/13405/files/423c1169..612d5eba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=09-10 Stats: 11 lines in 1 file changed: 0 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13405/head:pull/13405 PR: https://git.openjdk.org/jdk/pull/13405 From psadhukhan at openjdk.org Tue May 30 17:24:06 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 30 May 2023 17:24:06 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v10] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 17:07:40 GMT, Phil Race wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Optimize fix > > src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2219: > >> 2217: public int hashCode() { >> 2218: return Float.hashCode(value); >> 2219: } > > why isn't index and lu part of this ? It is because only the float "value" is being considered and not the `lu` units px/pt > src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2225: > >> 2223: return val instanceof CSS.FontSize size >> 2224: && Objects.equals(size.svalue, svalue); >> 2225: } > > This is an anomaly. In all the other cases below you are using the local fields not the original parsed string. This is because font-size attribute can have units or percentage in it, it seems like as is being tested in the regression test, 42px, 42pt so "svalue" is being used which will have 42px/42pt so we can compare the string value of 42px or 42pt otherwise we need to parse to get the integer 42 and then the units px or pt and then compared separately > src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2920: > >> 2918: @Override >> 2919: public boolean equals(Object val) { >> 2920: return val instanceof CSS.BackgroundPosition bp > > why isn't "relative" part of equals and hashCode()? it is said "relative" is bit 0, horizontal relative, bit 1 horizontal relative to // font size, 2 vertical relative to size, 3 vertical relative to // font size I was not sure if it is need to be considered in the equals/hashcode contract.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1210587508 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1210587619 PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1210590108 From aivanov at openjdk.org Tue May 30 17:35:01 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 May 2023 17:35:01 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v10] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 17:18:48 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2225: >> >>> 2223: return val instanceof CSS.FontSize size >>> 2224: && Objects.equals(size.svalue, svalue); >>> 2225: } >> >> This is an anomaly. In all the other cases below you are using the local fields not the original parsed string. > > This is because font-size attribute can have units or percentage in it, it seems like as is being tested in the regression test, 42px, 42pt so "svalue" is being used which will have 42px/42pt so we can compare the string value of 42px or 42pt otherwise we need to parse to get the integer 42 and then the units px or pt and then compared separately We should not parse the string, it's already parsed. What if I put a space between value and unit? These two strings should produce equal attribute sets: {"font-size: 42px", "font-size: 42 px"}, The easiest way is to implement `LengthUnit.equals` which you still need for comparing `CSS.LengthValue` anyway because that class has exactly the same problem. You also compare the raw string there: https://github.com/openjdk/jdk/blob/612d5eba4c83ab53c797b03a244879261a5faa2a/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L2678-L2681 It doesn't look right to me. This is basically [a continuation of the same discussion](https://github.com/openjdk/jdk/pull/13405#discussion_r1202100159). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1210602634 From aivanov at openjdk.org Tue May 30 18:29:07 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 30 May 2023 18:29:07 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v7] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: On Tue, 30 May 2023 07:08:47 GMT, Tejesh R wrote: >> This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. >> The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. > > Tejesh R 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 eight additional commits since the last revision: > > - Updated new fix > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8307105 > - White space fix > - Alternate Fix > - Updated based on review comments > - Updated based on review comments > - Updated based on review comments > - Fix + Manual Test Other than the couple of comments, the fix looks good to me now. The `BasicFileChooserUI.Handler.valueChanged` method looks like it was before the [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966) fix. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 742: > 740: setDirectorySelected(true); > 741: setDirectory(file); > 742: I guess this blank line can be removed. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 1250: > 1248: } > 1249: > 1250: I am for preserving the blank line here, two blank lines separate method bodies from a nested class. src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 862: > 860: //Checks only if it's .lnk shortcut link. Other two links > 861: //namely Symbolic and Junctions returns false, so that the > 862: //absolute path can be resolved. Should it be included inside the javadoc as an `@implNote`? The class isn't public so we can change it, and it is more helpful because it's shown right away without opening source code for the method. src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 867: > 865: cachedIsLink = hasAttribute(ATTRIB_LINK) > 866: && (!isFileSystem() > 867: || getPath().toLowerCase().endsWith(".lnk")); At the very least, you should indent `||` farther because it's inside the parentheses (the condition is `c1 && (!c2 || c3)`), otherwise it could be misinterpreted as `c1 && !c2 || c3` which is completely different. Suggestion: cachedIsLink = hasAttribute(ATTRIB_LINK) && (!isFileSystem() || getPath().toLowerCase().endsWith(".lnk")); However, my personal preference is to align wrapped lines to the start of their corresponding part of the expression: Suggestion: cachedIsLink = hasAttribute(ATTRIB_LINK) && (!isFileSystem() || getPath().toLowerCase().endsWith(".lnk")); Either way is fine. ------------- PR Review: https://git.openjdk.org/jdk/pull/13998#pullrequestreview-1450471218 PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1209994712 PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1209995818 PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1209978564 PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1209973851 From coleenp at openjdk.org Tue May 30 18:45:57 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 30 May 2023 18:45:57 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: <-J0qbu5Ym0zr1WgUHHd2xw4qAwCsXrusMtlVCIH4snk=.d6571950-4708-430d-b119-150728407390@github.com> On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > forgotton _ src/hotspot/share/runtime/javaThread.cpp line 115: > 113: #include > 114: #endif > 115: Could these conditionals be included in globalDefinitions_xlc.hpp instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1210684136 From achung at openjdk.org Tue May 30 18:48:20 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 30 May 2023 18:48:20 GMT Subject: RFR: 8296972: [macos13] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java: getExtendedState() != 6 as expected. Message-ID: added displayChanged call to CPlatformWindow when frame first needs to deiconify or unmaximize All client tests passed after change ------------- Commit messages: - removed from problemlist - init commit Changes: https://git.openjdk.org/jdk/pull/14226/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14226&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296972 Stats: 3 lines in 2 files changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14226/head:pull/14226 PR: https://git.openjdk.org/jdk/pull/14226 From achung at openjdk.org Tue May 30 19:16:01 2023 From: achung at openjdk.org (Alisen Chung) Date: Tue, 30 May 2023 19:16:01 GMT Subject: RFR: 8307325: Verify the focus owner when non focused windows requesting focus [v2] In-Reply-To: References: Message-ID: On Tue, 16 May 2023 05:04:51 GMT, Ravi Gupta wrote: >> Write a test Check, when the top level Window is not the focused Window requesting for focus and becoming the Focus Owner for any Component in that Window checking the following >> >> 1.The Component is the Focus Owner and the Window becomes the focused Window If the platform supports cross requesting focus >> across Windows. >> 2.The request is remembered and be granted when the Window is later focused If the platform does not support requesting focus >> across Windows. >> >> Testing: >> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass. > > Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision: > > 8307325: Review comments fixed test/jdk/java/awt/Focus/CrossFocusRequestTest/CrossFocusRequestTest.java line 111: > 109: > 110: private static void initializeGUI() { > 111: frame1 = new Frame("Test Frame1"); Should these frames be named something specific to the test? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13790#discussion_r1210715878 From rmahajan at openjdk.org Tue May 30 20:01:19 2023 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Tue, 30 May 2023 20:01:19 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v8] In-Reply-To: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: > Problem: > > Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup: > > - Scrawly ticks in checkboxes; > - Wrong circle relations in selected radio buttons. > > Root-cause: > We open theme on AWT Toolkit Window which always has Primary Monitor DPI. > Due to this when the app window goes to Secondary Screen with different DPI UI buttons > appear incorrectly rendered. > Following is a list proposed changes to fix this issue. > > > Proposed Fix with Summary of changes: > > 1. Open a new Theme Handle per the DPI of the Screen where the App window is. > --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app. > window is. > > 2. GetPartSize() of icons returns size based on standard size = 96 DPI. > --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI. > > 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI. > -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows returns. Thus UI buttons are scaled correctly once we get their size back from Windows. > > 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we always floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil. > --> This helps make sure that for .25s scaling we get better rendering. > This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering. > > As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now. > > > Testing: > > Tested locally on my Windows machine with a 2 monitor setup 125%, 150%, 175%, 225% scaling values and on mach5. > > ___________________________________ > Monitor 1 | Monitor 2 > (Primary) | > | > 125% | 175% > 150% | 175% > 150% | 225% > 175% | 175% > 175% | 150% > 175% | 225% > _____________________ |_____________ > > Also tested on setup with scaling values of up-to 350%. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: Update src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13701/files - new: https://git.openjdk.org/jdk/pull/13701/files/a041d6b9..67db341d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13701&range=06-07 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13701.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13701/head:pull/13701 PR: https://git.openjdk.org/jdk/pull/13701 From dmarkov at openjdk.org Tue May 30 20:34:57 2023 From: dmarkov at openjdk.org (Dmitry Markov) Date: Tue, 30 May 2023 20:34:57 GMT Subject: RFR: 8296972: [macos13] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java: getExtendedState() != 6 as expected. In-Reply-To: References: Message-ID: On Tue, 30 May 2023 18:41:38 GMT, Alisen Chung wrote: > added displayChanged call to CPlatformWindow when frame first needs to deiconify or unmaximize > All client tests passed after change Changes requested by dmarkov (Reviewer). src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 989: > 987: // the zoom call toggles between the normal and the max states > 988: unmaximize(); > 989: peer.displayChanged(); Why do you call `peer.displayChanged()` only when the previous windows state is `MAXIMIZED_BOTH`? What happens if the previous windows state is `NORMAL`? src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 997: > 995: // let's return into the normal states first > 996: execute(CWrapper.NSWindow::deminiaturize); > 997: peer.displayChanged(); Same as above. What happens if we move from `NORMAL` to `MAXIMIZED_BOTH`? Shall we call `peer.displayChanged()` when a frame is moved to `NORMAL` state? I know that cases are not covered by the test but it seems the issue takes place there. Can you investigate, please? ------------- PR Review: https://git.openjdk.org/jdk/pull/14226#pullrequestreview-1451769898 PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1210794283 PR Review Comment: https://git.openjdk.org/jdk/pull/14226#discussion_r1210794376 From prr at openjdk.org Tue May 30 20:43:06 2023 From: prr at openjdk.org (Phil Race) Date: Tue, 30 May 2023 20:43:06 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v8] In-Reply-To: References: Message-ID: On Sat, 27 May 2023 01:25:40 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > fix macos build src/java.desktop/share/classes/java/awt/peer/RobotPeer.java line 130: > 128: return false; > 129: } > 130: The only change to this file is adding a blank line. Please revert. src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 139: > 137: > 138: for (TokenItem tokenItem : tokensForRectangle) { > 139: retVal = getRGBPixelsImpl( This can't be right. You surely want to check all cases of retVal not just the last one. src/java.desktop/unix/classes/sun/awt/screencast/TokenItem.java line 88: > 86: > 87: public boolean hasValidBounds() { > 88: //This check is very formal, in order to filter out abnormal values very "rough" ? src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 62: > 60: private static final String REL_NAME = > 61: ".java/.robot/screencast-tokens.properties"; > 62: .java is already hidden. Why make .robot hidden ? src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 66: > 64: private static final Path PROPS_PATH; > 65: private static final Path PROP_FILENAME; > 66: private static final Object PROPS_LOCK = new Object(); Why do you need PROPS_LOCK to synchronize access to PROPS ? I don't see why you can't synchronize on PROPS directly ? src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 150: > 148: } > 149: > 150: private static class WatcherThread extends Thread { What is all this for ? Reading and writing a file doesn't need all this. src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 387: > 385: } > 386: > 387: try (OutputStream output = Files.newOutputStream(PROPS_PATH)) { Note that this stream is un-buffered (slow) https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Files.html#newOutputStream(java.nio.file.Path,java.nio.file.OpenOption...) Maybe doesn't matter given how small the file is. src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 43: > 41: > 42: #define EXCEPTION_CHECK_DESCRIBE_CLEAR() if ((*env)->ExceptionCheck(env)) { \ > 43: (*env)->ExceptionDescribe(env); \ Describe already clears the exception https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 375: > 373: DEBUG_SCREENCAST("@@@ using screen %i\n", index); > 374: if (index >= screenSpace.screenCount) { > 375: DEBUG_SCREENCAST("? Wrong index for screen\n", NULL); I've seen this "! in a triangle" symbol in a quite a few places in the DEBUG messages. Looks like you got some non-ascii char in there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210736642 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210738114 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210735716 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210744585 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210754519 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210749175 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210767223 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210788290 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1210799141 From serb at openjdk.org Tue May 30 21:23:54 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 30 May 2023 21:23:54 GMT Subject: RFR: 8296972: [macos13] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java: getExtendedState() != 6 as expected. In-Reply-To: References: Message-ID: On Tue, 30 May 2023 18:41:38 GMT, Alisen Chung wrote: > added displayChanged call to CPlatformWindow when frame first needs to deiconify or unmaximize > All client tests passed after change Why this method is not called automatically by our native code? what events are changed since macOS 13.0? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1569119372 From serb at openjdk.org Tue May 30 21:27:53 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 30 May 2023 21:27:53 GMT Subject: RFR: 8296972: [macos13] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java: getExtendedState() != 6 as expected. In-Reply-To: References: Message-ID: On Tue, 30 May 2023 18:41:38 GMT, Alisen Chung wrote: > added displayChanged call to CPlatformWindow when frame first needs to deiconify or unmaximize > All client tests passed after change BTW it is unclear what the call to "displayChanged" will fix. Will it set the correct "graphicsDevice", if yes then what gD was used before the call, if not then what property is updated by the "displayChanged"? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1569124595 From duke at openjdk.org Tue May 30 21:46:59 2023 From: duke at openjdk.org (JoKern65) Date: Tue, 30 May 2023 21:46:59 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: <-J0qbu5Ym0zr1WgUHHd2xw4qAwCsXrusMtlVCIH4snk=.d6571950-4708-430d-b119-150728407390@github.com> References: <-J0qbu5Ym0zr1WgUHHd2xw4qAwCsXrusMtlVCIH4snk=.d6571950-4708-430d-b119-150728407390@github.com> Message-ID: On Tue, 30 May 2023 18:42:54 GMT, Coleen Phillimore wrote: >> JoKern65 has updated the pull request incrementally with one additional commit since the last revision: >> >> forgotton _ > > src/hotspot/share/runtime/javaThread.cpp line 115: > >> 113: #include >> 114: #endif >> 115: > > Could these conditionals be included in globalDefinitions_xlc.hpp instead? In principle the `#include ` could be included in globalDefinitions_xlc.hpp. But alloca.h implements it with a `#undef alloca` `#define alloca(size) __builtin_alloca (size)` If this new global define does not introduce new trouble (even in future coding) when it is seen in every source, we can go this way. Are there any obstacles from anyone else? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1210853233 From psadhukhan at openjdk.org Wed May 31 03:11:59 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 31 May 2023 03:11:59 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v10] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 17:32:10 GMT, Alexey Ivanov wrote: >> This is because font-size attribute can have units or percentage in it, it seems like as is being tested in the regression test, 42px, 42pt so "svalue" is being used which will have 42px/42pt so we can compare the string value of 42px or 42pt otherwise we need to parse to get the integer 42 and then the units px or pt and then compared separately > > We should not parse the string, it's already parsed. > > What if I put a space between value and unit? These two strings should produce equal attribute sets: > > {"font-size: 42px", "font-size: 42 px"}, > > > The easiest way is to implement `LengthUnit.equals` which you still need for comparing `CSS.LengthValue` anyway because that class has exactly the same problem. You also compare the raw string there: > > https://github.com/openjdk/jdk/blob/612d5eba4c83ab53c797b03a244879261a5faa2a/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L2678-L2681 > > It doesn't look right to me. > > This is basically [a continuation of the same discussion](https://github.com/openjdk/jdk/pull/13405#discussion_r1202100159). I am not sure I understand...Where the string is parsed...Earlier in my previous iteration I was using Scanner util class to parse the string to extract integer 42 and px from 42px and comparing separately which I thought you were referring to as we should not parse in `equals` so I removed and I optimized to compare the string value `svalue` What are you suggesting then? I already told using your suggested code fails the regression test.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1211039400 From tr at openjdk.org Wed May 31 06:13:22 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 31 May 2023 06:13:22 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v8] In-Reply-To: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: > This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. > The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. Tejesh R 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 10 additional commits since the last revision: - Merge Master + Updated based on review comments - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8307105 - Updated new fix - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8307105 - White space fix - Alternate Fix - Updated based on review comments - Updated based on review comments - Updated based on review comments - Fix + Manual Test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13998/files - new: https://git.openjdk.org/jdk/pull/13998/files/a946c73a..a8beb1ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=06-07 Stats: 5946 lines in 157 files changed: 4468 ins; 813 del; 665 mod Patch: https://git.openjdk.org/jdk/pull/13998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13998/head:pull/13998 PR: https://git.openjdk.org/jdk/pull/13998 From tr at openjdk.org Wed May 31 06:16:02 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 31 May 2023 06:16:02 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v7] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: On Tue, 30 May 2023 09:06:16 GMT, Alexey Ivanov wrote: >> Tejesh R 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 eight additional commits since the last revision: >> >> - Updated new fix >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8307105 >> - White space fix >> - Alternate Fix >> - Updated based on review comments >> - Updated based on review comments >> - Updated based on review comments >> - Fix + Manual Test > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 867: > >> 865: cachedIsLink = hasAttribute(ATTRIB_LINK) >> 866: && (!isFileSystem() >> 867: || getPath().toLowerCase().endsWith(".lnk")); > > At the very least, you should indent `||` farther because it's inside the parentheses (the condition is `c1 && (!c2 || c3)`), otherwise it could be misinterpreted as `c1 && !c2 || c3` which is completely different. > Suggestion: > > cachedIsLink = hasAttribute(ATTRIB_LINK) > && (!isFileSystem() > || getPath().toLowerCase().endsWith(".lnk")); > > > However, my personal preference is to align wrapped lines to the start of their corresponding part of the expression: > Suggestion: > > cachedIsLink = hasAttribute(ATTRIB_LINK) > && (!isFileSystem() > || getPath().toLowerCase().endsWith(".lnk")); > > > Either way is fine. Updated to second suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1211134303 From jwaters at openjdk.org Wed May 31 07:08:55 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 31 May 2023 07:08:55 GMT Subject: RFR: 8308780: Fix the Java Integer types on Windows In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com> References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com> Message-ID: On Wed, 24 May 2023 13:56:05 GMT, Julian Waters wrote: > On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code Bumping :( ------------- PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1569611758 From mkartashev at openjdk.org Wed May 31 07:33:57 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Wed, 31 May 2023 07:33:57 GMT Subject: RFR: 8308875: java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java failed with 'Cannot invoke "sun.awt.X11GraphicsDevice.getInsets()" because "device" is null' In-Reply-To: References: Message-ID: On Fri, 26 May 2023 08:19:09 GMT, Maxim Kartashev wrote: > 8308875 is a regression after the recent [fix for 8305578](https://github.com/openjdk/jdk/commit/d7245f70) that effectively undid a part of [another, older, change](https://github.com/openjdk/jdk/commit/40f6d697d25293282e3d3ee695ef8cd9a5494799), the one made to fix [8233573](https://bugs.openjdk.org/browse/JDK-8233573). > > This commits brings that part back and passes the test `java/awt/Toolkit/GetScreenInsetsCustomGC/GetScreenInsetsCustomGC.java` on Linux, so the test is also removed from the ProblemList file. @mrserb Could you take a look at this one, please? I believe it reinstates the fix ([8233573](https://bugs.openjdk.org/browse/JDK-8233573)) that you originally made. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14170#issuecomment-1569648355 From duke at openjdk.org Wed May 31 08:21:57 2023 From: duke at openjdk.org (JoKern65) Date: Wed, 31 May 2023 08:21:57 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: <-J0qbu5Ym0zr1WgUHHd2xw4qAwCsXrusMtlVCIH4snk=.d6571950-4708-430d-b119-150728407390@github.com> Message-ID: On Tue, 30 May 2023 21:44:17 GMT, JoKern65 wrote: >> src/hotspot/share/runtime/javaThread.cpp line 115: >> >>> 113: #include >>> 114: #endif >>> 115: >> >> Could these conditionals be included in globalDefinitions_xlc.hpp instead? > > In principle the `#include ` could be included in globalDefinitions_xlc.hpp. But alloca.h implements it with a > `#undef alloca` > `#define alloca(size) __builtin_alloca (size)` > If this new global define does not introduce new trouble (even in future coding) when it is seen in every source, we can go this way. > Are there any obstacles from anyone else? At least the whole jdk actually builds with `#include ` in globalDefinitions_xlc.hpp ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1211272616 From tr at openjdk.org Wed May 31 08:56:05 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 31 May 2023 08:56:05 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v7] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: On Tue, 30 May 2023 09:10:03 GMT, Alexey Ivanov wrote: >> Tejesh R 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 eight additional commits since the last revision: >> >> - Updated new fix >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8307105 >> - White space fix >> - Alternate Fix >> - Updated based on review comments >> - Updated based on review comments >> - Updated based on review comments >> - Fix + Manual Test > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 862: > >> 860: //Checks only if it's .lnk shortcut link. Other two links >> 861: //namely Symbolic and Junctions returns false, so that the >> 862: //absolute path can be resolved. > > Should it be included inside the javadoc as an `@implNote`? The class isn't public so we can change it, and it is more helpful because it's shown right away without opening source code for the method. Adding as `@implNote` would be better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1211135049 From aivanov at openjdk.org Wed May 31 08:57:10 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 May 2023 08:57:10 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v10] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 17:18:42 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2219: >> >>> 2217: public int hashCode() { >>> 2218: return Float.hashCode(value); >>> 2219: } >> >> why isn't index and lu part of this ? > > It is because only the float "value" is being considered and not the `lu` units px/pt Yet `equals` currently just compares `svalue`? It looks weird. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1211319419 From aivanov at openjdk.org Wed May 31 08:57:11 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 May 2023 08:57:11 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v10] In-Reply-To: References: Message-ID: On Wed, 31 May 2023 03:09:12 GMT, Prasanta Sadhukhan wrote: > I already told using your suggested code fails the regression test.. Which regression test do you refer to? The one for `AttributeSet.equals` or another? I can't see how implementing `equals` could affect other tests? unless some tests already use `AttributeSet.equals`. If the test being developed fails, it means the implementation in `CSS` is wrong. I haven't been able to thinker with the code myself. > What are you suggesting then? Neither parsing the string nor using the raw string seems right. The object already contains the parsed data as a set of fields: `value`, `index`, `lu`. https://github.com/openjdk/jdk/blob/927a9ed68371597eba1609f97ac03dd1de812e26/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L2203-L2205 I think the fields should be used in the implementation of the `equals` method, and, as [I already noted](https://github.com/openjdk/jdk/pull/13405#discussion_r1200351364), it should look something like this: @Override public boolean equals(Object val) { return val instanceof CSS.FontSize size && value == size.value && index == size.index && Objects.equals(lu, size.lu); } Using `Objects.equals` handles `null` values in `lu` fields gracefully. At the same time, this requires that `LengthUnit` implements `equals`. I suggested an implementation without `LengthUnit.equals`, it was probably incorrect because I didn't test it; however, implementing `LengthUnit.equals` is a better solution. @Override public boolean equals(Object obj) { return obj instanceof LengthUnit ou && type == ou.type && value == ou.value && Objects.equals(units, ou.units); } (Okay, I thought `CSS.LengthValue` also uses `LengthUnit` class but it doesn't, or rather it doesn't have it as a field, units are stored as a `String` value there.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1211318063 From aivanov at openjdk.org Wed May 31 09:08:13 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 May 2023 09:08:13 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v8] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: <1X0vJzmYBwsAHbYEMiuvp5K_9kfG2Lfe0xvkr6zwRuA=.18697d15-219c-47fa-adae-884405b4c4dc@github.com> On Wed, 31 May 2023 06:13:22 GMT, Tejesh R wrote: >> This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. >> The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. > > Tejesh R 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 10 additional commits since the last revision: > > - Merge Master + Updated based on review comments > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8307105 > - Updated new fix > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8307105 > - White space fix > - Alternate Fix > - Updated based on review comments > - Updated based on review comments > - Updated based on review comments > - Fix + Manual Test Changes requested by aivanov (Reviewer). src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 861: > 859: * @implNote Checks only if it is .lnk shortcut link. Other two links > 860: * namely Symbolic and Junctions returns false, so that the > 861: * absolute path can be resolved. Suggestion: * * @implNote Returns {@code true} for {@code .lnk} shortcuts only. * For symbolic links and junctions, it returns * {@code false} even though {@code IShellFolder} returns * {@code true} now. It is a workaround for easier handling of * symbolic links and junctions. The text may still be imperfect, however I hope, it explains the reasons clearer. src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 868: > 866: cachedIsLink = hasAttribute(ATTRIB_LINK) > 867: && (!isFileSystem() > 868: || getPath().toLowerCase().endsWith(".lnk")); Suggestion: cachedIsLink = hasAttribute(ATTRIB_LINK) && (!isFileSystem() || getPath().toLowerCase().endsWith(".lnk")); One space less, the first ampersand in `&&` should align with `h` on the line above. ------------- PR Review: https://git.openjdk.org/jdk/pull/13998#pullrequestreview-1452558817 PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1211332971 PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1211321342 From psadhukhan at openjdk.org Wed May 31 09:28:04 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 31 May 2023 09:28:04 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v10] In-Reply-To: References: Message-ID: <_0_Zi5KB9ITmsCSiQ6L8M6esZBKbaq-8qz76pfiEoe8=.6059e738-4c36-4043-8fe6-9b598da8841a@github.com> On Wed, 31 May 2023 08:53:56 GMT, Alexey Ivanov wrote: >> It is because only the float "value" is being considered and not the `lu` units px/pt > > Yet `equals` currently just compares `svalue`? It looks weird. It might looks weird but it is the one which is working. For example, for `{"font-size: 42px", "font-size: 22px"}` `value` is 0.0 `svalue` is 42px, 22px index false lu.units px so if I check return val instanceof CSS.FontSize size && value == size.value && index == size.index && Objects.equals(lu, size.lu); it will return equals `true `even though it should not be equal which is why I used `svalue` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1211357733 From aivanov at openjdk.org Wed May 31 09:50:58 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 May 2023 09:50:58 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v10] In-Reply-To: <_0_Zi5KB9ITmsCSiQ6L8M6esZBKbaq-8qz76pfiEoe8=.6059e738-4c36-4043-8fe6-9b598da8841a@github.com> References: <_0_Zi5KB9ITmsCSiQ6L8M6esZBKbaq-8qz76pfiEoe8=.6059e738-4c36-4043-8fe6-9b598da8841a@github.com> Message-ID: On Wed, 31 May 2023 09:23:38 GMT, Prasanta Sadhukhan wrote: >> Yet `equals` currently just compares `svalue`? It looks weird. > > It might looks weird but it is the one which is working. > For example, for `{"font-size: 42px", "font-size: 22px"}` > > `value` is 0.0 > `svalue` is 42px, 22px > `index` false > `lu.units` px > so if I check > > > return val instanceof CSS.FontSize size > && value == size.value > && index == size.index > && Objects.equals(lu, size.lu); > > > > it will return equals `true `even though it should not be equal which is why I used `svalue` This is why you have to compare the entire value of `LengthUnit` as [I described above](https://github.com/openjdk/jdk/pull/13405#discussion_r1211318063). >From a quick debugging session, `"font-size: 42px"` is parsed into the following values: CSS$FontSize value = 0.0 index = false svalue = "42px" lu = {CSS$LengthUnit at 1594} "0 42.0" type = 0 value = 42.0 units = "px" `"font-size: 22px"` is parsed into: CSS$FontSize value = 0.0 index = false svalue = "22px" lu = {CSS$LengthUnit at 1594} "0 22.0" type = 0 value = 22.0 units = "px" So [the implementation I suggested today](https://github.com/openjdk/jdk/pull/13405#discussion_r1211318063) for `FontSize.equals` and `LengthUnit.equals` handles it correctly. The one that [I suggested last week](https://github.com/openjdk/jdk/pull/13405#discussion_r1200351364) which avoids implementing `LengthUnit.equals` does not work because it takes into account only the `units` field of the `LengthUnit` object. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1211390695 From tr at openjdk.org Wed May 31 09:52:29 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 31 May 2023 09:52:29 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v9] In-Reply-To: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: <8P8nGL9YPnpUETFjUG4NlyvaTsXFOEDm1giWGqprWPU=.cac42ee9-b768-4d53-9621-3db97e8016c5@github.com> > This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. > The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13998/files - new: https://git.openjdk.org/jdk/pull/13998/files/a8beb1ed..7c815222 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=07-08 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13998/head:pull/13998 PR: https://git.openjdk.org/jdk/pull/13998 From aivanov at openjdk.org Wed May 31 09:55:12 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 May 2023 09:55:12 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v9] In-Reply-To: <8P8nGL9YPnpUETFjUG4NlyvaTsXFOEDm1giWGqprWPU=.cac42ee9-b768-4d53-9621-3db97e8016c5@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> <8P8nGL9YPnpUETFjUG4NlyvaTsXFOEDm1giWGqprWPU=.cac42ee9-b768-4d53-9621-3db97e8016c5@github.com> Message-ID: On Wed, 31 May 2023 09:52:29 GMT, Tejesh R wrote: >> This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. >> The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Marked as reviewed by aivanov (Reviewer). src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 864: > 862: cachedIsLink = hasAttribute(ATTRIB_LINK); > 863: } > 864: Let's preserve this blank line. ------------- PR Review: https://git.openjdk.org/jdk/pull/13998#pullrequestreview-1452674513 PR Review Comment: https://git.openjdk.org/jdk/pull/13998#discussion_r1211395090 From tr at openjdk.org Wed May 31 10:06:30 2023 From: tr at openjdk.org (Tejesh R) Date: Wed, 31 May 2023 10:06:30 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v10] In-Reply-To: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: > This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. > The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13998/files - new: https://git.openjdk.org/jdk/pull/13998/files/7c815222..ac00b104 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13998&range=08-09 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13998.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13998/head:pull/13998 PR: https://git.openjdk.org/jdk/pull/13998 From aivanov at openjdk.org Wed May 31 10:06:30 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 May 2023 10:06:30 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v10] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: On Wed, 31 May 2023 10:01:16 GMT, Tejesh R wrote: >> This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. >> The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13998#pullrequestreview-1452706212 From abhiscxk at openjdk.org Wed May 31 12:42:04 2023 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 31 May 2023 12:42:04 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v10] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: <9naUoRIRbCyccAaMroCuNhpcIaL0S-qjaWgObI-xco0=.e3c7801b-41f0-4a6a-98ce-051e508ae964@github.com> On Wed, 31 May 2023 10:06:30 GMT, Tejesh R wrote: >> This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. >> The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Marked as reviewed by abhiscxk (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13998#pullrequestreview-1453106433 From psadhukhan at openjdk.org Wed May 31 12:55:45 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 31 May 2023 12:55:45 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v12] In-Reply-To: References: Message-ID: > Two CSS AttributeSet-s can be compared using the AttributeSet.isEqual() method which can fail due to missing implementation of equals method in CSS subclasses. > In this issue, even when two CSS AttributeSet has same 42 font size string value, Object equality fails. > Fixed by implementing the equality and hashCode method for CSS.FontSize class. > > All jtreg/jck tests are ok Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Use local objects for FontSize as per review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13405/files - new: https://git.openjdk.org/jdk/pull/13405/files/612d5eba..a7214bac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13405&range=10-11 Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13405/head:pull/13405 PR: https://git.openjdk.org/jdk/pull/13405 From psadhukhan at openjdk.org Wed May 31 12:55:47 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 31 May 2023 12:55:47 GMT Subject: RFR: 7083187: Class CSS.CssValue is missing implementations of equals() and hashCode() [v10] In-Reply-To: References: <_0_Zi5KB9ITmsCSiQ6L8M6esZBKbaq-8qz76pfiEoe8=.6059e738-4c36-4043-8fe6-9b598da8841a@github.com> Message-ID: On Wed, 31 May 2023 09:47:50 GMT, Alexey Ivanov wrote: >> It might looks weird but it is the one which is working. >> For example, for `{"font-size: 42px", "font-size: 22px"}` >> >> `value` is 0.0 >> `svalue` is 42px, 22px >> `index` false >> `lu.units` px >> so if I check >> >> >> return val instanceof CSS.FontSize size >> && value == size.value >> && index == size.index >> && Objects.equals(lu, size.lu); >> >> >> >> it will return equals `true `even though it should not be equal which is why I used `svalue` > > This is why you have to compare the entire value of `LengthUnit` as [I described above](https://github.com/openjdk/jdk/pull/13405#discussion_r1211318063). > > From a quick debugging session, `"font-size: 42px"` is parsed into the following values: > > > CSS$FontSize > value = 0.0 > index = false > svalue = "42px" > lu = {CSS$LengthUnit at 1594} "0 42.0" > type = 0 > value = 42.0 > units = "px" > > `"font-size: 22px"` is parsed into: > > CSS$FontSize > value = 0.0 > index = false > svalue = "22px" > lu = {CSS$LengthUnit at 1594} "0 22.0" > type = 0 > value = 22.0 > units = "px" > > > So [the implementation I suggested today](https://github.com/openjdk/jdk/pull/13405#discussion_r1211318063) for `FontSize.equals` and `LengthUnit.equals` handles it correctly. > > The one that [I suggested last week](https://github.com/openjdk/jdk/pull/13405#discussion_r1200351364) which avoids implementing `LengthUnit.equals` does not work because it takes into account only the `units` field of the `LengthUnit` object. OK. Thanks for the suggestion..Updated `FontSize.equals` and `LenghtUnit.equals` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13405#discussion_r1211666980 From asemenov at openjdk.org Wed May 31 13:37:06 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Wed, 31 May 2023 13:37:06 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v3] In-Reply-To: References: Message-ID: > When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". > They can be fixed with small changes. Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14033/files - new: https://git.openjdk.org/jdk/pull/14033/files/3f343c26..d5b70cb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033 PR: https://git.openjdk.org/jdk/pull/14033 From asemenov at openjdk.org Wed May 31 13:40:57 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Wed, 31 May 2023 13:40:57 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v3] In-Reply-To: <_RQshJQSfZfWSXTPvIjEekBkNIJCGy6UPHo_94bE5IM=.afc7036a-4553-45f2-b5d2-76758e69dbb4@github.com> References: <_RQshJQSfZfWSXTPvIjEekBkNIJCGy6UPHo_94bE5IM=.afc7036a-4553-45f2-b5d2-76758e69dbb4@github.com> Message-ID: On Sun, 28 May 2023 03:57:40 GMT, Kim Barrett wrote: >> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: >> >> update > > src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c line 1163: > >> 1161: #if defined(__clang__) >> 1162: #pragma clang diagnostic push >> 1163: #pragma clang diagnostic ignored "-Wparentheses" > > I think this warning is because of the several `if (init_result = ...)`? Better would be to just add the extra parens. done > src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 575: > >> 573: if (ps_pdread(ph, (char *)link_map_addr + LINK_MAP_LD_OFFSET, >> 574: &lib_ld, sizeof(uintptr_t)) != PS_OK) { >> 575: #else > > What problem is being "fixed" by these? I'm dubious that this is the best solution to whatever the problem > is, but can't evaluate or suggest alternatives without knowing what it is. done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211733228 PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211732832 From asemenov at openjdk.org Wed May 31 13:41:04 2023 From: asemenov at openjdk.org (Artem Semenov) Date: Wed, 31 May 2023 13:41:04 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v2] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 08:14:59 GMT, Alexey Ushakov wrote: >> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: >> >> update > > src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 655: > >> 653: // linker loaded it. We use "base diff" in read_lib_segments call below. >> 654: >> 655: if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_ADDR_OFFSET, > > Extra white spaces before 'if' done > src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 662: > >> 660: >> 661: // read address of the name >> 662: if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NAME_OFFSET, > > Extra white-spaces before 'if' done > src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 717: > >> 715: >> 716: // read next link_map address >> 717: if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NEXT_OFFSET, > > Extra white-spaces before 'if' done > src/jdk.jpackage/share/native/common/tstrings.cpp line 60: > >> 58: #endif >> 59: // With g++ this compiles only with '-std=gnu++0x' option >> 60: ret = vsnprintf(&*fmtout.begin(), fmtout.size(), format, args); > > Extra white-spaces before 'ret' done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211732345 PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211734132 PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211734711 PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211735111 From weijun at openjdk.org Wed May 31 13:55:57 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 31 May 2023 13:55:57 GMT Subject: RFR: 8308286 Fix clang warnings in linux code [v3] In-Reply-To: References: Message-ID: On Wed, 31 May 2023 13:37:06 GMT, Artem Semenov wrote: >> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors". >> They can be fixed with small changes. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > update src/java.security.jgss/share/native/libj2gss/gssapi.h line 47: > 45: > 46: // Condition was copied from > 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h In the current version of the file above, it's written as #if defined(__APPLE__) && (defined(__ppc__) ||... Is it better? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211757380 From azvegint at openjdk.org Wed May 31 15:03:04 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 31 May 2023 15:03:04 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: References: Message-ID: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> > Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. > This comes with some difficulties, and one of them is the inability to get screenshots from the system. > This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) > > But this functionality is a very important part of automated testing. > > > At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): > > 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) > It has several drawbacks though: > + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). > + There is no way to disable the visual "screen flash" after screenshot > + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. > Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. > But we still can consider this option as a fallback. > > > > 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) > It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. > This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. > > + implementation is more complicated comparing to Screenshot API > + no intermediate file, screenshot data can be obtained from memory > + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) > > > So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. > > This change also introduces some new behavior for the robot: > A system window now appears asking for confirmation from the user to capture the screen. > + The user can refuse the screen capture completely. In this case a security exception will be thrown. > + The user can allow a screen capture for all screens o... Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: - improve retVal processing - address token storage comments - removing non-ascii - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13803/files - new: https://git.openjdk.org/jdk/pull/13803/files/257445f4..389cfd73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13803&range=07-08 Stats: 107 lines in 7 files changed: 23 ins; 13 del; 71 mod Patch: https://git.openjdk.org/jdk/pull/13803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13803/head:pull/13803 PR: https://git.openjdk.org/jdk/pull/13803 From azvegint at openjdk.org Wed May 31 15:06:04 2023 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 31 May 2023 15:06:04 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v8] In-Reply-To: References: Message-ID: On Tue, 30 May 2023 19:33:20 GMT, Phil Race wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> fix macos build > > src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 139: > >> 137: >> 138: for (TokenItem tokenItem : tokensForRectangle) { >> 139: retVal = getRGBPixelsImpl( > > This can't be right. You surely want to check all cases of retVal not just the last one. Updated. > src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 62: > >> 60: private static final String REL_NAME = >> 61: ".java/.robot/screencast-tokens.properties"; >> 62: > > .java is already hidden. Why make .robot hidden ? Updated. > src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 150: > >> 148: } >> 149: >> 150: private static class WatcherThread extends Thread { > > What is all this for ? Reading and writing a file doesn't need all this. This is to work from multiple VM with the file. We only read the file the first time we use `createScreenCapture` and when another VM externally modifies the file. Alternatively we could read it before each use of `createScreenCapture`, but I wanted to avoid unnecessary reading and reduce the possible simultaneous writing and reading time. > src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 387: > >> 385: } >> 386: >> 387: try (OutputStream output = Files.newOutputStream(PROPS_PATH)) { > > Note that this stream is un-buffered (slow) > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Files.html#newOutputStream(java.nio.file.Path,java.nio.file.OpenOption...) > Maybe doesn't matter given how small the file is. Moved to newBufferedWriter/Readed > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 43: > >> 41: >> 42: #define EXCEPTION_CHECK_DESCRIBE_CLEAR() if ((*env)->ExceptionCheck(env)) { \ >> 43: (*env)->ExceptionDescribe(env); \ > > Describe already clears the exception > https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptiondescribe Updated. > src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 375: > >> 373: DEBUG_SCREENCAST("@@@ using screen %i\n", index); >> 374: if (index >= screenSpace.screenCount) { >> 375: DEBUG_SCREENCAST("? Wrong index for screen\n", NULL); > > I've seen this "! in a triangle" symbol in a quite a few places in the DEBUG messages. > Looks like you got some non-ascii char in there. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1211860159 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1211860753 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1211727223 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1211865131 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1211864955 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1211866052 From dnguyen at openjdk.org Wed May 31 16:00:15 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 31 May 2023 16:00:15 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v10] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: <1oPV4dprYa40tu5fpNaDAXwQ37zuTVlHdxVqKYFMHYY=.88ade712-874e-4f7b-a2a2-49f023a01b16@github.com> On Wed, 31 May 2023 10:06:30 GMT, Tejesh R wrote: >> This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. >> The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Marked as reviewed by dnguyen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13998#pullrequestreview-1453606312 From dnguyen at openjdk.org Wed May 31 16:06:03 2023 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 31 May 2023 16:06:03 GMT Subject: RFR: 8307105: JFileChooser InvalidPathException when selecting some system folders on Windows [v10] In-Reply-To: References: <_Z_tjw8MJu10XV_mkx1Hxl5CoxY4Jmes4DkgXDrhIdY=.756d3934-3231-4911-96f8-2718f5646d58@github.com> Message-ID: On Wed, 31 May 2023 10:06:30 GMT, Tejesh R wrote: >> This is a regression from fix [JDK-8281966](https://bugs.openjdk.org/browse/JDK-8281966): Absolute path of symlink is null in JFileChooser. The fix checks whether the file path is a symbolic link using `Files.isSymbolicLink()` method with path as input. In windows for specific folders like "This PC"/"Network"/"Libraries" the path value will be a hex values which causes InvalidPathException. In order to resolve the issue, since no other checks are available to validate the path of these folders, checking if the file is link firstly and then for symbolic link resolves the problem (since File.isLink() doesn't take path as input rather file is a parameter). Since every symbolic link is a link, this fix seems logical to me. >> The fix is tested in CI for regression and is green. The regression fix is also tested for confirmation and works fine. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Updated based on review comments Changes LGTM now ------------- PR Comment: https://git.openjdk.org/jdk/pull/13998#issuecomment-1570513025 From prr at openjdk.org Wed May 31 20:22:14 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 31 May 2023 20:22:14 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE I'm getting pretty consistent testing results now - meaning the ones that have known issues are the ones that fail, and I've looked at the code sufficiently. The restore token seems to be behaving properly now. I did have one case I've not understood where a test system got very confused about the display resolution of the monitor and needed a full power cycle. I don't know if a specific test caused that or it was something else, but it isn't repeatable (at least not yet) so shouldn't block integration. I am quite sure that SOME of the test failures are unstable tests that we've been lucky with all these years and xwayland is now showing up the instability. Things un-related to robot and more about timing for the most part. Although there's one test that seriously over-stresses robot with > 10,000 calls in a loop to getPixelColor() I'll see if I can push test update fixes to at least some of these to reduce noise. But I'm OK to approve now. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13803#pullrequestreview-1454093265 From prr at openjdk.org Wed May 31 20:28:18 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 31 May 2023 20:28:18 GMT Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2] In-Reply-To: References: Message-ID: On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote: >> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors". >> Some of those are in shared codebase and could be addressed by small adjustments. >> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code. > > JoKern65 has updated the pull request incrementally with one additional commit since the last revision: > > forgotton _ I am Ok with the client-libs changes here. I did not look at anything else. So you'll need more approvals before its ready to push. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14146#pullrequestreview-1454101589 From jjg at openjdk.org Wed May 31 20:35:20 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 31 May 2023 20:35:20 GMT Subject: RFR: JDK-8305593: Add @spec tags in java.desktop [v2] In-Reply-To: References: Message-ID: <1pzy8_QMxIKFj-P-BCPMxiKcs-kME72cWvBnYJHgdZQ=.cc7dbbab-d2e9-4dd1-8282-7fe32fe18fc0@github.com> > Please review a docs-only change to add `@spec` tags into `java.desktop` public API files Jonathan Gibbons 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 since the last revision: - Update narrative references to use `rfc-editor.org` instead of (variants of) `ietf.org` - Merge remote-tracking branch 'upstream/master' into 8305593.at-spec-java.desktop - JDK-8305593: Add @spec tags in java.desktop ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13360/files - new: https://git.openjdk.org/jdk/pull/13360/files/374a088c..fcccc85f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13360&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13360&range=00-01 Stats: 493097 lines in 5807 files changed: 403689 ins; 46411 del; 42997 mod Patch: https://git.openjdk.org/jdk/pull/13360.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13360/head:pull/13360 PR: https://git.openjdk.org/jdk/pull/13360 From aturbanov at openjdk.org Wed May 31 20:56:21 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 31 May 2023 20:56:21 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE make/modules/java.desktop/lib/Awt2dLibraries.gmk line 195: > 193: > 194: LIBPIPEWIRE_HEADER_DIRS := \ > 195: $(TOPDIR)/src/$(MODULE)/unix/native/libpipewire/include Are you sure Tab should be used here? in all other places of this file spaces are used for indentation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212298738 From aturbanov at openjdk.org Wed May 31 21:09:15 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 31 May 2023 21:09:15 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: <49V03ZEKWKUCrE9mQixXApM_Kij9pdTKY-Uu2NLW3N8=.cfe72533-5cce-4470-9322-801a93ad99e0@github.com> On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 303: > 301: > 302: Set> entries; > 303: synchronized (PROPS) { I'm not sure I understand purpose of this `synchronized` block. `entrySet()` returns _view_ of Properties entries, not a copy. It means concurrent thread could modify content of `PROPS` when we do `stream()` below. >From my opinion either we need to perform all work inside `synchronized` to be sure that no concurrent modification are possible. Or just remove `synchronized` (`Properties` is a thread safe class) and _be ready_ of possible concurrent updates ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212313046 From aturbanov at openjdk.org Wed May 31 21:18:15 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 31 May 2023 21:18:15 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE src/java.desktop/unix/classes/sun/awt/screencast/TokenItem.java line 111: > 109: > 110: public static TokenItem parse(String token, Object input) { > 111: if (token == null || input == null) return null; Do we need this `null` checks? Currently only non-null values are passed to this method ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212323291 From aturbanov at openjdk.org Wed May 31 21:24:12 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 31 May 2023 21:24:12 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 307: > 305: } > 306: > 307: Set malformed = new LinkedHashSet<>(); Can we use plain HashSet here? Seems there is not much reason to save original order of tokens. src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 320: > 318: return tokenItem; > 319: }) > 320: .filter(obj -> !Objects.isNull(obj)) `Objects.isNull` wasn't supposed to be used like this. Let's either inline it and use `!= null` or use method reference `.filter(Objects::nonNull)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212328710 PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212326672 From aturbanov at openjdk.org Wed May 31 21:38:12 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 31 May 2023 21:38:12 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE src/java.desktop/unix/classes/sun/awt/screencast/TokenStorage.java line 346: > 344: rectangle.height > 345: )) > 346: .collect(Collectors.toCollection(ArrayList::new)); why not plain toList() collector? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13803#discussion_r1212340873 From aivanov at openjdk.org Wed May 31 21:44:10 2023 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 May 2023 21:44:10 GMT Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env [v6] In-Reply-To: References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com> Message-ID: On Tue, 30 May 2023 16:04:55 GMT, Alexey Ivanov wrote: >> src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 131: >> >>> 129: } >>> 130: dpiAwareWidgetToTheme.get(dpi).clear(); >>> 131: dpiAwareWidgetToTheme.clear(); >> >> Suggestion: >> >> for (Map dpiVal : dpiAwareWidgetToTheme.values()) { >> for (Long value : dpiVal.values()) { >> closeTheme(value); >> } >> dpiVal.clear(); >> } >> dpiAwareWidgetToTheme.clear(); >> >> Avoid additional call to `get`. > > This is even more serious: all the theme handles are closed but the maps for DPIs other than the passed `dpi` aren't cleared. With `clear` inside the loop, maps for all DPIs are cleared. I've thought about it more, and I was **wrong**. Clearing the `dpiVal` map isn't needed at all because as the next step the outer map gets cleared, meaning that maps with theme handles are thrown away. Thus, no need to waste time to run `dpiVal.clear()` ? `dpiAwareWidgetToTheme.clear()` takes care of those too. That is remove the line `dpiVal.clear()`, please. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1212347708 From serb at openjdk.org Wed May 31 22:28:35 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 31 May 2023 22:28:35 GMT Subject: RFR: 8308152: PropertyDescriptor should work with overridden generic getter method Message-ID: Description of the bug, copied from https://github.com/openjdk/jdk/pull/7190 > In jdk 9 we started to sort the list of methods for each class for two reasons: > 1. We had a number of bugs which state that our JavaBeans randomly does not work, examples: JDK-6807471[1] , JDK-6788525[2], the reason was that the order of methods from Class.getMethods() is not specified. > 2. We tried to sort methods so the more specific returns types come first, this was done because our logic for selecting the correct method did not work properly. > > The second issue above was fixed by the separate change [JDK-8196373](https://bugs.openjdk.java.net/browse/JDK-8196373) so now we only need to sort the list of methods in any order and do not care about return types. > Unfortunatly it was found that we have two code paths to create a PropertyDescriptor, one of them is used by the `Introspector.getBeanInfo` and was patched by the [JDK-8196373](https://bugs.openjdk.java.net/browse/JDK-8196373) and another when the PropertyDescriptor is created directly and it still affected by that bug. The code added by this patch is the same we already use in PropertyInfo.java, see https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/beans/introspect/PropertyInfo.java#L81 ------------- Commit messages: - 8308152: PropertyDescriptor should work with overridden generic getter method Changes: https://git.openjdk.org/jdk/pull/14228/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14228&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308152 Stats: 107 lines in 2 files changed: 105 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14228.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14228/head:pull/14228 PR: https://git.openjdk.org/jdk/pull/14228 From prr at openjdk.org Wed May 31 22:35:15 2023 From: prr at openjdk.org (Phil Race) Date: Wed, 31 May 2023 22:35:15 GMT Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v9] In-Reply-To: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> References: <7zH3TcYwH9q2Dd7r2qRDA4oNRfzihwSS5loKCfOBBks=.8d776665-6fdb-4581-89ee-f45cca7c87ba@github.com> Message-ID: <-FJMSrpWiLdsZ902c4-dmdU6CxJecnoHtUhqJmtKlf4=.b60c9934-62d3-49ad-b96f-39190b6a89e3@github.com> On Wed, 31 May 2023 15:03:04 GMT, Alexander Zvegintsev wrote: >> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default. >> This comes with some difficulties, and one of them is the inability to get screenshots from the system. >> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) >> >> But this functionality is a very important part of automated testing. >> >> >> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal): >> >> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot) >> It has several drawbacks though: >> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive). >> + There is no way to disable the visual "screen flash" after screenshot >> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. >> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot. >> But we still can consider this option as a fallback. >> >> >> >> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast) >> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming. >> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API. >> >> + implementation is more complicated comparing to Screenshot API >> + no intermediate file, screenshot data can be obtained from memory >> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources) >> >> >> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default. >> >> This change also introduces some new behavior for the robot: >> A system window now appears asking for confirmation from the user to capture the screen. >> + The user can refuse the screen capture completely. In this case a security exception will be thrown. >> + The user can allow... > > Alexander Zvegintsev has updated the pull request incrementally with four additional commits since the last revision: > > - improve retVal processing > - address token storage comments > - removing non-ascii > - EXCEPTION_CHECK_DESCRIBE_CLEAR -> EXCEPTION_CHECK_DESCRIBE I spoke too soon :-( I remembered about an odd result from last week and it seems that whenever I have a full screen window capture fails - at least on my system and I think one lab system. See test and output below from a fully patched Ubuntu 22.04.02 system import java.awt.Frame; import java.awt.GraphicsDevice; import java.awt.Rectangle; import java.awt.Robot; public class FSW { public static void main(String args[]) throws Exception { Robot robot = new Robot(); Frame frame = new Frame("FSW"); GraphicsDevice gd = frame.getGraphicsConfiguration().getDevice(); try { gd.setFullScreenWindow(frame); robot.delay(5000); robot.createScreenCapture(new Rectangle(50, 50, 10, 10)); } finally { gd.setFullScreenWindow(null); frame.dispose(); } } } % java FSW cropTo:163 Unexpected stride / 4: 0 srcW: 1920 and the capture fails every time. And again with debugging turned on ScreencastWatcher: started // getRGBPixels affectedScreenBounds [java.awt.Rectangle[x=0,y=0,width=1920,height=1200]] // getTokens exact matches 1. [Token: 41dc61fb-279b-4069-b408-30873451fb03 java.awt.Rectangle[x=0,y=0,width=1920,height=1200] ] // getTokens same sizes 2. [Token: 41dc61fb-279b-4069-b408-30873451fb03 java.awt.Rectangle[x=0,y=0,width=1920,height=1200] ] // storeToken old: |41dc61fb-279b-4069-b408-30873451fb03| new |41dc61fb-279b-4069-b408-30873451fb03| allowed bounds [0, 0, 1920, 1200] // Storing TokenItem: Token: 41dc61fb-279b-4069-b408-30873451fb03 java.awt.Rectangle[x=0,y=0,width=1920,height=1200] initXdgDesktopPortal:236 connection/sender name :1.525 / 1_525 checkVersion:190 ScreenCast protocol version 4 Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl:833 taking screenshot at x: 50 y 50 w 10 h 10 with token |41dc61fb-279b-4069-b408-30873451fb03| initXdgDesktopPortal:236 connection/sender name :1.525 / 1_525 checkVersion:190 ScreenCast protocol version 4 callbackScreenCastStart:611 available screen count 1 rebuildScreenData:87 ==== screenId#35 rebuildScreenData:132 ----------------------- rebuildScreenData:133 screenId#35 || bounds x 0 y 0 w 1920 h 1200 || capture area x 0 y 0 w 0 h 0 shouldCapture 0 rebuildScreenData:134 #---------------------# callbackScreenCastStart:617 rebuildScreenData result |0| callbackScreenCastStart:630 restore_token |41dc61fb-279b-4069-b408-30873451fb03| storeRestoreToken:653 saving token, old: |41dc61fb-279b-4069-b408-30873451fb03| > new: |41dc61fb-279b-4069-b408-30873451fb03| portalScreenCastStart:709 ScreenCastStartResult |0| getPipewireFd:886 portalScreenCastStart result |0| checkCanCaptureAllRequiredScreens:847 Found allowed screen bounds in affected screen bounds 0 0 1920 1200 getPipewireFd:900 --- portalScreenCastStart getPipewireFd:907 pwFd 17 doLoop:557 screenId#35[loc(0,0) size(1920x1200)] @@@ adding screen 0 checkScreen:472 screenId#35 || bounds x 0 y 0 w 1920 h 1200 || capture area x 50 y 50 w 10 h 10 shouldCapture 1 connectStream:373 @@@ using screen 0 connectStream:411 screenId#35 || bounds x 0 y 0 w 1920 h 1200 || capture area x 50 y 50 w 10 h 10 shouldCapture 1 startStream:355 screenId#35: stream connecting 0x7f04548e3600 onStreamStateChanged:303 screenId#35[loc(0,0) size(1920x1200)] state 0 (unconnected) -> 1 (connecting) err (null) onStreamStateChanged:303 screenId#35[loc(0,0) size(1920x1200)] state 1 (connecting) -> 2 (paused) err (null) onStreamParamChanged:197 screenId#35[loc(0,0) size(1920x1200)] param event id 4 onStreamParamChanged:218 screenId#35[loc(0,0) size(1920x1200)] stream format: Spa:Enum:VideoFormat:BGRx (8) 1920x1200 connectStream:424 screenId#35[loc(0,0) size(1920x1200)] frame size: 1920x1200 doLoop:563 screenId#35[loc(0,0) size(1920x1200)] @@@ screen processed 0 onStreamStateChanged:303 screenId#35[loc(0,0) size(1920x1200)] state 2 (paused) -> 3 (streaming) err (null) onStreamProcess:236 screenId#35[loc(0,0) size(1920x1200)] hasFormat 1 captureDataReady 0 shouldCapture 1 onStreamProcess:271 screenId#35 || bounds x 0 y 0 w 1920 h 1200 || capture area x 50 y 50 w 10 h 10 shouldCapture 1 onStreamProcess:272 screenId#35[loc(0,0) size(1920x1200)] got a frame of size 0 offset 0 stride 0 flags 0 FD 31 captureDataReady 0 onStreamProcess:292 screenId#35[loc(0,0) size(1920x1200)] data ready Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl:856 all data ready Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl:864 screenId#35[loc(0,0) size(1920x1200)] @@@ copying screen data 0, captureData 0x7f03d40042a0 || x 50 y 50 w 10 h 10 requested area || x 0 y 0 w 1920 h 1200 screen bound || x 50 y 50 w 10 h 10 in-screen coords capture area onStreamParamChanged:197 screenId#35[loc(0,0) size(1920x1200)] param event id 4 onStreamStateChanged:303 screenId#35[loc(0,0) size(1920x1200)] state 3 (streaming) -> 2 (paused) err (null) onStreamStateChanged:303 screenId#35[loc(0,0) size(1920x1200)] state 2 (paused) -> 0 (unconnected) err (null) doCleanup:109 STOPPING loop ------------- PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-1571048110 From tehtmi at gmail.com Fri May 5 22:22:53 2023 From: tehtmi at gmail.com (tehtmi) Date: Fri, 05 May 2023 22:22:53 -0000 Subject: Why was JDK-8253530 closed? Message-ID: <217ef716-98e3-d575-1c70-2bfbe02ab965@gmail.com> Hi, JDK-8253530 (which I originally submitted) was closed as "not an issue" with no comment. Can someone please explain why? I still think this is a bug (rendering garbage in non-integer HiDPI scaling), and I re-checked that it exists in jdk 20. I am happy to provide more information or write a more appropriate bug report if that would be helpful. Thanks!