RFR 8234147 : Avoid looking up standard charsets in core libraries

Ivan Gerasimov ivan.gerasimov at oracle.com
Wed Nov 27 11:52:03 UTC 2019


Thank you Alan for reviewing!

Please see the comments inline.

On 11/26/19 11:54 PM, Alan Bateman wrote:
> On 27/11/2019 04:39, Ivan Gerasimov wrote:
>> Hello!
>>
>> It is a cleanup fix with mostly two kinds of changes:
>> - when a standard charset is specified by its name, use a 
>> preinitialized Charset constant instead,
>> - replace the usage of StandardCharset.* constants with their 
>> sun.nio.cs.* equivalents to avoid accidental early initialization of 
>> rarely-used charsets.
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8234147
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8234147/00/webrev/
>>
>> I also had to modify one regression test that relied on a private 
>> auxiliary method, which was removed with the fix.
>>
>> Mach5 control build looks green.
>>
>> Would you please help review the fix?
> The motivation is okay and most of the changes are okay but it does 
> create a needless dependency on sun.nio.* classes in places that are 
> unlikely (or impossible) to use during early startup. I think the 
> change to the JDBC CachedRow implementation, prefs, and the 
> jdk.net.httpserver module should be dropped as want fewer classes 
> outside of java.base depending on java.base internals, not more. I 
> also wonder about the NTLM, XML properties and a few more that 
> shouldn't be dependency on sun.nio.* classes if possible.
>
Please note that in fact sun.nio.cs.* was not used in java.net.http, 
java.prefs and java.sql.rowset.  I only used those sun.nio constants 
inside the java.base module, exactly for the reason of avoiding 
additional dependencies.

It's not clear how to distinguish the classes inside the java.base 
module that do not have to depend on sun.nio.cs.  If you feel strong 
about NTLM and XML, I can replace sun.nio.cs.* instances with 
corresponding java.charset.StandardCharsets.* constants in these classes.

>
>
> Minot nit but if this is pushed then it would be good to keep the 
> imports consistent with the existing style where you can, e.g. I see 
> several files where the import sun.nio.* is put at the top of source 
> files that already group imports of JDK internal classes together 
> further down.
>
Thanks, done.  Unfortunately, imports conventions are not very 
consistent across the JDK code, so I mostly tried to preserve the 
pre-existing order of imports in each file.

> Mandy might want to comment on TrySetAccessibleTest. If I'm not 
> mistaken it should say "non-exported" rather than "exported". Also I 
> think we want this test to have a dependency on a few JDK internal and 
> private methods as possible as it's a maintenance issue to keep it up 
> to date (as you've experienced here with the removal of Perf.getBytes).
>
If I got it correct, the test was meant to access a private static 
method, and after removing Perf.getBytes there were no such methods left 
in the Perf class.  That's why I had to pick some other method to test, 
so I chose ModulePath.packageName instead.

Here's the updated webrev with reorganized imports:

http://cr.openjdk.java.net/~igerasim/8234147/01/webrev/

Thanks again!

-- 
With kind regards,
Ivan Gerasimov



More information about the core-libs-dev mailing list