Failure unpacking custom JRE

[haraldk]

I have downloaded the Java 10.0.1 JRE for Windows from Oracle (I downloaded the .gz but I doubt it matters). Unpacked it and created a JAR from it, as described.

I'm using the following values in getdown.txt:

java_min_version = 1100001
java_exact_version_required = true
java_location = [windows] java_windows.jar

I placed the java_windows.jar in the same folder as the rest of my application.

It seems to download fine, but there's a problem unpacking:

Here's the extract from the launch.log:

2018/07/05 16:50:20:235 INFO n$a.a: Checking Java version [current=1080171, wantMin=1100001, wantMax=0]
2018/07/05 16:50:20:237 INFO n$a.a: Checking version of unpacked JVM [vers=10000100].
2018/07/05 16:50:20:237 WARNING n$a.a: An exact Java VM version is required. [current=10000100, required=1100001]
2018/07/05 16:50:20:237 INFO n$a.a: Attempting to update Java VM...
2018/07/05 16:50:20:238 INFO n$a.a: Downloading 79376243 bytes...
2018/07/05 16:50:20:240 INFO n$a.a: Downloading resource [url=[redacted]/java_windows.jar, size=79376243]
2018/07/05 16:50:20:397 INFO n$a.a: - .\java_vm.jar_new
2018/07/05 16:50:20:576 WARNING n$a.a: getdown() failed.
java.io.IOException: Failure unpacking [jar=java.util.jar.JarFile@5585caed, entry=.\java_vm\bin\java.dll]
	at com.threerings.getdown.util.FileUtil.unpackJar(Unknown Source)
	at com.threerings.getdown.data.Resource.unpack(Unknown Source)
	at com.threerings.getdown.data.Resource.unpackIfNeeded(Unknown Source)
	at com.threerings.getdown.data.Resource.install(Unknown Source)
	at com.threerings.getdown.launcher.Getdown.updateJava(Unknown Source)
	at com.threerings.getdown.launcher.Getdown.getdown(Unknown Source)
	at com.threerings.getdown.launcher.Getdown.run(Unknown Source)
Caused by: java.io.FileNotFoundException: .\java_vm\bin\java.dll (Prosessen får ikke tilgang til filen fordi den brukes av en annen prosess)
	at java.io.FileOutputStream.open0(Native Method)
	at java.io.FileOutputStream.open(Unknown Source)
	at java.io.FileOutputStream.<init>(Unknown Source)
	at java.io.FileOutputStream.<init>(Unknown Source)
	... 7 more
2018/07/05 16:50:20:576 INFO n$a.a: Releasing lock

(Error message in English is something like "The process cannot access the file, as it is in use by another process")

I'm suspecting this might be related to anti-virus software or something similar. That is unfortunately a show stopper. Is there a fix, hack or workaround I can employ?

As I'm probably creating an installer or similar to install the application, I'm thinking this is overkill anyway. Is there a way to create a bundled application that installs the JRE with the application and have GetDown use it, but don't try to download new versions and mess with DLL's etc on the client computer? Ie.: How do I specify the JRE GetDown should use?

Best regards,

-- Harald K

[samskivert]

Indeed Windows makes it harder and harder to install software these days. I'm sure that's good for security reasons, but it makes life harder for apps like Getdown.

There's currently no explicit way to tell Getdown to use a custom JRE without using the existing mechanism where you provide a JRE resource. That said, if you install the JRE resource and unpack it yourself first, then Getdown will not attempt to unpack it. The downside is that you have to have a .jar file with the entire JRE in addition to the unpacked JRE, but you don't get the benefit of automatically updating that JRE.

You could be sneaky and define a custom JVM resource that is actually just a tiny .jar file with some stub file in it, and install that and your own manually installed JRE, then you don't have the data duplication.

Or you can use another mechanism Getdown supports called "direct launching" where you install your desired JRE, and you insure that the launching mechanism runs Getdown using that JRE, and then you pass -Ddirect and Getdown will just reuse the same JVM it's running in to run the application.

All that said, if anyone wants to submit a pull request with the necessary changes to make JRE auto-updating work again on newer Windows versions, I'm sure all the Getdown users would greatly appreciate it. I have not shipped a commercial application that uses Getdown in more than a decade, so I'm not in a position to do any real testing of JRE auto-update.

[samskivert]

You know, looking at the code more closely, I think Getdown will just use any Java VM it sees in <appdir>/java_vm regardless of whether there is an auto-updating JVM resource also specified in the getdown.txt file.

So if your installer just installs your desired JRE into <appdir>/java_vm then Getdown should just automatically use it.

I was looking at the code that checks whether Getdown has a valid Java version per the min/max Java version information specified in the getdown.txt file. That won't just look into java_vm unless there's a custom JVM resource, but the app launching code doesn't care. It just looks for that directory and uses it if it's there, assuming that the earlier phases ensured that the JRE in there was correct.

[Adrodoc]

@haraldk Your min version seems to be incorrect, you are using a 10.0.1 jre, which is 10000100 in the getdown version format, but in your getdown.txt you say that version 1100001 is required. If you change java_min_version = 1100001 to java_min_version = 10000100 it should work fine.

[Maia-Everett]

I hit this bug as well in 1.8.3.