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
<https://bugs.openjdk.java.net/browse/JDK-8274087>
Regards,
Scott
On Sep 21, 2021, at 3:49 PM, Scott Palmer <swpal...@gmail.com
<mailto:swpal...@gmail.com>> 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 <andy.herr...@oracle.com
<mailto:andy.herr...@oracle.com>> wrote:
I thought I could create a reproduction scenario by using an app
with "-splash:<image file>" 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
<alan.bate...@oracle.com <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
