RFR (JDK11): JDK-8195986: Incorrect javac -h output with annotation processing and missing classes

Jan Lahoda jan.lahoda at oracle.com
Wed Jun 27 16:16:22 UTC 2018


Hi,

javac tries to reuse ClassSymbol across annotation processing rounds, so 
that they don't need to be load multiple times from the classfiles.

But, in some cases (namely, when some of the ClassSymbols that were 
loaded from the classfiles depend on unknown class that may be generated 
by the annotation processor), javac clears all suspicious ClassSymbols, 
and recompletes them again. But it, currently, also sets new Types for 
all the cleared ClassSymbols.

This then leads to new types assigned to critical classes like 
j.l.String, which then leads to:
Symtab.stringType != Symtab.stringType.tsym.type

(because Symtab.stringType contains the very original type assigned to 
j.l.String, but Symtab.stringType.tsym.type is the one assigned in the 
last annotation processing round.)

This then misguides the JNIWriter to write a wrong native header, but 
could potentially lead to other problems as well.

I believe the need to set new types is for the case where the 
ClassSymbol's type is erroneous (and needs to be fixed back to 
ClassType), so the proposed patch is to only set new types for ERR 
ClassSymbols. (ClassTypes should be cleared to their pristine state in 
ClassSymbol.reset().)

An alternative fix would be to fix the JNIWriter to use 
Symtab.stringType.tsym for comparison instead of Symtab.stringType.

Webrev: http://cr.openjdk.java.net/~jlahoda/8195986/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8195986

Any feedback is welcome.

Thanks,
     Jan


More information about the compiler-dev mailing list