Open salmonb opened 1 year ago
Good isse. I can imagine this is happening because the IPv6 classes are not added to the reflection config files.
javafx.scene.image.Image
has an error
and exception
property which get filled in when something unexpected happened while loading the image. You can add a listener and print the stack trace to see more info about the reason of the loading failure.
image.exceptionProperty().addListener((obs, ov, nv) -> {
if (nv != null) nv.printStackTrace();
});
@johanvos Not sure IPv6 are well separated classes in the JDK. FYI here is the trace I'm getting when trying URL.openStream():
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] java.net.NoRouteToHostException: No route to host
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at com.oracle.svm.jni.JNIJavaCallWrappers.jniInvoke_VA_LIST_NoRouteToHostException_constructor_96b3f65891b472d5be3aacfd448298970f4e1ca0(JNIJavaCallWrappers.java:0)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.nio.ch.Net.connect0(Net.java)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.nio.ch.Net.connect(Net.java:579)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.nio.ch.Net.connect(Net.java:568)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:588)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at java.net.Socket.connect(Socket.java:633)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:304)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.security.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:174)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.net.NetworkClient.doConnect(NetworkClient.java:183)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.net.www.http.HttpClient.openServer(HttpClient.java:498)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.net.www.http.HttpClient.openServer(HttpClient.java:603)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:266)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:380)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:189)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1242)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1128)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:175)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:224)
[Mon Jul 24 13:04:35 BST 2023][INFO] [SUB] at java.net.URL.openStream(URL.java:1161)
Here is the last Java code before JNI at Net.java:579
static int connect(ProtocolFamily family, FileDescriptor fd, InetAddress remote, int remotePort)
throws IOException
{
if (remote.isLinkLocalAddress()) {
remote = IPAddressUtil.toScopedAddress(remote);
}
boolean preferIPv6 = isIPv6Available() &&
(family != StandardProtocolFamily.INET);
return connect0(preferIPv6, fd, remote, remotePort); // <= failing JNI call
}
Thanks @tiainen for the exceptionProperty, I forgot about that...
We're seeing this issue too. Has there been progress on this?
I would love to have this issue resolved too, but I guess this is happening at the low level API, so in GraalVM rather than in Gluon Substrate itself.
The current version of Gluon Substrate is designed to work with its own fork of GraalVM, based on version 22.1.0.1 (2 years old). Oracle released newer versions of GraalVM since that time, and this issue may be solved now in GraalVM.
So I think the question for this issue is: does Gluon have a plan to update its fork to a newer GraalVM version?
On devices supporting IPv6, it's impossible to download anything from domains having a IPv6 DNS record.
For example, an ImageView with a URL pointing to such domain will show no image. No error is raised or logged in this case.
A call to URL.openStream() on such URL throws a "No route to host" exception. This issue happens only in the Gluon app, not in other apps of the device (pinging that domain or browsing that same URL in the browser works fine for example).
I reproduced the issue on iOS and iPadOS, not on Android but maybe just because my Android device is too old and doesn't support IPv6.
Expected Behavior
ImageView and URL.openStream() should work with IPv6 domains (as they do with IPv4 domains).
Current Behavior
ImageView and URL.openStream() don't work with IPv6 domains.
Steps to Reproduce
Here is a reproducer:
The application shows 4 thumbnails showing the image number, the hostname it comes from, and its IP address. The first 2 domains are IPv4 domains only, but the last 2 are IPv6 domains, as you can see below when running this app on a device supporting IPv6:
When clicking on a IPv4 thumbnail, the image is loading correctly (as shown above). But when clicking on a IPv6 thumbnail, no image is loaded (as shown below).
Your Environment
Issue reproduced on iPad mini 6 and iPhone SE 2017