Странная запись "! *" В LocalVariableTypeTable при компиляции с компилятором eclipse

Скомпилируйте следующий код с помощью компилятора ECJ из пакета Eclipse Mars.2:

import java.util.stream.*;

public class Test {
    String test(Stream<?> s) {
        return s.collect(Collector.of(() -> "", (a, t) -> {}, (a1, a2) -> a1));
    }
}

Команда компиляции следующая:

$ java -jar org.eclipse.jdt.core_3.11.2.v20160128-0629.jar -8 -g Test.java

После успешной компиляции позвольте проверить полученный файл класса с помощью javap -v -p Test.class. Наиболее интересным является синтетический метод, сгенерированный для (a, t) -> {} lambda:

  private static void lambda$1(java.lang.String, java.lang.Object);
    descriptor: (Ljava/lang/String;Ljava/lang/Object;)V
    flags: ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC
    Code:
      stack=0, locals=2, args_size=2
         0: return
      LineNumberTable:
        line 5: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       1     0     a   Ljava/lang/String;
            0       1     1     t   Ljava/lang/Object;
      LocalVariableTypeTable:
        Start  Length  Slot  Name   Signature
            0       1     1     t   !*

Я был очень удивлен, увидев эту запись !* в LocalVariableTypeTable. Спецификация JVM охватывает атрибут LocalVariableTypeTable и говорит:

Запись constant_pool в этом индексе должна содержать структуру CONSTANT_Utf8_info (§4.4.7), представляющую сигнатуру поля, которая кодирует тип локальной переменной в исходной программе (§4.7.9.1).

§4.7.9.1 определяет грамматику для сигнатур поля, которая, если я правильно понимаю, не охватывает ничего похожего на !*.

Следует также отметить, что ни javac-компилятор, ни старые версии ECJ 3.10.x не генерируют эту запись LocalVariableTypeTable. Является ли !* некоторым нестандартным расширением Eclipse или я что-то пропускаю в спецификации JVM? Означает ли это, что ECJ не соответствует спецификации JVM? Что означает !* и есть ли другие подобные строки, которые могут появляться в атрибуте LocalVariableTypeTable?

Последствия

Приведенное выше описывает и объясняет статус-кво, демонстрируя, что никакая спецификация не говорит компилятору вести себя иначе, чем текущий статус. Очевидно, что это не совсем желательная ситуация.

Кто-то может обратиться в Oracle, отметив, что Java 8 представляет ситуацию, которая не распространяется на части JVMS. Эта ситуация может стать еще более актуальной, как только локальные переменные станут объектом вывода типа

Любой, кто наблюдает за негативным воздействием текущей ситуации, приглашается перезвонить в rfe 494198 (ecj), который в противном случае имеет низкий приоритет.

Update: Между тем кто-то сообщил пример, где требуется обычный Signature (который не может быть оппортунически опущен), чтобы кодировать тип, который не может быть закодирован в соответствии с JVMS. В этом случае также javac создает неуказанный байтовый код. Согласно follow-up никакая переменная не должна иметь такого типа, но я не думаю, что это обсуждение завершено (и, по общему признанию, JLS еще не обеспечивает эту цель).

Обновление 2: Получив совет от автора спецификации, я вижу три части в конечном решении:

(1) Каждая подпись типа в любом атрибуте байткода должна придерживаться грамматики в JVMS 4.7.9.1. Ни ecj !, ни javac <captured wildcard> не является законным.

(2) Составители должны аппроксимировать сигнатуры типов, где нет юридического кодирования, например, используя стирание вместо захвата. Для записи LVTT такое приближение должно рассматриваться как законное.

(3) JLS должен гарантировать, что только типы, кодируемые с использованием JVMS 4.7.9.1, появляются в позициях, где генерация атрибута Signature является обязательной.

Для будущих версий элементов ecj (1) и (2) были разрешено. Я не могу говорить о графиках, когда javac и JLS будут исправлены соответственно.

Ответ 1

Последствия