Open sormuras opened 3 years ago
I guess, FXGL uses module java.net.http
, which in turn gets some https
-related bits from module jdk.crypto.ec
.
See also https://stackoverflow.com/questions/55439599/sslhandshakeexception-with-jlink-created-runtime
Nice, many thanks.
fxgl-net is the module that deals with networking stuff. UpdaterService (and any other code) calls fxgl-net
to deal with networking. So, I suppose jdk.crypto.ec
should go to the module-info.java
in fxgl-net
? If so, you are welcome to send a PR.
I'd be happy to provide a PR, Almas.
Yet, module com.almasb.fxgl.net
doesn't read module java.net.http
as I expected. Perhaps, the standard "java.net" API from module java.base
already reads that crypto-related module ... via META-INF/services
? Do you want (me) to figure out the underlying reason before adding requires jdk.crypto.ec;
?
Yeah, I don't remember adding java.net.http
...
There is no rush with this as it doesn't crash the engine. The good news is that you already have a fix. So if you have time, a quick investigation would be much appreciated!
Meanwhile...
warning: [removal] module jdk.crypto.ec has been deprecated and marked for removal requires jdk.crypto.ec; // https://github.com/AlmasB/FXGL/issues/910
That's due to https://bugs.openjdk.org/browse/JDK-8308398 "Move SunEC crypto provider into java.base" in Java 22.
Using
jlink
to create a custom runtime image may lead to following output.See https://github.com/sormuras/bach-fxgl/actions/runs/403066229 for an example and a reproducer.
If one adds
requires jdk.crypto.ec;
to a module description (or add it to linked modules manually), thehandshake_failure
is no longer issued.