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

[Scott Palmer]

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.(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.(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

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

[Kevin Rushforth]

I've made an
application image with jpackage.  I've moved the default location of the
runtime in the application image
...
If I keep the runtime in $APPDIR\runtime, things don't fail in this way.


If it works when using the default location of the Java runtime and no 
other changes, I'd guess that this is a bug in the jpackage app 
launcher, or maybe in the code that creates the runtime (e.g., if 
something isn't copied to the right place when not in the default 
location). Hopefully Andy or Alexey can comment.


-- Kevin


On 9/20/2021 2: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.(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.(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

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

[Andy Herrick]

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.(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.(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

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

[Alan Bateman]

On 21/09/2021 14:21, Andy Herrick 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 ?


The exception suggests that something is seriously broken, maybe that 
early VM initialization didn't execute correctly but I can't see what it 
didn't fail earlier. It would be great if there are steps to duplicate this.


-Alan.

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

[Scott Palmer]

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 
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.(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.(HttpsClient.java:266)
> >  at
> >
> java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.ja

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

[Andy Herrick]

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 > 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)
>     

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

[Andy Herrick]

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 > 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

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

[Alan Bateman]

On 21/09/2021 15:54, 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.


Good to see that you found it quickly. However I'm puzzled as why 
initializingEncoding wasn't called, I would have expected the VM to blow 
up during early startup. Would you have cycles to dig into that a bit 
more in case something has been masked, like for example an exception 
being swallowed.  Running with -Xlog:exceptions might reveal something.


-Alan

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

[Scott Palmer]

> On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:
> 
> On 21/09/2021 15:54, 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.
>> 
> Good to see that you found it quickly. However I'm puzzled as why 
> initializingEncoding wasn't called, I would have expected the VM to blow up 
> during early startup. Would you have cycles to dig into that a bit more in 
> case something has been masked, like for example an exception being 
> swallowed.  Running with -Xlog:exceptions might reveal something.


Do you have a case that reproduces the issue?

Scott

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

[Andy Herrick]

I thought I could create a reproduction scenario by using an app with 
"-splash:" arg then moving the jre as you did, but I have 
not yet been able make it fail.


/Andy

On 9/21/2021 11:43 AM, Scott Palmer wrote:

On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:

On 21/09/2021 15:54, 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.


Good to see that you found it quickly. However I'm puzzled as why 
initializingEncoding wasn't called, I would have expected the VM to blow up 
during early startup. Would you have cycles to dig into that a bit more in case 
something has been masked, like for example an exception being swallowed.  
Running with -Xlog:exceptions might reveal something.


Do you have a case that reproduces the issue?

Scott

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

[Scott Palmer]

I have discovered that I have to have my Java Agent configured  in the .cfg 
file for it to happen:

[JavaOptions]
java-option=-javaagent:$APPDIR\libs\MyAgent.jar


The agent is needed in my real app only to get an instance of the 
Instrumentation interface. In my test code, where I have reproduced this, it is 
never used.  My test app just takes a URL and fetches it via a 
HttpURLConnection with setInstanceFollowRedirects(false) so I can capture the 
new location.  If you are still having trouble reproducing I will have the code 
cleaned up for the bug report soon...


Regards,

Scott



> On Sep 21, 2021, at 12:12 PM, Andy Herrick  wrote:
> 
> I thought I could create a reproduction scenario by using an app with 
> "-splash:" arg then moving the jre as you did, but I have not yet 
> been able make it fail.
> 
> /Andy
> 
> On 9/21/2021 11:43 AM, Scott Palmer wrote:
>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:
>>> 
>>> On 21/09/2021 15:54, 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.
 
>>> Good to see that you found it quickly. However I'm puzzled as why 
>>> initializingEncoding wasn't called, I would have expected the VM to blow up 
>>> during early startup. Would you have cycles to dig into that a bit more in 
>>> case something has been masked, like for example an exception being 
>>> swallowed.  Running with -Xlog:exceptions might reveal something.
>> 
>> Do you have a case that reproduces the issue?
>> 
>> Scott

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

[Scott Palmer]

I’ve uploaded a project that reproduces the problem to JDK-8274087 


Regards,

Scott 

> On Sep 21, 2021, at 3:49 PM, Scott Palmer  wrote:
> 
> I have discovered that I have to have my Java Agent configured  in the .cfg 
> file for it to happen:
> 
> [JavaOptions]
> java-option=-javaagent:$APPDIR\libs\MyAgent.jar
> 
> 
> The agent is needed in my real app only to get an instance of the 
> Instrumentation interface. In my test code, where I have reproduced this, it 
> is never used.  My test app just takes a URL and fetches it via a 
> HttpURLConnection with setInstanceFollowRedirects(false) so I can capture the 
> new location.  If you are still having trouble reproducing I will have the 
> code cleaned up for the bug report soon...
> 
> 
> Regards,
> 
> Scott
> 
> 
> 
>> On Sep 21, 2021, at 12:12 PM, Andy Herrick  wrote:
>> 
>> I thought I could create a reproduction scenario by using an app with 
>> "-splash:" arg then moving the jre as you did, but I have not 
>> yet been able make it fail.
>> 
>> /Andy
>> 
>> On 9/21/2021 11:43 AM, Scott Palmer wrote:
 On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:
 
 On 21/09/2021 15:54, 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.
> 
 Good to see that you found it quickly. However I'm puzzled as why 
 initializingEncoding wasn't called, I would have expected the VM to blow 
 up during early startup. Would you have cycles to dig into that a bit more 
 in case something has been masked, like for example an exception being 
 swallowed.  Running with -Xlog:exceptions might reveal something.
>>> 
>>> Do you have a case that reproduces the issue?
>>> 
>>> Scott
> 

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

[Alan Bateman]

On 21/09/2021 20:49, Scott Palmer wrote:

:


The agent is needed in my real app only to get an instance of the 
Instrumentation interface.
As a general point, the Instrumentation object should never be leaked to 
applications or libraries. I have no idea what the agent does here but 
you should be able to this applications without the java.instrument 
module in the runtime image.


-Alan

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

[Andy Herrick]

Thanks Scott

This will help a lot because I couldn't reproduce this using just a 
splash screen as I expected I could.


I will look at this example this morning.

/Andy

On 9/21/21 7:05 PM, Scott Palmer wrote:
I’ve uploaded a project that reproduces the problem to JDK-8274087 



Regards,

Scott

On Sep 21, 2021, at 3:49 PM, Scott Palmer > wrote:


I have discovered that I have to have my Java Agent configured  in 
the .cfg file for it to happen:


[JavaOptions]
java-option=-javaagent:$APPDIR\libs\MyAgent.jar


The agent is needed in my real app only to get an instance of the 
Instrumentation interface. In my test code, where I have reproduced 
this, it is never used.  My test app just takes a URL and fetches it 
via a HttpURLConnection with setInstanceFollowRedirects(false) so I 
can capture the new location.  If you are still having trouble 
reproducing I will have the code cleaned up for the bug report soon...



Regards,

Scott



On Sep 21, 2021, at 12:12 PM, Andy Herrick > wrote:


I thought I could create a reproduction scenario by using an app 
with "-splash:" arg then moving the jre as you did, but 
I have not yet been able make it fail.


/Andy

On 9/21/2021 11:43 AM, Scott Palmer wrote:
On Sep 21, 2021, at 11:40 AM, Alan Bateman 
mailto:alan.bate...@oracle.com>> wrote:


On 21/09/2021 15:54, 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.


Good to see that you found it quickly. However I'm puzzled as why 
initializingEncoding wasn't called, I would have expected the VM 
to blow up during early startup. Would you have cycles to dig into 
that a bit more in case something has been masked, like for 
example an exception being swallowed.  Running with 
-Xlog:exceptions might reveal something.


Do you have a case that reproduces the issue?

Scott

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

[Andy Herrick]

I can't seem to get your testcase to work with the Oracle JDK configured.

I can build, but then when I run

$ ./build/application/FetchURL/FetchURL.exe

I get:

*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" 
with message c

an't find transform methodID at JPLISAgent.c line: 552
*** java.lang.instrument ASSERTION FAILED ***: "result" at 
JPLISAgent.c line: 400


FATAL ERROR in native method: processing of -javaagent failed
same behavior if I restore "runtime" directory and fix FetchURL.cfg to 
remove app.runtime entry.


anyway I used your two source files to build the test app without 
gradle, and the test can download 
https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8 
without any problems.


I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" 
to cfg file and app still ran fine (downloaded the above)


So I still don't have any way to reproduce this problemwith the Oracle jdk.

/Andy


PS:

Although something somewhere else may have changed to counter the 
problem, it's clear from your description, that since the only place in 
the code the default runtime path is used (instead of the actual runtime 
path, which may be different) is the line in WinLauncher.cpp to call 
SetDllDirectory().


This should be fixed - but would like a way to reproduce the problem it 
causes first.


/Andy

On 9/21/2021 12:12 PM, Andy Herrick wrote:
I thought I could create a reproduction scenario by using an app with 
"-splash:" arg then moving the jre as you did, but I have 
not yet been able make it fail.


/Andy

On 9/21/2021 11:43 AM, Scott Palmer wrote:
On Sep 21, 2021, at 11:40 AM, Alan Bateman  
wrote:


On 21/09/2021 15:54, 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.


Good to see that you found it quickly. However I'm puzzled as why 
initializingEncoding wasn't called, I would have expected the VM to 
blow up during early startup. Would you have cycles to dig into that 
a bit more in case something has been masked, like for example an 
exception being swallowed.  Running with -Xlog:exceptions might 
reveal something.


Do you have a case that reproduces the issue?

Scott

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

[Scott Palmer]

I reproduced it with the AZUL's distribution of OpenJDK (with JavaFX modules 
bundled) and I just changed:

vendor = JvmVendorSpec.ADOPTOPENJDK

And get the same error with that build of OpenJDK as well.  “OpenJDK Runtime 
Environment Temurin-17+35 (build 17+35)”
You can try that, as Gradle should download the JDK for you.

I then downloaded the Oracle build of OpenJDK from https://jdk.java.net/17/
(build 17+35-2724)
unzipped it to C:\Tools
building with:

gradlew -Porg.gradle.java.installations.paths=C:\Tools\jdk-17 clean build

I still reproduce the error.

Though the assertion in native JVM code that you are getting looks like yet 
another bug!  So perhaps it is good that it is discovered as well.


Scott

> On Sep 22, 2021, at 9:54 AM, Andy Herrick  wrote:
> 
> I can't seem to get your testcase to work with the Oracle JDK configured.
> 
> I can build, but then when I run
> 
> $ ./build/application/FetchURL/FetchURL.exe
> 
> I get:
> 
>> *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with 
>> message c
>> an't find transform methodID at JPLISAgent.c line: 552
>> *** java.lang.instrument ASSERTION FAILED ***: "result" at JPLISAgent.c 
>> line: 400
>> 
>> FATAL ERROR in native method: processing of -javaagent failed
> same behavior if I restore "runtime" directory and fix FetchURL.cfg to remove 
> app.runtime entry.
> 
> anyway I used your two source files to build the test app without gradle, and 
> the test can download 
> https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8 
> without any problems.
> 
> I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" to 
> cfg file and app still ran fine (downloaded the above)
> 
> So I still don't have any way to reproduce this problemwith the Oracle jdk.
> 
> /Andy
> 
> 
> PS:
> 
> Although something somewhere else may have changed to counter the problem, 
> it's clear from your description, that since the only place in the code the 
> default runtime path is used (instead of the actual runtime path, which may 
> be different) is the line in WinLauncher.cpp to call SetDllDirectory().
> 
> This should be fixed - but would like a way to reproduce the problem it 
> causes first.
> 
> /Andy
> 
> On 9/21/2021 12:12 PM, Andy Herrick wrote:
>> I thought I could create a reproduction scenario by using an app with 
>> "-splash:" arg then moving the jre as you did, but I have not 
>> yet been able make it fail.
>> 
>> /Andy
>> 
>> On 9/21/2021 11:43 AM, Scott Palmer wrote:
 On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:
 
 On 21/09/2021 15:54, 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.
> 
 Good to see that you found it quickly. However I'm puzzled as why 
 initializingEncoding wasn't called, I would have expected the VM to blow 
 up during early startup. Would you have cycles to dig into that a bit more 
 in case something has been masked, like for example an exception being 
 swallowed.  Running with -Xlog:exceptions might reveal something.
>>> 
>>> Do you have a case that reproduces the issue?
>>> 
>>> Scott

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

[Scott Palmer]

Sorry That last build with the Oracle OpenJDK needed the build file changed to 
have

   vendor = JvmVendorSpec.ORACLE

as well as the command line property pointing to the path to the jdk,

Scott 


> On Sep 22, 2021, at 10:24 AM, Scott Palmer  wrote:
> 
> I reproduced it with the AZUL's distribution of OpenJDK (with JavaFX modules 
> bundled) and I just changed:
> 
>   vendor = JvmVendorSpec.ADOPTOPENJDK
> 
> And get the same error with that build of OpenJDK as well.  “OpenJDK Runtime 
> Environment Temurin-17+35 (build 17+35)”
> You can try that, as Gradle should download the JDK for you.
> 
> I then downloaded the Oracle build of OpenJDK from https://jdk.java.net/17/   
>  (build 17+35-2724)
> unzipped it to C:\Tools
> building with:
> 
> gradlew -Porg.gradle.java.installations.paths=C:\Tools\jdk-17 clean build
> 
> I still reproduce the error.
> 
> Though the assertion in native JVM code that you are getting looks like yet 
> another bug!  So perhaps it is good that it is discovered as well.
> 
> 
> Scott
> 
>> On Sep 22, 2021, at 9:54 AM, Andy Herrick  wrote:
>> 
>> I can't seem to get your testcase to work with the Oracle JDK configured.
>> 
>> I can build, but then when I run
>> 
>> $ ./build/application/FetchURL/FetchURL.exe
>> 
>> I get:
>> 
>>> *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with 
>>> message c
>>> an't find transform methodID at JPLISAgent.c line: 552
>>> *** java.lang.instrument ASSERTION FAILED ***: "result" at JPLISAgent.c 
>>> line: 400
>>> 
>>> FATAL ERROR in native method: processing of -javaagent failed
>> same behavior if I restore "runtime" directory and fix FetchURL.cfg to 
>> remove app.runtime entry.
>> 
>> anyway I used your two source files to build the test app without gradle, 
>> and the test can download 
>> https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8 
>> without any problems.
>> 
>> I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" to 
>> cfg file and app still ran fine (downloaded the above)
>> 
>> So I still don't have any way to reproduce this problemwith the Oracle jdk.
>> 
>> /Andy
>> 
>> 
>> PS:
>> 
>> Although something somewhere else may have changed to counter the problem, 
>> it's clear from your description, that since the only place in the code the 
>> default runtime path is used (instead of the actual runtime path, which may 
>> be different) is the line in WinLauncher.cpp to call SetDllDirectory().
>> 
>> This should be fixed - but would like a way to reproduce the problem it 
>> causes first.
>> 
>> /Andy
>> 
>> On 9/21/2021 12:12 PM, Andy Herrick wrote:
>>> I thought I could create a reproduction scenario by using an app with 
>>> "-splash:" arg then moving the jre as you did, but I have not 
>>> yet been able make it fail.
>>> 
>>> /Andy
>>> 
>>> On 9/21/2021 11:43 AM, Scott Palmer wrote:
> On Sep 21, 2021, at 11:40 AM, Alan Bateman  
> wrote:
> 
> On 21/09/2021 15:54, 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.
>> 
> Good to see that you found it quickly. However I'm puzzled as why 
> initializingEncoding wasn't called, I would have expected the VM to blow 
> up during early startup. Would you have cycles to dig into that a bit 
> more in case something has been masked, like for example an exception 
> being swallowed.  Running with -Xlog:exceptions might reveal something.
 
 Do you have a case that reproduces the issue?
 
 Scott
> 

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

[Andy Herrick]

I still don't get the error your report.  Is there something else that 
needs to be set up for using instrumentation ?


I do get a different error when I have both runtime and jre directories 
after "cp -r jre runtime" (in FetchURL/build/application/FetchURL dir)


As built (before copy):


$ ./FetchURL
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" 
with message c

an't find transform methodID at JPLISAgent.c line: 552
*** java.lang.instrument ASSERTION FAILED ***: "result" at 
JPLISAgent.c line: 400


FATAL ERROR in native method: processing of -javaagent failed


after copy:


$ ./FetchURL
Exception in thread "main" java.lang.ClassNotFoundException: 
io.m3si.utils.ClassL

oaderUtils$Agent
    at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClas

sLoader.java:636)
    at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Cl

assLoaders.java:182)
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAg

ent(InstrumentationImpl.java:433)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPre

main(InstrumentationImpl.java:527)
*** java.lang.instrument ASSERTION FAILED ***: "result" with message 
agent load/p
remain call failed at 
t:\workspace\open\src\java.instrument\share\native\libinstr

ument\JPLISAgent.c line: 422
FATAL ERROR in native method: processing of -javaagent failed, 
processJavaStart f

ailed


but then with jre removed and line in cfg removed I get the same error:


$ ./FetchURL
Exception in thread "main" java.lang.ClassNotFoundException: 
io.m3si.utils.ClassLoaderUt

ils$Agent
    at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader

.java:636)
    at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoad

ers.java:182)
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(Ins

trumentationImpl.java:433)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(In

strumentationImpl.java:527)
*** java.lang.instrument ASSERTION FAILED ***: "result" with message 
agent load/premain
call failed at 
t:\workspace\open\src\java.instrument\share\native\libinstrument\JPLISAge

