Use SmallRye FFM to reliably get host name - #524
Conversation
0a9afe8 to
7ac678d
Compare
|
I understand that on classic JVM, only one of the native methods will ever get called, so only one of them will get linked, but with GraalVM native image, it seems to me you rely on |
|
It's okay if it did try to link it though. |
|
But it wouldn't succeed then? The bootstrap method would, IDK, probably throw an exception? I don't know how native image would behave in that case. Well, more of a theoretical concern. I was just wondering. |
|
The internal function resolution (via |
Ah, clever! Nice! |
08be907 to
1231e45
Compare
This comment was marked as resolved.
This comment was marked as resolved.
f57cacd to
7645d50
Compare
|
Hey, it works now. Cool. |
|
Updated to use the new |
This is a quick example of how SmallRye FFM can be used. In this case, we have always relied on complicated heuristics to determine the system host name because Java has no API to access this information. But with SmallRye FFM, we can just make the native call directly if the JVM allows it.
This should not necessarily be considered for merging, at least until we have solutions for both Quarkus and WildFly to register native access. But eventually, doing something like this could replace most of the heuristics that we currently employ (like probing environment variables).
Note that while this is a large change, much of the change consists of things that should be moved to a parent POM: working around impsorter bugs, establishing common versions. Also, there are some legitimately missing tests in the
netmodule relating to host name (it's hard to really test in general, but we can at least make sure we don't explode).Edit: the Windows build doesn't presently work; this may be a problem on the SmallRye FFM side, but it can be ignored for now.