RFR [10]: 8186517: sun.nio.cs.StandardCharsets$Aliases and ClassMap can be lazily loaded

Martin Buchholz martinrb at google.com
Mon Aug 21 18:05:55 UTC 2017


I agree we should optimize for common charset names, in part to help the
world move to UTF-8.

It's *weird* to canonicalize to lower case, when the canonical charset
names are all uppercase ("UTF-8" instead of "utf-8").

---

  62     public static final String UTF_8 = "UTF-8";

Is this still used?

Maybe the very first thing lookup() should do is check
charsetName == UTF_8

---

Is switching from char[] to StringBuilder really an improvement?  Charset
names are all short, so the cost of copying the char[] to a byte[] is
negligible.


On Mon, Aug 21, 2017 at 6:46 AM, Claes Redestad <claes.redestad at oracle.com>
wrote:

> Hi,
>
> the Aliases and Classes inner classes in StandardCharsets can be
> lazily-loaded by restructuring how we check for the three
> default-loaded charsets. This removes some classloading and
> work from happening during critical phases of the VM startup,
> as well as a net gain on any systems that default to any of the
> three standard charsets (UTF-8, Latin-1, ASCII).
>
> Webrev: http://cr.openjdk.java.net/~redestad/8186517/jdk.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8186517
>
> I'm not sure if the pre-existing optimization to allow
> StandardCharsets.charsets() unsynchronized access to internals
> is really necessary (or even 100% correct), but by ensuring we
> retrieve the Aliases and Classes instances in a synchronized block
> we should be no worse off semantically here.
>
> /Claes
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170821/00a409ec/attachment.html>


More information about the nio-dev mailing list