nt.c line: 422
FATAL ERROR in native method: processing of -javaagent failed, 
processJavaStart failed


note the "t:\workspace" ?  I don't have a t: drive, where is that coming 
from ?


/Andy


On 9/22/2021 10:25 AM, Scott Palmer wrote:

Sorry That last build with the Oracle OpenJDK needed the build file changed to 
have

vendor = JvmVendorSpec.ORACLE

as well as the command line property pointing to the path to the jdk,

Scott



On Sep 22, 2021, at 10:24 AM, Scott Palmer  wrote:

I reproduced it with the AZUL's distribution of OpenJDK (with JavaFX modules 
bundled) and I just changed:

vendor = JvmVendorSpec.ADOPTOPENJDK

And get the same error with that build of OpenJDK as well.  “OpenJDK Runtime 
Environment Temurin-17+35 (build 17+35)”
You can try that, as Gradle should download the JDK for you.

I then downloaded the Oracle build of OpenJDK from 
https://urldefense.com/v3/__https://jdk.java.net/17/__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzZBwkTMGA$
 (build 17+35-2724)
unzipped it to C:\Tools
building with:

gradlew -Porg.gradle.java.installations.paths=C:\Tools\jdk-17 clean build

I still reproduce the error.

Though the assertion in native JVM code that you are getting looks like yet 
another bug!  So perhaps it is good that it is discovered as well.


