On Tue, 27 Jan 2026 14:26:45 GMT, Chen Liang <[email protected]> wrote:
> I don't think this is worth it - most user programs will refer to UTF_8 as
> StandardCharsets.UTF_8, so this doesn't really optimize anything. Also in the
> ArrayDeque to ArrayList case, ArrayList has other allocation benefits in
> addition to avoiding ArrayDeque class load. So I personally recommend
> withdrawing this patch, especially that AOT preimage should be able to
> capture the linked or even initialized state of StandardCharsets class.
Some context: I spotted this because I've gotten review feedback in the past
(from @cl4es IIRC) about avoiding `StandardCharsets` in this class.
The current version of the class has three occurrences of `UTF_8.INSTANCE`
besides this one recently introduced `StandardCharsets.UTF_8` instance. So
there is a consistency issue here as well, besides any (valid or invalid)
performance concerns.
See also the following note from `StandardCharsets`:
// To avoid accidental eager initialization of often unused Charsets
// from happening while the VM is booting up, which may delay
// initialization of VM components, we should generally avoid depending
// on this class from elsewhere in java.base.
@cl4es may have opinions about the present validity of this note.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29443#issuecomment-3805613881
