Bug in JDK25 with switch statements

[Jan Lahoda]

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/0d61922e/attachment-0001.htm>