[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 
> <https://bugs.openjdk.java.net/browse/JDK-8274087>
>
> Regards,
>
> Scott
>
>> On Sep 21, 2021, at 3:49 PM, Scott Palmer <swpalmer at gmail.com 
>> <mailto:swpalmer at 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.herrick at oracle.com 
>>> <mailto:andy.herrick at 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.Bateman at oracle.com <mailto:Alan.Bateman at 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
>>
>