Scott


On Sep 22, 2021, at 9:54 AM, Andy Herrick  wrote:

I can't seem to get your testcase to work with the Oracle JDK configured.

I can build, but then when I run

$ ./build/application/FetchURL/FetchURL.exe

I get:


*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message 
c
an't find transform methodID at JPLISAgent.c line: 552
*** java.lang.instrument ASSERTION FAILED ***: "result" at JPLISAgent.c line: 
400

FATAL ERROR in native method: processing of -javaagent failed

same behavior if I restore "runtime" directory and fix FetchURL.cfg to remove 
app.runtime entry.

anyway I used your two source files to build the test app without gradle, and 
the test can download 
https://urldefense.com/v3/__https://linear-89.frequency.stream/dist/localnow/89/hls/master/playlist.m3u8__;!!ACWV5N9M2RV99hQ!eG4msXvYMONuZH2PKW1Mddol9UY2VkepPpI36eTZz9c_70fXHLm84-lrbzbGSGkGog$
  without any problems.

I then moved runtime to jre and added line "app.runtime=$APPDIR/../jre" to cfg 
file and app still ran fine (downloaded the above)

So I still don't have any way to reproduce this problemwith the Oracle jdk.

/Andy


PS:

Although something somewhere else may have changed to counter the problem, it's 
clear from your des

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

