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.herr...@oracle.com
<mailto: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
<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
