On Thu, Jun 11, 2015 at 9:42 AM, Alan Bateman <alan.bate...@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
