This is on Windows 10 Pro. using JDK 17 for jpackage and I'm pretty sure for jimage (though the image was made shortly after 17 GA and is being reused)..
There are no libraries directly in $APPDIR, though there are plenty in other sibling folders to the 'app' folder (in addition to those in app\libs) I changed app.runtime to point to the (relative) path without the $APPDIR\.. - same problem. Tried a absolute path, same problem. The exact same runtime folder that was failing for me was simply copied to the default location to make it work. It works if I leave app.runtime out of the .cfg file, or if I point to $APPDIR\..\runtime I did some more experiments and found that if I just rename the 'runtime' folder to 'jre', but leave it at the same depth then the problem appears. I suspected there must be some hardcoded reference to the 'runtime' folder in the app launcher. However, if I have two copies of the runtime, one at the default location, and use app.runtime to point to the other copy it still fails. (i.e. if it is referencing some library from the default location it doesn't help.. I thought it might, being that it is all in the same process.) The application is complex. It has a plugin mechanism that uses an Agent and the Instrument class to augment the classpath at runtime. (Older versions of the plugin mechanism used to hack the System classloader on JDK 8 and switching to an Agent was the fastest way to make it work on later versions in a supported manner. It likely should be using custom classloaders, but classloading issues got messy when I looked into that way back when we started.) I will try to find time later this week to isolate a test case that can reproduce it. For now I can work around the issue by putting the runtime back to the default location for this case. This is a special case of an application that actually includes the JRE itself as one of the plugins so we can upgrade the JRE after the initial deployment or run different jobs with different JREs. I was trying to make a smaller tool/demo that used the JRE from where it would be in our "plugin" folder. Regards, Scott On Tue, Sep 21, 2021 at 9:22 AM Andy Herrick <andy.herr...@oracle.com> wrote: > 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 >