Another gap in JVMS 4.7.9.1

[Stephan Herrmann]

This loosely relates to the recent thread
     "spec clarification: wildcard array element signature".

JVMS seems to be lacking a definition how capture variables should be
encoded in class file attributes.

Until recently we believed this to be relevant only for LVTT,
where - according to javac - simply *not* generating an entry *could*
be a viable workaround.

Recently, s.o. reported the following program:

-----
public class Bug494198<T> {
   class Inner<U> {

   }
   public static void main(String[] args) {
     Bug494198<?> outer=new Bug494198<>();
     Object inner=outer.new Inner<String>() {
       public String toString() {
         return getClass().getGenericSuperclass().toString();
       }
     };
     System.out.println(inner);
   }
}
-----

When compiled with javac and run with java it throws GenericSignatureFormatError.
Inspecting Bug494198$1.class with javap shows:

----
final class Bug494198$1 extends Bug494198<<captured wildcard>>.Inner<java.lang.String>
----

The outer type argument is mandatory, but JVMS doesn't give an answer as to what
should be generated there.

For implementation reasons, ecj represents the wildcard as "!".

Neither is correct, it seems no answer *can* be correct against current JVMS.

I could imagine that even those "fresh type variables" introduced via JLS 18.4
need to appear in class file attributes in special situations.


While the above may be a contrived example, wanting to generate LVTT
with captures involved has been observed in real world examples.

thanks,
Stephan