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