Re: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v5]
On Mon, 22 May 2023 08:51:13 GMT, George Adams wrote: >> Deprecate the Windows x86-32 port, with the intent to remove it in a future >> release. > > George Adams 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 remote-tracking branch 'upstream/master' into jep449 > - fixup > - update wording from review > - typo fix > - fix wording > - 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port > for Removal Thanks for the update - PR Review: https://git.openjdk.org/jdk/pull/13852#pullrequestreview-1438204051
Re: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v5]
> 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=13803=04 - incr: https://webrevs.openjdk.org/?repo=jdk=13803=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
Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v4]
> 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=14064=03 - incr: https://webrevs.openjdk.org/?repo=jdk=14064=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
Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2]
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
Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2]
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
Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v3]
> 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+erik...@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=14064=02 - incr: https://webrevs.openjdk.org/?repo=jdk=14064=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
Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2]
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
Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2]
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
Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries [v2]
> 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=14064=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
Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries
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
Re: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries
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
Re: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots [v4]
> 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=13803=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
Re: RFR: 8308093: Disable language preview features use in JDK
On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona wrote: > This patch disables temporary use of language preview features in JDK. > Temporary enabled language preview features (to allow Pattern Matching for > switch use in the Classfile API library) are no more necessary. > All redundant use of --enable-preview in the Classfile API tests are also > removed. > > Please review. > > Thanks, > Adam Marked as reviewed by darcy (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1437004246
Integrated: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal
On Sat, 6 May 2023 09:39:17 GMT, George Adams wrote: > Deprecate the Windows x86-32 port, with the intent to remove it in a future > release. This pull request has now been integrated. Changeset: 29b8d3d9 Author:George Adams Committer: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/29b8d3d9e73c3771f18b8d4d69e32475f17346fa Stats: 22 lines in 3 files changed: 22 ins; 0 del; 0 mod 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal Reviewed-by: erikj - PR: https://git.openjdk.org/jdk/pull/13852
Re: RFR: 8308093: Disable language preview features use in JDK
On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona wrote: > This patch disables temporary use of language preview features in JDK. > Temporary enabled language preview features (to allow Pattern Matching for > switch use in the Classfile API library) are no more necessary. > All redundant use of --enable-preview in the Classfile API tests are also > removed. > > Please review. > > Thanks, > Adam Marked as reviewed by alanb (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1436580302
Re: RFR: 8308093: Disable language preview features use in JDK
On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona wrote: > This patch disables temporary use of language preview features in JDK. > Temporary enabled language preview features (to allow Pattern Matching for > switch use in the Classfile API library) are no more necessary. > All redundant use of --enable-preview in the Classfile API tests are also > removed. > > Please review. > > Thanks, > Adam Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1436562362
Re: RFR: 8308093: Disable language preview features use in JDK
On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona wrote: > This patch disables temporary use of language preview features in JDK. > Temporary enabled language preview features (to allow Pattern Matching for > switch use in the Classfile API library) are no more necessary. > All redundant use of --enable-preview in the Classfile API tests are also > removed. > > Please review. > > Thanks, > Adam The enable-preview for jmh benchmark compilation exists before Classfile API integration, so this should be it. - Marked as reviewed by liach (Author). PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1436460682
Integrated: JDK-8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms
On Thu, 27 Apr 2023 11:21:04 GMT, Jan Lahoda wrote: > To support JShell and other usecases, the JDK uses JLine, which provides > line-editing functionality inside a terminal. > > JLine has several ways to work with the terminal, based on various additional > libraries and tools. Most of them are not directly usable inside the JDK, so > currently, on non-Windows platforms, the JLine inside the JDK will use > external programs, like `stty`, to inspect the terminal's properties and to > switch the terminal to raw mode. > > This is slightly problematic, as the external programs might be missing, and > while this is not that big problem for JShell, it might be a problem for > other potential uses of JLine, like using it inside `System.console()`. > > So, the proposal here is to call the corresponding native methods directly, > on selected platforms for now (Linux and Mac OS/X), instead of invoking the > external programs. On Windows, this has always been the case, we are using a > custom implementation of the interface that maps native and Java function for > JNA there, and the proposal is to do the same here. We take the appropriate > mapping interface for JNA, and provide hand-written implementation for it, > using JNI. > > The Windows implementation is mostly unchanged, the changes are mostly > non-Windows only. The overview of the changes is: > - `LastErrorException` is moved from the Windows-specific code to the > platform-neutral code, as it is used by all the native implementations. This > is the only change that directly affects the Windows-specific code > - `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaNativePty.java` > and > `unix/classes/jdk/internal/org/jline/terminal/impl/jna/JnaTerminalProvider.java` > are created based on the corresponding files from JLine. In JLine, these > files directly call platform-specific implementations, but in this patch, the > platform specific code is commented out, and replaced with calls to > `JDKNativePty`, which is a new platform-specific class, that delegates to the > actual platform-specific implementations. Note the `JnaNativePty.java` and > `JnaTerminalProvider.java` already exist in the Windows part, but have > different pieces of code commented out, which makes them substantially > different. > - for Linux and Mac OS/X, there are platform-specific implementations based > on the corresponding code from JLine, with the hand-written JNI-based > implementation of the JNA-based existing interfaces. They also have an > implementation of `JDKNativePty`, which just delegates to the given > platform's `"NativePty"` imple... This pull request has now been integrated. Changeset: a9705196 Author:Jan Lahoda URL: https://git.openjdk.org/jdk/commit/a9705196cea7d6f468b76b1cfff561352ee0b6b2 Stats: 2145 lines in 23 files changed: 2097 ins; 40 del; 8 mod 8306983: Do not invoke external programs when switch terminal to raw mode on selected platforms Co-authored-by: Adam Sotona Reviewed-by: erikj, vromero, bpb - PR: https://git.openjdk.org/jdk/pull/13687
RFR: 8308093: Disable language preview features use in JDK
This patch disables temporary use of language preview features in JDK. Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary. All redundant use of --enable-preview in the Classfile API tests are also removed. Please review. Thanks, Adam - Commit messages: - 8308093: Disable language preview features use in JDK Changes: https://git.openjdk.org/jdk/pull/14076/files Webrev: https://webrevs.openjdk.org/?repo=jdk=14076=00 Issue: https://bugs.openjdk.org/browse/JDK-8308093 Stats: 24 lines in 12 files changed: 0 ins; 22 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14076/head:pull/14076 PR: https://git.openjdk.org/jdk/pull/14076
Re: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v5]
> Deprecate the Windows x86-32 port, with the intent to remove it in a future > release. George Adams 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 remote-tracking branch 'upstream/master' into jep449 - fixup - update wording from review - typo fix - fix wording - 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal - Changes: - all: https://git.openjdk.org/jdk/pull/13852/files - new: https://git.openjdk.org/jdk/pull/13852/files/a79fa92e..29c960a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=13852=04 - incr: https://webrevs.openjdk.org/?repo=jdk=13852=03-04 Stats: 126189 lines in 2220 files changed: 95119 ins; 15372 del; 15698 mod Patch: https://git.openjdk.org/jdk/pull/13852.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13852/head:pull/13852 PR: https://git.openjdk.org/jdk/pull/13852
Re: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v3]
On Fri, 19 May 2023 14:49:54 GMT, George Adams wrote: >> George Adams has updated the pull request incrementally with one additional >> commit since the last revision: >> >> typo fix > > This JEP has now been moved from "Proposed to target" to "Targeted" which > means I think we can merge this now. > @gdams please see my comment above re the wording. Thanks @dholmes-ora updated PTAL - PR Comment: https://git.openjdk.org/jdk/pull/13852#issuecomment-1556763799
Re: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v4]
> Deprecate the Windows x86-32 port, with the intent to remove it in a future > release. George Adams has updated the pull request incrementally with two additional commits since the last revision: - fixup - update wording from review - Changes: - all: https://git.openjdk.org/jdk/pull/13852/files - new: https://git.openjdk.org/jdk/pull/13852/files/8c090a71..a79fa92e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=13852=03 - incr: https://webrevs.openjdk.org/?repo=jdk=13852=02-03 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13852.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13852/head:pull/13852 PR: https://git.openjdk.org/jdk/pull/13852
Re: RFR: 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal [v3]
On Fri, 19 May 2023 14:49:54 GMT, George Adams wrote: >> George Adams has updated the pull request incrementally with one additional >> commit since the last revision: >> >> typo fix > > This JEP has now been moved from "Proposed to target" to "Targeted" which > means I think we can merge this now. @gdams please see my comment above re the wording. Thanks - PR Comment: https://git.openjdk.org/jdk/pull/13852#issuecomment-1556710566
Re: RFR: 8307652: sealed class hierarchy graph doesn't distinguish non-sealed classes [v2]
On Tue, 16 May 2023 17:16:57 GMT, Chen Liang wrote: >> `@sealedGraph` had a mechanism to render non-sealed classes differently, but >> it's useless because the graph nodes are not bordered. This patch converts >> the non-sealed classes to be rendered in italics instead. >> >> An example of `ConstantDesc`, which has a sealed hierarchy except >> `DynamicConstantDesc`: >> JDK 20: >>  >> >> This patch: >>  > > Chen Liang 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: > > - Use an edge and node to indicate non-sealed hierarchy > - Merge branch 'master' into fix/sealedgraph-nonsealed > - 8307652: sealed class hierarchy graph doesn't distinguish non-sealed > classes Marked as reviewed by pminborg (Committer). - PR Review: https://git.openjdk.org/jdk/pull/13877#pullrequestreview-1435944754
Re: RFR: JDK-8306304: Fix xlc17 clang warnings in ppc and aix code [v2]
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
