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

[Vicente Romero]

looks good,
Vicente

On 06/27/2018 12:16 PM, Jan Lahoda wrote:
> 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