RFR: 8268894: ArrayIndexOutOfBoundsException in jdk compiler: at jdk.compiler/com.sun.tools.javac.jvm.ClassWriter.writePosition(ClassWriter.java:671)

Guoxiong Li gli at openjdk.java.net
Thu Aug 26 08:51:30 UTC 2021

On Wed, 25 Aug 2021 20:00:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> from your description it seems like the bug is more on the lombok side than in javac's, if I understand correctly you are saying that the bug is provoked by lombok because it is not generating completely correct ASTs right

The lombok may need to be improved. But javac shouldn't crash at this situation. It should compile the sources successfully or report a related warning(maybe a new warning `Wrong Position`). Because the wrong source positions may only affect the positions of the errors or warnings and have not much impact to the syntax and semantics.

> but still the information in `lvarOffset` seems to be used so not generating it doesn't seem like the best option

I can't find a place that the variable `lvarOffset` is used individually without `lvarLength` and `lvarIndex`. I find the `lvarOffset` always be used like the following code. So we should generate or use `lvarOffset`, `lvarLength` and `lvarIndex` together and couldn't use or generate one of them individually.

// com.sun.tools.javac.jvm.ClassWriter
            databuf.appendChar(p.lvarOffset.length);  // for table length
            for (int i = 0; i < p.lvarOffset.length; ++i) {

@vicente-romero-oracle can you find the code that `lvarOffset` is used independently after `lvarOffset = new int[]{to};`? Or I am missing something, too.

>  it could be that we need to make sure that the 3 arrays are in sync before generating the class file

Good idea. But I still want to remove `lvarOffset = new int[]{to};` if we can comfirm it is redundant.
And maybe I can `sync before generating the class file` and remove `lvarOffset = new int[]{to};` at the same time to improve the code and prevent the wrong usage in the future.


PR: https://git.openjdk.java.net/jdk/pull/4749

More information about the compiler-dev mailing list