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

Tue Sep 21 15:35:03 UTC 2021

I filed:     JDK-8274087: Windows DLL path not set correctly.

for this, and will work on a fix for JDK18 and backport to JDK17.0.2.

/Andy

On 9/21/2021 10:54 AM, Andy Herrick wrote:
> 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
>>