How to handle update of Java on Client from 32bit to 64bit together with custom Java VM

[Robert]

We are using getDown together with a pre-installed Version of Java on the client computer and have configured getDown to use a custom VM and libraries depending on the Java architecture

See extract of our getDown.txt below:

...

code = [windows-amd64]ext/swt/win64/swt.jar
code = [windows-x86]ext/swt/win32/swt.jar

java_min_version = 1110000
java_location = [windows-amd64] java/java_windows64.jar
java_location = [windows-x86] java/java_windows32.jar
...

We now run into problems, when the Java-Version on the client changes.

Let's say, on client a 32bit-Java version (Version < 11) is installed

-> getDown then installs the 32bit-Version of the Java-VM and downloads the 32bit-implementation of swt.jar

When now on the Client a 64bit-Version of Java is installed, getDown will retrieve the 64bit-Version of swt.jar, but doesn't install a different custom Java VM (because the formerly installed custom java version does meet the java_min_version requirement)

Now the problem occurs that getDown launches the application with the 32bit-Version of Java (located in ./java_vm), but on the classpath is the 64bit-Version of swt.jar

How to handle this?

Wouldn't it be possible that getDown checks the architecture from the virtual machine which is used to launch the application to download also the correct architecture versions of the code? So in example above, getdown see that in java_vm a 32-bit Version of Java is installed so it downloads the 32bit Version of swt.jar (and put this one on the classpath).

Or would it be possible, that getDown checks if the architecture it was launched differs from the architecture of the downloaded Java VM, and if so, download the same architecture as the JVM with which getDown was started?

[Michael Bayne]

Either of those sound like reasonable solutions. Using the architecture information from the custom JVM seems like a good place to start, since that would be necessary regardless if a custom JVM was not available that matched the architecture of the JVM running Getdown.

Unfortunately I don't have the time to implement and test them, but I'd be happy to review a pull request that made the necessary changes.

--
You received this message because you are subscribed to the Google Groups "OOO Libs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ooo-libs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ooo-libs/5df1e961-0582-43fd-ba91-3a039c1347b1%40googlegroups.com.

--

-- m...@samskivert.com