[Scott Palmer]

> On Sep 22, 2021, at 11:22 AM, Andy Herrick  wrote:
> 
> I still don't get the error your report.  Is there something else that needs 
> to be set up for using instrumentation ?

Nothing that I’m aware of.  Maybe there is something to do with Visual C/C++ 
runtime libraries that I have installed globally? -just a wild guess.

Ohhh… here’s something…

I had JDK 17 ‘bin’ folder on my PATH (along with many other things)
If I clear the PATH env var with:
 
 set PATH=

Then I get an different error:

Error occurred during initialization of VM
Could not find agent library instrument on the library path, with error: Can’t 
find dependent libraries
Module java.instrument may be missing from runtime image.

All I have to do to et back to the original error is

set PATH=C:\Tools\jdk-17\bin

So this is definitely related to the DLL search path, and it was just lucky 
that some libraries were found via PATH in my environment.

> 
> I do get a different error when I have both runtime and jre directories after 
> "cp -r jre runtime" (in FetchURL/build/application/FetchURL dir)
> 
> As built (before copy):
> 
>> $ ./FetchURL
>> *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with 
>> message c
>> an't find transform methodID at JPLISAgent.c line: 552
>> *** java.lang.instrument ASSERTION FAILED ***: "result" at JPLISAgent.c 
>> line: 400
>> 
>> FATAL ERROR in native method: processing of -javaagent failed
>> 
> after copy:
> 
>> $ ./FetchURL
>> Exception in thread "main" java.lang.ClassNotFoundException: 
>> io.m3si.utils.ClassL
>> oaderUtils$Agent
>> at 
>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClas
>> sLoader.java:636)
>> at 
>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Cl
>> assLoaders.java:182)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
>> at 
>> java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAg
>> ent(InstrumentationImpl.java:433)
>> at 
>> java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPre
>> main(InstrumentationImpl.java:527)
>> *** java.lang.instrument ASSERTION FAILED ***: "result" with message agent 
>> load/p
>> remain call failed at 
>> t:\workspace\open\src\java.instrument\share\native\libinstr
>> ument\JPLISAgent.c line: 422
>> FATAL ERROR in native method: processing of -javaagent failed, 
>> processJavaStart f
>> ailed
> 
> but then with jre removed and line in cfg removed I get the same error:
> 
>> $ ./FetchURL
>> Exception in thread "main" java.lang.ClassNotFoundException: 
>> io.m3si.utils.ClassLoaderUt
>> ils$Agent
>> at 
>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader
>> .java:636)
>> at 
>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoad
>> ers.java:182)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
>> at 
>> java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(Ins
>> trumentationImpl.java:433)
>> at 
>> java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(In
>> strumentationImpl.java:527)
>> *** java.lang.instrument ASSERTION FAILED ***: "result" with message agent 
>> load/premain
>> call failed at 
>> t:\workspace\open\src\java.instrument\share\native\libinstrument\JPLISAge
>> nt.c line: 422
>> FATAL ERROR in native method: processing of -javaagent failed, 
>> processJavaStart failed
> 
> note the "t:\workspace" ?  I don't have a t: drive, where is that coming from 
> ?

