I don't see anything wrong with this offhand. the runtime should be able
to be anywhere if the cfg files "app.runtime" line points to it.
Is this on windows ? Is the the released JDK17 used both for the jlinked
runtime and the jpackage tool ?
Are there any libraries in $APPDIR (which is added to the $PATH env
variable on windows) which could be interfering with encoding
initialization ?
Can you try the following experiment:
manually edit the cfg file line:
app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre
to contain the canonical path to
...\my_own_folder\where_the_jre_is_deeper\jre
and try again ?
/Andy
On 9/20/2021 5:37 PM, Scott Palmer wrote:
This is likely not the right place to ask this (sorry).. but I'm trying to
get info to write a bug report and want to make sure I'm not doing
something stupid first.
I've created a JRE image from JDK 17 with jlink. I've made an
application image with jpackage. I've moved the default location of the
runtime in the application image and modified the launcher .cfg file
accordingly by adding a line to the [Application] section
app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre
My application launches. It shows a JavaFX GUI. It does a bunch of stuff
that "works", but then one thread fails with this exception:
Exception in thread "Reader-BG-1" java.lang.InternalError: platform
encoding not initialized
at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native
Method)
at
java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933)
at
java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1519)
at
java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:852)
at
java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509)
at
java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367)
at
java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301)
at java.base/java.net.InetAddress.getByName(InetAddress.java:1251)
at
java.base/java.net.InetSocketAddress.<init>(InetSocketAddress.java:229)
at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:178)
at
java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:498)
at
java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:603)
at
java.base/sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:266)
at
java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:380)
at
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:189)
at
java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1242)
at
java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1128)
at
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:175)
at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665)
at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589)
at
java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:529)
at
java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:308)
If I keep the runtime in $APPDIR\runtime, things don't fail in this way.
Smells like a bug in the app launcher to me.. but maybe it's in the runtime?
Any assistance would be appreciated (including telling me where I should go
to ask this, if this list isn't appropriate).
Thanks,
Scott
