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

[Maurizio Cimadamore]

On 12/06/2019 11:40, Sundararajan Athijegannathan wrote:
> The "no target package" situation is bad. Should we force 
> specification of a package always or assume/derive target package from 
> input(s)?

What about assuming hat target package is "jextract", if none is 
specified? This will lead to package hierarchies like

jextract.usr.include....

Maurizio

>
> -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/