[External] : Re: JDK-8268622 - Performance issues in javac `Name` class

[Archie Cobbs]

Hi Jon et. al.,

Picking back up this email thread regarding JDK-8269957
<https://bugs.openjdk.org/browse/JDK-8269957>: "facilitate alternate impls
of NameTable and Name" after a detour to incorporate these recent
changes/fixes:

   - JDK-8303526: Changing "arbitrary" Name.compareTo() ordering breaks the
   regression suite
   - JDK-8303623: Compiler should disallow non-standard UTF-8 string
   encodings

I've created a new (draft) PR - https://github.com/openjdk/jdk/pull/13282

When you get a chance let me know what you think.

Thanks,
-Archie

On Mon, Mar 6, 2023 at 6:57 PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Mon, Mar 6, 2023 at 4:15 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> Yes, as a general rule, the compiler and runtime should be mutually
>> consistent.
>>
> I've updated the PR to check for classfile major version < 48. In that
> case longer-than-necessary encodings are allowed.
>
>> This discussion probably also applies to javac reading names in source
>> files and having those names propagate to class files.
>>
> Agreed. Though I think we're good here because the Lexer/Scanner uses a
> CharsetDecoder that detects errors on malformed input. As a simple test I
> verified that StandardCharsets.UTF_8 returns "MALFORMED" on input with "è"
> encoded as c3 e8.
>
> And after the lexer step, you're going from char[] to byte[], and those
> conversions are already being done correctly in the compiler code.
>
> It's the byte[] to char[] step in which "non-standard" encodings can creep
> in.
>
> -Archie
>
> --
> Archie L. Cobbs
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230403/6571a072/attachment.htm>