[External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

Andy Herrick andy.herrick at oracle.com
Tue Sep 21 14:54:18 UTC 2021


I found the problem in 
open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp

we call SetDllDirectory() with the path to the bin dir in the default 
runtime directory, not the actual runtime directory.

since on Windows we never use other than the default runtime location - 
we had not seen a problem, but is bug I will file and fix.

Thanks.

/Andy

On 9/21/2021 10:17 AM, Scott Palmer wrote:
> 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 
> <mailto: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
>     <https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.Inet6AddressImpl.lookupAllHostAddr(Native
>     > Method)
>     >          at
>     > java.base/java.net
>     <https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933)
>     >          at
>     > java.base/java.net
>     <https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.InetAddress.getAddressesFromNameService(InetAddress.java:1519)
>     >          at
>     > java.base/java.net
>     <https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.InetAddress$NameServiceAddresses.get(InetAddress.java:852)
>     >          at
>     > java.base/java.net
>     <https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.InetAddress.getAllByName0(InetAddress.java:1509)
>     >          at
>     > java.base/java.net
>     <https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.InetAddress.getAllByName(InetAddress.java:1367)
>     >          at
>     > java.base/java.net
>     <https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.InetAddress.getAllByName(InetAddress.java:1301)
>     >          at java.base/java.net
>     <https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.InetAddress.getByName(InetAddress.java:1251)
>     >          at
>     > java.base/java.net
>     <https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.InetSocketAddress.<init>(InetSocketAddress.java:229)
>     >          at java.base/sun.net
>     <https://urldefense.com/v3/__http://sun.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPmjoCOyeg$>.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
>     <https://urldefense.com/v3/__http://java.net__;!!ACWV5N9M2RV99hQ!cK2V22iJze6hwFbWIzZKgRder-bdAm7ZPMElasps8WXPWPT4Bp6Q1eXLXPnKuOQcpQ$>.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