Inconsistent classfile encountered on annotated generic types

[tiller]

Extracted from #4616

The following project : https://github.com/Tiller/jdt-annot-issue (master branch)

Gives the following error:

Inconsistent classfile encountered: The undefined type parameter T is referenced from within ReturnUpdateCommand

It is most certainly due to the annotated generics :

Patch<@ValidUrlTemplate(value = UrlValidationType.RETURN_LABEL_URL, message = "{" + RETURN_LABEL_URL_VALIDATION_ERROR + "}") String> labelUrl

This issue is also most certainly the root cause of another issue I have (but the repro given doesn't reproduce the second issue afaik) where a lot of records and/or classes of my project are silently not compiled. No error, just no .class files. But when I open the file in the editor and save, the .class is generated. => When I remove all annotated generics in my project, the issue disappear

Issue appeared after upgrading from 4.37 to 4.38 nightly

[srikanth-sankaran]

Inconsistent classfile encountered: The undefined type parameter T is referenced from within ReturnUpdateCommand

@tiller Where would I see this error ? I don't see anything in the Problems view nor in log view ? Did you perhaps get it when you tried to dump a class file content with javap ? If so which file ?

[srikanth-sankaran]

Ah, looks like I need to make some changes in the editor and save ... investigating ...

[srikanth-sankaran]

In the generated class file, we have:

private final test.Patch labelUrl;
descriptor: Ltest/Patch;
flags: (0x0012) ACC_PRIVATE, ACC_FINAL
Signature: #15 // Ltest/Patch<TT;>;

See the signature of the field. Broken.

Compare the first two fields:

private final test.Patch<java.lang.String> tracking;
descriptor: Ltest/Patch;
flags: (0x0012) ACC_PRIVATE, ACC_FINAL
Signature: #8 // Ltest/Patch<Ljava/lang/String;>;
RuntimeVisibleTypeAnnotations:
0: #10(): FIELD, location=[TYPE_ARGUMENT(0)]
test.Valid

private final test.Patch<java.lang.String> rma;
descriptor: Ltest/Patch;
flags: (0x0012) ACC_PRIVATE, ACC_FINAL
Signature: #8 // Ltest/Patch<Ljava/lang/String;>;

which show up with the right signature. Something goes wrong when resolving Patch<@ValidUrlTemplate(value = UrlValidationType.AA, message = "{}") String>

[srikanth-sankaran]

Shorter single file test case that shows the problem:

package test;

import java.lang.annotation.Target;

public record Record(
        Patch<@ValidUrlTemplate(value = UrlValidationType.AA, message = "{}") String> labelUrl) { 
}

class Patch<T> {
    public T field;
}

enum UrlValidationType {
    AA, BB
}

@Target(java.lang.annotation.ElementType.TYPE_USE)
@interface ValidUrlTemplate {
    UrlValidationType value();
    String message();
}

Relevant dump from javap:

  private final test.Patch<T> labelUrl;
    descriptor: Ltest/Patch;
    flags: (0x0012) ACC_PRIVATE, ACC_FINAL
    Signature: #8                           // Ltest/Patch<TT;>;  // HERE SIGNATURE IS WRONG!!!
    RuntimeInvisibleTypeAnnotations:
      0: #10(#11=e#12.#13,#14=s#15): FIELD, location=[TYPE_ARGUMENT(0)]
        test.ValidUrlTemplate(
          value=Ltest/UrlValidationType;.AA
          message="{}"
        )

  public test.Patch<java.lang.String> labelUrl();
    descriptor: ()Ltest/Patch;
    flags: (0x0001) ACC_PUBLIC
    Signature: #17                          // ()Ltest/Patch<Ljava/lang/String;>;  // HERE SIGNATURE IS OK
    RuntimeInvisibleTypeAnnotations:
      0: #10(#11=e#12.#13,#14=s#15): METHOD_RETURN, location=[TYPE_ARGUMENT(0)]
        test.ValidUrlTemplate(
          value=Ltest/UrlValidationType;.AA
          message="{}"
        )
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: getfield      #19                 // Field labelUrl:Ltest/Patch;
         4: areturn
      LineNumberTable:
        line 6: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature

[srikanth-sankaran]

I have a PR under test here: #4629

All the three recent issues are due to the same underlying reason - reentrancy triggered by annotation handling that we are ill prepared for. Thanks for the defect reports. Any remaining issues - please share suitable test cases and we will prioritize the fixes so 4.38 is solid w.r.t to this feature.