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

[Henry Jen]

While I agree it’s better to specify a target package, this is not really about package, even if you have it, 
the Byte is defined in the same source code, and will be considered before java.lang.Byte.

Without fully qualified name, the clash is guaranteed. I like to see short names, but if we want to do that, we need to do it smarter and means we need to check for name clashes or provide a way to specify	name-mapping as we did for package.

Anyway, that’s why I have the exclude symbol, that’s what I have to work around Byte. But you can tell that I added the struct case then we still have issues.

Cheers,
Henry


> On Jun 12, 2019, at 6:28 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> 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/