RFR(M): 8081674: EmptyStackException at startup if running with extended or unsupported charset

[Volker Simonis]

On Thu, Jun 11, 2015 at 9:42 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 10/06/2015 20:02, Mandy Chung wrote:
>>
>> :
>> ClassLoader.java
>>     It should have done that.  Nit:
>>     Can you move line 1693 to 1868 closer to loadLibrary0 (the caller of
>> findBuiltinLib)?
>>     Also make it private.
>>
>> Same applies to jdk9.
>>
>> Otherwise looks good.  No need to generate a webrev as long as you make
>> the change before the push.
>
> Looks good to me too (assuming these changes).
>

Thanks!

>> :
>>
>>> On jdk9 we are now running in another problem which is caused by the
>>> fact that the extended charsets are now being loaded by ServiceLoader
>>> (I've detailed that already in the bug report). But I think we can
>>> leave the fix of that problem to another change as this seems to
>>> require some more reasoning (see Alan's comments in the bug report).
>>
>> Yes this is a harder problem that have to investigate further.
>>
> Right, the main issue here is that java.base must contain all charsets that
> are needed during start up / VM initialization. There is also no guarantee
> the jdk.charsets module will be linked into the run-time image.
>
> There are two scenarios that come from this. One is the LANG setting as we
> have here, the other is attempting to run with file.encoding set. The choice
> as to whether to fail gracefully or switch to UTF-8 might be different for
> these two scenarios, it just investigation and a proposal.
>

I'd vote for falling back to either UTF-8 or ISO-8859-1 and issuing a
warning. Failing gracefully maybe difficult as we're in the middle of
the initialization so throwing an exception is probably the best we
can do (which I wouldn't consider "gracefully").

Regards,
Volker

> -Alan