emscripten doesn't find/use locally installed Java

[jb-wisemo]

This is similar to emscripten-core/emsdk#1142 but for Java.

I have a system installed Java 8 newer than what emcripten bundles.

Unfortunately there are no working instructions for doing so.

I tried using the command "emsdk uninstall java-8.152-64bit", then edited .emscripten to point to the locally installed java jre 1.8.0.192

But now CI builds fail with the error message "error: error: tool is not installed and therefore cannot be activated: 'java-8.152-64bit'"
which indicates that something deep inside emscripten is checking for the specific bundled java install status.

Installing the bundled java again causes emscripten to use it instead of the version/path specified in .emscripten

Please provide instructions for doing this right, and don't make such hidden boobytraps for sysadmins trying to run a minimal install.

OS version: Windows 10.0.22000.778
emscripten version: 3.1.14 (4343cbe)

Command invoked by CI build script: %EMSDK_PATH%\emsdk.bat activate 3.1.14
Output from command:
Resolving SDK version '3.1.14' to 'sdk-releases-upstream-ade9d780ff17c88d81aa13860361743e3c1e1396-64bit'
error: error: tool is not installed and therefore cannot be activated: 'java-8.152-64bit'

Supplemental issue:
"emsdk install java_8.152-64bit" sets all unpacked files to the timestamp of running the unpack, not the upstream timestamps or the timestamps in the downloaded zip file.

[sbc100]

What is you reason for wanting to use a version of java other than the bundled version. The idea behind emsdk is to bundle all of the emscripten dependencies and pin them to specific versions, to avoid compatibly issues with any host tools that might be install (and have different/incompatible versions).

Another way of putting it: Is there some specific reason you want to have emscripten use a version of java other than the version that is install by emsdk?

On another note, are you use emscripten is even using java? I though that the these days we ran closure compiler via native binaries rather than the java version? How are you verifying that emscripten is even using java at all?

Regarding the timestamps on the unpacked files, is there some reason you care about those timestamps? It could be that we could improve the "unzip" code in emsdk to preserve them.

[jb-wisemo]

Using the separately installed Java keeps disk space use down on a CI build machine filled to the brim with cross build tools for many targets. It also allows running the last (and hopefully least insecure) legally licenced Java 8 before Oracle raised the price.

The issue is that emscripten refuses to even start without its own bundled Java. If it won't even be used it only makes the requirement to install the bundled versions of all 3rd party tools even worse.

The dates on unzipped tool files helps identify their version and age by comparing against regularly installed tools, obscuring the dates either during zipping or unzipping is a loss of identifying information and clearly a bug, given the wide availability of non-buggy unzip code.

[sbc100]

I see. I think windows is the only platform where we bundle our own version of java with emsdk. BTW, emscripten itself runs just fine without java, its only emsdk (which is the bundling of emscripten with all of its dependencies) that adds the dependency. In fact I think this bug probably makes more sense in the emsdk repo, so we should move it there, unless you think otherwise?

We could see if we could just remove java dependency from the windows version of emsdk. Sadly we don't any any such thing as an optional dependency at this point so the windows emsdk simply depends on java today. I will create a patch the remove the dependency and see if we can land that. Then folks can still optionally install the bundles java but they wouldn't be forced to.

Patches would certainly be welcome to fix the unzip code to be more date aware: https://github.com/emscripten-core/emsdk/blob/32fba7b7c439ad806dcd1903231611241966ce30/emsdk.py#L563-L627