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

Alan Bateman Alan.Bateman at oracle.com
Thu Jun 11 07:42:18 UTC 2015

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

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


More information about the hotspot-dev mailing list