8319457: Update jpackage to support WiX v4 and v5 on Windows #19318

alexeysemenyukoracle · 2024-05-20T21:14:09Z

Add support for WiX4 and WiX5 in jpackage.

jpackage supports WiX3, WiX4 and WiX5. It will pick WiX4/WiX5 if one of them is installed and there is WiX3 installed too. (Note: WiX4 and WiX5 are not supposed to be installed side-by-side, but if it happens, WiX5 will be preferred over WiX4).

Custom WiX3 sources will be automatically converted to WiX4 format if WiX4/WiX5 is used. The converter provides:

full support of the conversion of WiX L10N (.wxl) files, i.e. full support of "http://schemas.microsoft.com/wix/2006/localization" to "http://wixtoolset.org/schemas/v4/wxl" namespace conversion;
partial support of WiX source (.wxs) files, i.e. partial support of "http://schemas.microsoft.com/wix/2006/wi" to "http://wixtoolset.org/schemas/v4/wxs" namespace conversion;

The converter is a XSLT stylesheet. The default converter is src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl. It can be replaced with the custom converter by adding "wix-conv.xsl" file to the resource directory.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8319457: Update jpackage to support WiX v4 and v5 on Windows (Enhancement - P3)

Reviewers

Alexander Matveev (@sashamatveev - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/19318/head:pull/19318
$ git checkout pull/19318

Update a local copy of the PR:
$ git checkout pull/19318
$ git pull https://git.openjdk.org/jdk.git pull/19318/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 19318

View PR using the GUI difftool:
$ git pr show -t 19318

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/19318.diff

Webrev

Link to Webrev Comment

…errides.wxi, and l10n .wxl files

… package option

… of two BiInteger objects and it didn't work right. When the bug was fixed app version check on Windows platform stopped working. It required a bit of work to get it working right.

…exe.

…ED" to test desc. It fixes the following error: [22:09:20.347] TRACE: assertFalse(): Check [C:\Program Files\UpdateServiceTest\foo.ico] path doesn't exist [22:09:20.375] [ FAILED ] ServiceTest.testUpdate; checks=60 java.lang.ExceptionInInitializerError at jdk.jpackage.test.LauncherIconVerifier.applyTo(LauncherIconVerifier.java:70) at jdk.jpackage.test.AdditionalLauncher.verifyIcon(AdditionalLauncher.java:298) at jdk.jpackage.test.AdditionalLauncher.verify(AdditionalLauncher.java:363) at jdk.jpackage.test.LauncherAsServiceVerifier$1.verify(LauncherAsServiceVerifier.java:261) at jdk.jpackage.test.Functional$ThrowingConsumer.lambda$toConsumer$0(Functional.java:41) at jdk.jpackage.test.PackageTest$Handler.lambda$verifyPackageInstalled$6(PackageTest.java:660) at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) at jdk.jpackage.test.PackageTest$Handler.verifyPackageInstalled(PackageTest.java:660) at jdk.jpackage.test.PackageTest$Handler.accept(PackageTest.java:594) at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:504) at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:411) at jdk.jpackage.test.Functional$ThrowingConsumer.lambda$toConsumer$0(Functional.java:41) at java.base/java.lang.Iterable.forEach(Iterable.java:75) at jdk.jpackage.test.PackageTest$Group.lambda$runAction$0(PackageTest.java:364) at java.base/java.lang.Iterable.forEach(Iterable.java:75) at jdk.jpackage.test.PackageTest$Group.runAction(PackageTest.java:364) at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) at jdk.jpackage.test.RunnablePackageTest.runActions(RunnablePackageTest.java:66) at jdk.jpackage.test.RunnablePackageTest.run(RunnablePackageTest.java:58) at ServiceTest.testUpdate(ServiceTest.java:132) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) at jdk.jpackage.test.TKit.lambda$ignoreExceptions$5(TKit.java:141) at jdk.jpackage.test.TKit.lambda$runTests$3(TKit.java:126) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1709) at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:807) at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:123) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:105) at jdk.jpackage.test.TKit.runTests(TKit.java:122) at jdk.jpackage.test.Main.runTests(Main.java:79) at jdk.jpackage.test.Main.lambda$main$2(Main.java:75) at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105) at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:109) at jdk.jpackage.test.Main.main(Main.java:75) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1575) Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make private static native long jdk.jpackage.internal.ExecutableRebrander.lockResource(java.lang.String) accessible: module jdk.jpackage does not "opens jdk.jpackage.internal" to unnamed module @3761e16e at java.base/java.lang.reflect.AccessibleObject.throwInaccessibleObjectException(AccessibleObject.java:388) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:364) :

bridgekeeper · 2024-05-20T21:14:55Z

👋 Welcome back asemenyuk! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2024-05-20T21:15:15Z

@alexeysemenyukoracle This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8319457: Update jpackage to support WiX v4 and v5 on Windows

Reviewed-by: almatvee

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 129 new commits pushed to the master branch:

a7205cc: 8333926: Shenandoah: Lower default immediate garbage threshold
56e8e60: 8330534: Update nsk/jdwp tests to use driver instead of othervm
bbd3b1d: 8334036: Update JCov for class file version 68
7ed8a5c: 8333841: Add more logging into setfldw001 tests
b77bd5f: 8333742: ProcessImpl and ProcessHandleImpl may mishandle processes that exit with code 259
aaaa86b: 8333360: PrintNullString.java doesn't use float arguments
ef101f1: 8332920: C2: Partial Peeling is wrongly applied for CmpU with negative limit
2843745: 8333972: Parallel: Remove unused methods in PSOldGen
93f3918: 8333954: Parallel: Remove unused arguments of type ParCompactionManager*
788b876: 8333917: G1: Refactor G1CollectedHeap::register_old_region_with_region_attr
... and 119 more: https://git.openjdk.org/jdk/compare/9686e804a2b058955ff88149c54a0a7896c0a2eb...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2024-05-20T21:15:35Z

@alexeysemenyukoracle The following labels will be automatically applied to this pull request:

build
core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

…rectory 'DesktopFolder' is deprecated. Use the StandardDirectory element instead." WiX4 warning

…he PATH. When wix.exe is not in the PATH, jpackage uses %USERPROFILE% env variable to get user home directory. But jtreg removes it from the environment when running tests, so without wix.exe in the PATH all jpackage tests will fail on Windows. This makes it impossible to test jpackage with wix3. This patch addresses this issue by reading user home additionally from "java.home" system property.

…ols available and what bundlers are supported.

This reverts commit 00d7cc6.

… and Saxon HE (v12.4)

magicus · 2024-06-04T09:06:55Z

/label -build

openjdk · 2024-06-04T09:07:20Z

@magicus
The build label was successfully removed.

alexeysemenyukoracle · 2024-06-04T12:37:03Z

I assume WiX5 will just work if installed instead of WiX4?

Correct.

Do you think it will make sense to introduce Wix5 ToolsetType in case if we need to do something different between 4 and 5?

They claim WiX5 is backward compatible with WiX4, i.e. WiX4 code should work with WiX5 toolkit. So I don't see a reason to introduce Wix5 ToolsetType now.

…. All WiX source files from the resource directory should be copied to jpackage work directory before running wxi tools. jpackage should not change files in the resource directory.

…ile() does: create parent directory and replace output file if it exists.

alexeysemenyukoracle · 2024-06-04T16:11:35Z

Fixed WinL10nTest test failure. It didn't fail on my dev machine but failed in another environment. I thought it was sporadic but it turned out to be a bug in this PR.

sashamatveev · 2024-06-05T03:54:46Z

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java

@@ -152,6 +153,16 @@ void addFilesToConfigRoot() throws IOException {
        super.addFilesToConfigRoot();
    }

+    @Override
+    List<String> getLoggableWixFeatures() {


Maybe I am missing something, but is it used? I only see call to base class WixFragmentBuilder::getLoggableWixFeatures.

WixFragmentBuilder::getLoggableWixFeatures is equivalent to:

new Function<WixFragmentBuilder, List<String>>() { public List<String> apply(WixFragmentBuilder obj) { return obj.getLoggableWixFeatures(); } }

An overridden WixAppImageFragmentBuilder#getLoggableWixFeatures() method will be called when WixAppImageFragmentBuilder instance is given.

sashamatveev · 2024-06-05T04:20:17Z

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties

@@ -41,8 +41,9 @@ resource.overrides-wix-file=Overrides WiX project file
 resource.shortcutpromptdlg-wix-file=Shortcut prompt dialog WiX project file
 resource.installdirnotemptydlg-wix-file=Not empty install directory dialog WiX project file
 resource.launcher-as-service-wix-file=Service installer WiX project file
+resource.wix-src-conv=XSLT stylesheet converting WiX sources from WiX v3 to WiX v4 format


WiX v4 -> WiX v4/v5

The converter does exactly as described, it converts WiX v3 sources into WiX v4 format that can be used with WiX v4 and WiX v5. So I believe the description should remain unchanged.

Makes sense, but for error.no-wix-tools I think we should add v5, in case if users sees this message when only v5 is installed.

sashamatveev · 2024-06-05T04:23:12Z

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties


-error.no-wix-tools=Can not find WiX tools (light.exe, candle.exe)
+error.no-wix-tools=Can not find WiX tools. Was looking for WiX v3 light.exe and candle.exe or WiX v4 wix.exe and none was found


WiX v4 -> WiX v4/v5

alexeysemenyukoracle · 2024-06-05T15:39:14Z

Do we need to handle default case for unknown wix type? In same cases you have default -> throw new IllegalArgumentException(); and in some you do not have.

Good catch. I'll update the code to make switch(wixVersion) ... expressions consistent as follows:

switch (wixVersion) {
  case Wix3 -> {}
  case WiX4 -> {}
  default -> throw new IllegalArgumentException();
}

sashamatveev · 2024-06-05T19:31:57Z

I assume WiX5 will just work if installed instead of WiX4?

Correct.

Do you think it will make sense to introduce Wix5 ToolsetType in case if we need to do something different between 4 and 5?

They claim WiX5 is backward compatible with WiX4, i.e. WiX4 code should work with WiX5 toolkit. So I don't see a reason to introduce Wix5 ToolsetType now.

jpackage allows override of main WiX source file (main.wxs), do you know what will happen if user will add main.wxs with format features available only in WiX 5 and will have WiX 5 toolkit installed?

Do you know if there any benefits to use any features available in WiX5 if WiX5 toolkit is installed, instead of using only WiX4 features with WiX5 toolkit?

alexeysemenyukoracle · 2024-06-06T12:41:17Z

jpackage allows override of main WiX source file (main.wxs), do you know what will happen if user will add main.wxs with format features available only in WiX 5 and will have WiX 5 toolkit installed?

jpackage will detect the custom main.wxs is WiX4 format and pass it as is to wix.exe. I.e. custom WiX5 main.wxs will work with WiX5 toolkit.
However, it will fail if they try using custom main.wxs with WiX5-specific features with WiX4 toolkit. But this is out of the scope of jpackage.

Do you know if there any benefits to use any features available in WiX5 if WiX5 toolkit is installed, instead of using only WiX4 features with WiX5 toolkit?

As far as I can tell from https://wixtoolset.org/docs/fivefour/, WiX5 reduces the redundancy of source files compared to WiX4. I can see how people handwriting sophisticated WiX source files can benefit from these improvements, not jpackage. The default main.wxs and two dialogs jpackage supplies are very basic and other sources are generated.

…entException if "wixVersion" is not WixToolkit#Wix3 or WixToolkit#Wix4. When/If we add another value to WixToolkit enum this will help not to miss adjusting all WiX version-specific code.

sashamatveev

Looks good. No more questions or comments.

alexeysemenyukoracle · 2024-06-12T13:35:52Z

/integrate

openjdk · 2024-06-12T13:37:06Z

Going to push as commit ba67ad6.
Since your change was applied there have been 140 commits pushed to the master branch:

2c9185e: 8321308: AArch64: Fix matching predication for cbz/cbnz
5a8a9fd: 8333382: [s390x] Enhance popcnt Instruction to use Z15 facilities
81083a0: 8299487: Test java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out
81ca0ec: 8334028: HttpClient: NPE thrown from assert statement
bd750b6: 8319933: Disable tests for JDK-8280481 on Graal
c80e2eb: 8333886: Explicitly specify that asSlice and reinterpret return a memory segment backed by the same region of memory.
a0318bc: 8334077: Fix problem list entries for compiler tests
a7e4ab9: 8333730: ubsan: FieldIndices/libFieldIndicesTest.cpp:276:11: runtime error: null pointer passed as argument 2, which is declared to never be null
abbf45b: 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]'
bd046d9: 8222884: ConcurrentClassDescLookup.java times out intermittently
... and 130 more: https://git.openjdk.org/jdk/compare/9686e804a2b058955ff88149c54a0a7896c0a2eb...master

Your commit was automatically rebased without conflicts.

openjdk · 2024-06-12T13:37:12Z

@alexeysemenyukoracle Pushed as commit ba67ad6.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

koppor · 2025-04-26T13:17:16Z

jpackage allows override of main WiX source file (main.wxs), do you know what will happen if user will add main.wxs with format features available only in WiX 5 and will have WiX 5 toolkit installed?

@alexeysemenyukoracle Related question: Generation of main.wxs was moved from prepareMainProjectFile to buildMSI. This breaks our patches to main.wxs (which used to work for 6+ years now)

Quoting https://docs.oracle.com/en/java/javase/24/jpackage/override-jpackage-resources.html#GUID-62412365-821D-4736-A20D-70F2D47136D8, the post-image script is executed before buildMSI (which is right).

Custom script that is executed after the application image is created and before the MSI installer is built for both .msi and .exe packages. No default script is provided.

I would expect that all files are available before the "Post-image script" are available - and not generated after any Post-image script is run.

alexeysemenyukoracle · 2025-04-26T19:50:06Z

I would expect that all files are available before the "Post-image script" are available

Definitely. Thank you for reporting the issue. Filed https://bugs.openjdk.org/browse/JDK-8355651 to track fixing the issue

alexeysemenyukoracle · 2025-04-29T15:41:47Z

@koppor , "JabRef post-image" script has a couple of issues:

A path to the "config" directory is derived from the current process directory. This logic is fragile and redundant. jpackage runs a copy of the "post-image" script from the "config" directory, so the path to the "config" directory is the parent folder of the script:

var installerConfig = fileSystem.GetFile(WScript.ScriptFullName).ParentFolder;

The script relies on the assumption that jpackage will create the "config" directory and the "image" directory within JabRef project directory tree. This is needed to obtain a path to the root directory of the project at JabRef-post-image.wsf:12. To ensure this, '--temp', "$buildDir/installer" is passed as an argument to jpackage in build.gradle:936. This will fall off if Gradle build directory is created outside of the project tree, which is not an uncommon configuration.

Unfortunately, issue n2 doesn't have a trivial solution like issue n1 because jpackage doesn't provide sufficient context to the post-image script. As a workaround, I'd embed a path to JabRef project root in the post-image script source. This will make it agnostic to the location of the project build directory and eliminate the need for '--temp', "$buildDir/installer" in the build.gradle. To embed a path to JabRef project root in the JabRef-post-image.wsf file, I'd add a Gradle task transforming it during the build.

I noticed there is no JabRef-post-image.wsf in the "main" branch anymore. Instead, you added a custom version of the "main.wxs" file. The script is still in the (v6.0-alpha2)[https://github.com/JabRef/jabref/blob/v6.0-alpha2/buildres/windows/JabRef-post-image.wsf] release though, I guess the fix is still relevant. I created a patch using v6.0-alpha2 tag as the baseline - JabRef/jabref#13033. Please suggest further actions.

alexeysemenyukoracle added 15 commits May 16, 2024 02:24

Can detect Wix v4 and v5.

1bd04b4

SimplePackageTest is a pass with manual "wix convert" on main.wxs, ov…

fb0e2ee

…errides.wxi, and l10n .wxl files

SimplePackageTest is a pass without manual tweaks

f78ebef

WiX4 doesn't accept localization IDs with dots (.). Rename them

1bdfd64

Use the same xslt for all types of wix3 sources to be converted

e5ab4d9

Fix Wix4 shortcut xml element output

9184222

Reuse WixSourceConverter#ResourceGroup

e473865

Fix issue caused by failed test exercising --windows-per-user-install…

2186169

… package option

Major tests pass with WiX4

e67d1c3

Log WiX4 post-processing of unpacked msi

d90e042

DottedVersion refactored. Old parsing code used "==" to test equality…

e8f43ee

… of two BiInteger objects and it didn't work right. When the bug was fixed app version check on Windows platform stopped working. It required a bit of work to get it working right.

Detect WiX3 full set of tools (candle.exe and light.exe) or WiX4 wix.…

aa0200c

…exe.

Fix InstallDirTest.testCommon test failure

1b35d20

WinL10nTest is a pass

6b510e1

alexeysemenyukoracle marked this pull request as draft May 20, 2024 21:14

openjdk bot added build build-dev@openjdk.org core-libs core-libs-dev@openjdk.org labels May 20, 2024

alexeysemenyukoracle added 9 commits May 21, 2024 10:02

Fix "warning WIX5436: Using DirectoryRef to reference the standard di…

8cb8fbb

…rectory 'DesktopFolder' is deprecated. Use the StandardDirectory element instead." WiX4 warning

Got rid of Wix36 WiX toolset type

51b4c0c

Merge branch 'master' into JDK-8319457

4f2f8e4

Don't suppress jpackage output when it is detecting what packaging to…

74407c8

…ols available and what bundlers are supported.

Merge branch 'master' into JDK-8319457

4e19e8b

Rollback unneeded change

00d7cc6

Revert "Rollback unneeded change"

5fded0b

This reverts commit 00d7cc6.

Ensure WiX source converter works with the default JDK XSLT processor…

3302aa0

… and Saxon HE (v12.4)

openjdk bot removed the build build-dev@openjdk.org label Jun 4, 2024

alexeysemenyukoracle added 4 commits June 4, 2024 09:48

EOLs restored

99aac32

EOLs restored

782d121

Fix issue with overwriting custom l10n file in the resource directory…

cbf7d31

…. All WiX source files from the resource directory should be copied to jpackage work directory before running wxi tools. jpackage should not change files in the resource directory.

WixSourceConverter#applyTo should do what OverridableResource#saveToF…

af8fb68

…ile() does: create parent directory and replace output file if it exists.

sashamatveev reviewed Jun 5, 2024

View reviewed changes

alexeysemenyukoracle changed the title ~~8319457: Update jpackage to support WiX Toolset 4 on Windows~~ 8319457: Update jpackage to support WiX v4 and v5 on Windows Jun 5, 2024

alexeysemenyukoracle added 2 commits June 6, 2024 08:48

Unify "switch(wixVersion) ..." expressions. Always throw IllegalArgum…

899470e

…entException if "wixVersion" is not WixToolkit#Wix3 or WixToolkit#Wix4. When/If we add another value to WixToolkit enum this will help not to miss adjusting all WiX version-specific code.

Add WiX v5 to "error.no-wix-tools"

d446973

sashamatveev approved these changes Jun 12, 2024

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jun 12, 2024

openjdk bot added the integrated Pull request has been integrated label Jun 12, 2024

openjdk bot closed this Jun 12, 2024

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jun 12, 2024

This was referenced Apr 30, 2025

Fix JabRef-post-image.wsf to make it agnostic to the location of the … JabRef/jabref#13033

Open

Support Toolchain for Java 25 gradle/gradle#33310

Open


		error.no-wix-tools=Can not find WiX tools (light.exe, candle.exe)
		error.no-wix-tools=Can not find WiX tools. Was looking for WiX v3 light.exe and candle.exe or WiX v4 wix.exe and none was found

8319457: Update jpackage to support WiX v4 and v5 on Windows #19318

8319457: Update jpackage to support WiX v4 and v5 on Windows #19318

Uh oh!

Conversation

alexeysemenyukoracle commented May 20, 2024 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Webrev

Uh oh!

bridgekeeper bot commented May 20, 2024

Uh oh!

openjdk bot commented May 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented May 20, 2024

Uh oh!

magicus commented Jun 4, 2024

Uh oh!

openjdk bot commented Jun 4, 2024

Uh oh!

alexeysemenyukoracle commented Jun 4, 2024

Uh oh!

alexeysemenyukoracle commented Jun 4, 2024

Uh oh!

sashamatveev Jun 5, 2024

Choose a reason for hiding this comment

Uh oh!

alexeysemenyukoracle Jun 5, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sashamatveev Jun 5, 2024

Choose a reason for hiding this comment

Uh oh!

alexeysemenyukoracle Jun 5, 2024

Choose a reason for hiding this comment

Uh oh!

sashamatveev Jun 5, 2024

Choose a reason for hiding this comment

Uh oh!

sashamatveev Jun 5, 2024

Choose a reason for hiding this comment

Uh oh!

alexeysemenyukoracle commented Jun 5, 2024

Uh oh!

sashamatveev commented Jun 5, 2024

Uh oh!

alexeysemenyukoracle commented Jun 6, 2024

Uh oh!

sashamatveev left a comment

Choose a reason for hiding this comment

Uh oh!

alexeysemenyukoracle commented Jun 12, 2024

Uh oh!

openjdk bot commented Jun 12, 2024

Uh oh!

openjdk bot commented Jun 12, 2024

Uh oh!

koppor commented Apr 26, 2025

Uh oh!

alexeysemenyukoracle commented Apr 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexeysemenyukoracle commented Apr 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

alexeysemenyukoracle commented May 20, 2024 •

edited by openjdk bot

Loading

openjdk bot commented May 20, 2024 •

edited

Loading

alexeysemenyukoracle Jun 5, 2024 •

edited

Loading

alexeysemenyukoracle commented Apr 26, 2025 •

edited

Loading

alexeysemenyukoracle commented Apr 29, 2025 •

edited

Loading