[foreign] RFR duplicates in named layouts have to be reported as error

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Mon May 28 12:32:50 UTC 2018


Here's a stab at the current approach; I started with your patch and 
tweaked in places.

http://cr.openjdk.java.net/~mcimadamore/panama/panama-binder-v3.html

I think the result is good; the problems you mention are resolved, and 
all use cases are supported.

Let me know what you think.

Maurizio


On 28/05/18 11:02, Maurizio Cimadamore wrote:
>
>
> On 28/05/18 09:37, Maurizio Cimadamore wrote:
>>
>>
>> On 28/05/18 07:39, Sundararajan Athijegannathan wrote:
>>> Isolated Structs will work if there are no name definitions or 
>>> references in its layout. If there are Unresolved name references in 
>>> its layout, then there has to be a 'context' in which the names are 
>>> defined/resolved. The context cannot be entire Java process as it 
>>> currently is! Two issues with the current code: 
>> I agree with all you say. The only thing I'm disagreeing with is the 
>> fact that the context has to be the @NativeHeader annotation, as that 
>> suggests an header-centric nature that was never intended to be part 
>> of the design.
>>
>> Other, more explicit ways to define the context include an explicit 
>> annotation which list all the classes where dependent layout can be 
>> found. I think I'd like something like this better. Example (names TBD):
>>
>> @NativeStruct("[$(b)](a)")
>> @Friends(B.class)
>> interface A {
>>     B b();
>> }
>>
>> @NativeStruct("[$(a)](b)")
>> @Friends(A.class)
>> interface B {
>>     A a();
>> }
> Now that I have expressed this more explicitly, another idea emerged - 
> what if we assumed that, if no annotation is provided, the context is 
> the outermost class? That will work neutrally with both struct and 
> header interfaces...
>
> Maurizio
>>
>>
>> Maurizio
>>
>>
>>
>



More information about the panama-dev mailing list