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.
-Alan
More information about the core-libs-dev
mailing list