[foreign] RFR: 8225552: typedef can interfere with primitive classes

[Sundararajan Athijegannathan]

The "no target package" situation is bad. Should we force specification 
of a package always or assume/derive target package from input(s)?

-Sundar

On 12/06/19, 3:34 PM, Maurizio Cimadamore wrote:
> The filtering looks good.
>
> I'm less sure about using qualified names always - what is the extra 
> benefit of using 'java.lang.String' ?
>
> My reading of the test suggests that:
>
> 1) if the user has specified a target package, then there is no clash 
> problems - as long as the jextract-generated types are all fully 
> qualified, there shouldn't be clashes with symbols in 
> java.lang/java.foreign
>
> 2) If there's no target package and jextract symbols are generated in 
> the unnamed package, then you can have an issue, because one can 
> "redefine" String.
>
> I think my preference would be to emit fully qualified names only when 
> necessary - e.g. in (2). Can we check whether we have a target package 
> set, and act accordingly?
>
> Cheers
> Maurizio
>
> On 11/06/2019 19:23, Henry Jen wrote:
>> Hi,
>>
>> Please review another trivial patch[1] that use fully qualified class 
>> to avoid wrong type reference.
>>
>> In this patch, I also entertain a small change to allow 
>> —exclude-symbols to filter out typedef, which are generated as type 
>> annotation. There is not good reason why we cannot filter out those 
>> if so is user wanted.
>>
>> [1] http://cr.openjdk.java.net/~henryjen/panama/8225552/0/webrev/