UpdaterService fails due to handshake failure

[sormuras]

Using jlink to create a custom runtime image may lead to following output.

.bach\workspace\image\bin\bach-fxgl
22:34:48.332 [JavaFX Application Thread] INFO  Engine               - FXGL-11.11 (08.09.2020 18.00) on WINDOWS (J:16-ea FX:16-ea)
22:34:48.333 [JavaFX Application Thread] INFO  Engine               - Source code and latest versions at: https://github.com/AlmasB/FXGL
22:34:48.333 [JavaFX Application Thread] INFO  Engine               -              Join the FXGL chat at: https://gitter.im/AlmasB/FXGL
22:34:48.710 [FXGL Background Thread 1 ] INFO  FXGLApplication      - FXGL initialization took: 0.245 sec
22:34:48.778 [FXGL Background Thread 1 ] INFO  FXGLApplication      - Game initialization took: 0.020 sec
22:34:48.945 [FXGL Background Thread 2 ] WARN  UpdaterService       - Failed to find updates: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

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), the handshake_failure is no longer issued.

...
22:35:53.250 [FXGL Background Thread 2 ] INFO  UpdaterService       - Your current version:  11.11
22:35:53.250 [FXGL Background Thread 2 ] INFO  UpdaterService       - Latest stable version: dev-SNAPSHOT

[sormuras]

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

[AlmasB]

Nice, many thanks.

[AlmasB]

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.

[sormuras]

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;?

[AlmasB]

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!