Must be from how the JDK was built.  I don’t have a T: drive either.

jar -tvf build\application\FetchURL\app\libs\FetchURL-0.0.01.jar
 0 Wed Sep 22 11:16:40 EDT 2021 META-INF/
   248 Wed Sep 22 11:16:40 EDT 2021 META-INF/MANIFEST.MF
 0 Wed Sep 22 11:10:30 EDT 2021 io/
 0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/
 0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/
 0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/fetchurl/
  3988 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/fetchurl/Main.class
  1000 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/ClassLoaderUtils$Agent.class
  4613 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/ClassLoaderUtils.class

I extracted MANIFEST.MF just to be sure …

Manifest-Version: 1.0
Implementation-Title: Kayak Plugins Bootstrap
Premain-Class: io.m3si.utils.ClassLoaderUtils$Agent
Implementation-Version: 1.0.1
Agent-Class: io.m3si.utils.ClassLoaderUtils$Agent
Main-Class: io.m3si.utils.fetchurl.Main

Looks right to me.

Scott

> 
> /Andy
> 
> 
> On 9/22/2021 10:25 AM, Scott Palmer wrote:
>> Sorry That last build with the Oracle OpenJDK needed the build file changed 
>> to have
>> 
>>vendor = JvmVendorSpec.ORACLE
>> 
>> as well as the command line property pointing to the path to the jdk,
>> 
>> Scott
>> 
>> 
>>> On Sep 22, 2021, at 10:24 AM, Scott Palmer  wrote:
>>> 
>>> I reproduced it with the AZUL's distribution of OpenJDK (with JavaFX 
>>> module

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

