What causes java.lang.InternalError: platform encoding not initialized ?

Scott Palmer swpalmer at gmail.com
Tue Sep 21 14:17:04 UTC 2021


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.herrick at 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
>


More information about the core-libs-dev mailing list