Bug in JDK25 with switch statements

[Rafael Winterhalter]

Yes, of course. On Java 25 the post processing is using the Class File API
and not ASM, but the method should be passed "as is" as it is not
transformed. Yet, the code seems to break.

I will have a look why this is the case and if this is a result of my
integration or the API in itself.

Thanks for the pointer. Best regards, Rafael



Am Fr., 21. März 2025 um 12:40 Uhr schrieb Jan Lahoda <jan.lahoda at oracle.com
>:

> Hello Rafael,
>
>
> I peeked at this, and it seems to me that when javac writes the file, the
> table switch offsets seem sensible:
>
>                      100: 322
>                      101: 374
>                      102: 374
>                      103: 374
>                      104: 374
>                      105: 374
>                      106: 374
>                      107: 374
>                      108: 374
>                      109: 296
>                      110: 374
>                      111: 374
>                      112: 361
>                      113: 374
>                      114: 335
>                      115: 348
>                      116: 309
>                  default: 374
>
> (I tweaked javac to make a copy of the generated classfile right after it
> is done with writing it to the disk.)
>
> But when the build ends, the classfile does not look sensible anymore. Is
> there some classfile postprocessing going on? Could you please check if
> that's working correctly?
>
>
> Thanks,
>
>     Jan
>
>
> On 21. 03. 25 11:15, Rafael Winterhalter wrote:
>
> (And of course, this is the right list, I originally thought to post this
> to the HotSpot list, but this happens in interpreted mode, so I excluded
> that.)
>
> Am Fr., 21. März 2025 um 11:14 Uhr schrieb Rafael Winterhalter <
> rafael.wth at gmail.com>:
>
>> The error is stable and can be reproduced by simply building the project.
>> But it seems to be an issue with javac indeed. The tableswitch statement is
>> compiled as follows.
>>
>>        213: tableswitch   { // 100 to 116
>>                      100: 322
>>                      101: 296
>>                      102: 361
>>                      103: 335
>>                      104: 348
>>                      105: 309
>>                      106: 374
>>                      107: 374
>>                      108: 374
>>                      109: 374
>>                      110: 374
>>                      111: 374
>>                      112: 374
>>                      113: 374
>>                      114: 374
>>                      115: 374
>>                      116: 374
>>                  default: 374
>>
>> The right branch for 'p' is included at offset 361, but 'p' is an integer
>> value of 109. The character 102 (f) is not included in the Java source.
>>
>> I guess this is the wrong mailing list in this case. I will post this to
>> the javac list.
>>
>> Thanks, Rafael
>>
>> Am Fr., 21. März 2025 um 10:54 Uhr schrieb Remi Forax <forax at univ-mlv.fr
>> >:
>>
>>> Hello Raphael,
>>> It may be hard to reproduce,
>>> can you do a javap -c on the class/method so it will be easier to see if
>>> the generated bytecode is wrong of if it's a VM issue.
>>>
>>> regards,
>>> Rémi
>>>
>>> ------------------------------
>>>
>>> *From: *"Rafael Winterhalter" <rafael.wth at gmail.com>
>>> *To: *"compiler-dev" <compiler-dev at openjdk.org>
>>> *Sent: *Friday, March 21, 2025 10:20:48 AM
>>> *Subject: *Bug in JDK25 with switch statements
>>>
>>> Hello,
>>> my project Byte Buddy fails to build with recent JDK 25s. I am not sure
>>> if this is a known bug, but I wanted to mention it:
>>> https://github.com/raphw/byte-buddy/actions/runs/13975513319/job/39131008617
>>>
>>> The reason for the build failure is that this switch statement ends up
>>> in the default branch:
>>> https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/asm/Advice.java#L3239
>>>
>>> This is happening for the char 'p' which is the last legal branch of the
>>> switch. This does not yield an error on JDKs 5 to 24, so this must be
>>> introduced recently.
>>>
>>> Thanks, Rafael
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250321/e0411f42/attachment.htm>