[Andy Herrick]

I also had a JDK16 bin dir on my path ...

I can get the error you show below (Error occurred during initialization 
of VM) if I clear my PATH, which is different from the error I get when 
running without moved runtime, so I can reproduce problem and test the fix.


I am using a script like:



./gradlew.bat clean build

cp -r build/application build/app2
mv build/app2/FetchURL/jre build/app2/FetchURL/runtime
cp FetchURLcfg.save build/app2/FetchURL/app/FetchURL.cfg

export PATH=

echo ""
echo "RUN as built:"
echo ""
build/application/FetchURL/FetchURL

echo ""
echo "RUN with default runtime:"
echo ""
build/app2/FetchURL/FetchURL

after fix both runs should have the same behavior and there should be no 
error like:



Error occurred during initialization of VM
Could not find agent library instrument on the library path, with 
error: Can't find dependent libraries

Module java.instrument may be missing from runtime image.


/Andy

On 9/22/2021 11:44 AM, Scott Palmer wrote:



On Sep 22, 2021, at 11:22 AM, Andy Herrick > wrote:


I still don't get the error your report.  Is there something else 
that needs to be set up for using instrumentation ?


Nothing that I’m aware of.  Maybe there is something to do with Visual 
C/C++ runtime libraries that I have installed globally? -just a wild 
guess.


