Temurin-build: Missing DLLs means users are forced to download the Microsoft Visual C++ Redistributable

@johanvos - Is this something you'd expect our distro to have or is that part of the JavaFX package on top?

It is part of the OpenJDK distribution, so for consistency reasons, I think it should be part of the AdoptOpenJDK distribution as well?

Great thank you! @ali-ince / @johnoliver one for us to look into

Including dlls into the package would increase the size of the OpenJDK distributatble which should be a consideration. Microsoft don't recommend static linking or include the DLL in your own directory as the OS/security update might not apply to those runtime

Looking at: https://social.msdn.microsoft.com/Forums/en-US/a28331ae-19a3-4a34-b3ba-1e8fd4430375/missing-apimswincore-dlls

It looks like those are OS level libraries but somehow they have changed the name. The suggestion from the MS community is that we should use mincore.lib which is a shim for all the api surface, but the binary would only work with Windows 8+.

Alternatively we can probabaly distribute the full Visual C++ redistributable installer in our installer package.

What would be a good option?

@sunnythepooh

Alternatively we can probabaly distribute the full Visual C++ redistributable installer in our installer package.

Yuck!!!

AdoptOpenJDK should be a drop-in replacement for the jdk.java.net release.

If you make end users jump through hoops, it'd be very damaging to the value proposition of zero-dependency jlink'd apps.

IMHO, Although I can see the reason why you would consider including the VC++ redist in AdoptOpenJDK, you should only include it if a .dll requires it and because the only thing that requires it is JavaFX's own .dll, then reason to include seem strange.

It makes more sense for the JavaFX package to include it.

Or included it in a AdoptOpenJavaFX extra pacakge :-)

It makes more sense for the JavaFX package to include it.

I can see that you may be absolutely right that the .dlls in an ideal world should be in a JavaFX package.

In the mean time though, until you can start providing your own AdoptOpenJavaFX package or convince Gluon to include the .dlls in their package, AdoptOpenJDK is unusable for JavaFX apps.

I'm sure there are all sorts of better long-term approaches, but in the mean time this is an unacceptable state of limbo for AdoptOpenJDK.

I think the main problem here may be that AdoptOpenJDK builds the JDK with a different version of visual studio (I'll check but it's probably VS2013) than what JavaFX is built with (given the DLL names missing, it's probably VS2017).

I'll try to verify the version of VS first and update here.

I've noticed that AdoptOpenJDK 12 (hotspot) now has the necessary DLLs, so everything works perfectly for JavaFX apps.

Thank you!!!

I've noticed that AdoptOpenJDK 12 (hotspot) now has the necessary DLLs, so everything works perfectly for JavaFX apps.

Thank you!!!

Good to hear - For Java 11 and 8 I suspect this issue will be resolved in the nightlies now. @ali-ince Are we building with VS 2017 for all versions now?

Not yet @karianna, that's still in progress. I'll update this thread when we switch to vs2017.

A quick update on this;

1. JDK11u 64-bit builds are now switched to VS2017.
2. JDK11u 32-bit builds are on VS2013. A fix that will enable JDK11u 32-bit to compile with VS2017 will be launched with 11.0.4 update and we'll be switching to VS2017 parallel to that.
3. JDK8u 32-bit and 64-bit builds are now switched to VS2013 (previously they were on VS2010/VS2013 mixed). We're working to get those to build on VS2017 as well, but that seems to take some more time to get a fix for submission to upstream.

Hi!
We have problems at our customer environment with the missing C runtime libraries.
How is the status on this issue?

The workaround would be installing the C runtime an ALL thousands of client systems that don't have it installed with the operating system.
We can't force our customer to do this or move from eg Windows Server 2012 R2 to newer versions as long as Microsoft itself supports these versions.

//EDIT:
Are there any other workarounds in the meanwhile?