Ohhh… here’s something…

I had JDK 17 ‘bin’ folder on my PATH (along with many other things)
If I clear the PATH env var with:
 set PATH=

Then I get an different error:

Error occurred during initialization of VM
Could not find agent library instrument on the library path, with 
error: Can’t find dependent libraries

Module java.instrument may be missing from runtime image.

All I have to do to et back to the original error is

set PATH=C:\Tools\jdk-17\bin

So this is definitely related to the DLL search path, and it was just 
lucky that some libraries were found via PATH in my environment.




I do get a different error when I have both runtime and jre 
directories after "cp -r jre runtime" (in 
FetchURL/build/application/FetchURL dir)


As built (before copy):


$ ./FetchURL
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" 
with message c

an't find transform methodID at JPLISAgent.c line: 552
*** java.lang.instrument ASSERTION FAILED ***: "result" at 
JPLISAgent.c line: 400


FATAL ERROR in native method: processing of -javaagent failed


after copy:


$ ./FetchURL
Exception in thread "main" java.lang.ClassNotFoundException: 
io.m3si.utils.ClassL

oaderUtils$Agent
    at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClas

sLoader.java:636)
    at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Cl

assLoaders.java:182)
    at 
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAg

ent(InstrumentationImpl.java:433)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPre

main(InstrumentationImpl.java:527)
*** java.lang.instrument ASSERTION FAILED ***: "result" with message 
agent load/p
remain call failed at 
t:\workspace\open\src\java.instrument\share\native\libinstr

ument\JPLISAgent.c line: 422
FATAL ERROR in native method: processing of -javaagent failed, 
processJavaStart f

ailed


but then with jre removed and line in cfg removed I get the same error:


$ ./FetchURL
Exception in thread "main" java.lang.ClassNotFoundException: 
io.m3si.utils.ClassLoaderUt

ils$Agent
    at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader

.java:636)
    at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoad

ers.java:182)
    at 
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(Ins

trumentationImpl.java:433)
    at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(In

strumentationImpl.java:527)
*** java.lang.instrument ASSERTION FAILED ***: "result" with message 
agent load/premain
call failed at 
t:\workspace\open\src\java.instrument\share\native\libinstrument\JPLISAge

nt.c line: 422
FATAL ERROR in native method: processing of -javaagent failed, 
processJavaStart failed


note the "t:\workspace" ?  I don't have a t: drive, where is that 
coming from ?


Must be from how the JDK was built.  I don’t have a T: drive either.

jar -tvf build\application\FetchURL\app\libs\FetchURL-0.0.01.jar
     0 Wed Sep 22 11:16:40 EDT 2021 META-INF/
   248 Wed Sep 22 11:16:40 EDT 2021 META-INF/MANIFEST.MF
     0 Wed Sep 22 11:10:30 EDT 2021 io/
     0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/
     0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/
     0 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/fetchurl/
  3988 Wed Sep 22 11:10:30 EDT 2021 io/m3si/utils/fetchurl/Main.class
  1000 Wed Sep 22 11:10:30 EDT 2021 
io/m3si/utils/ClassL