[foreign] RFR 8208199: Revisit one interface per header file approach

[Sundararajan Athijegannathan]

Yes, good catch! That should be removed. i.e., NativeHeader should be 
enforced for all interfaces transitively.

-Sundar

On 08/08/18, 6:43 PM, Maurizio Cimadamore wrote:
> Some binder comments too (related to the changes in HeadeImplGenerator)
>
> 1) are we expecting a header interface to implement something other 
> than another header interface?
>
> 2) isn't there a bug lurking here? Suppose I do 
> Libraries.bind(String.class), now, there's no NativeHeader in here, so 
> that will just 'do nothing' ? (as opposed to e.g. fail with exception)
>
> Maurizio
>
>
> On 08/08/18 14:06, Maurizio Cimadamore wrote:
>>
>>
>> On 08/08/18 13:25, Sundararajan Athijegannathan wrote:
>>>   May I suggest that we go with the current scheme (which is minimal 
>>> changes) and revisit based on use-cases? 
>> While I'm fine with the changes, and I agree that they are 'minimal', 
>> I'm also worried that they add a new design dimension that is not 
>> fully explored. Some of the issues with the approach are the lack of 
>> granularity in specifying the set of headers to be 'followed', as 
>> well as the fact that this new multi-header mode completely 
>> invalidates the assumptions of unresolved layout resolution - the 
>> assumption there was that any layout mentioned in a class C could be 
>> resolvable by looking at the outermost enclosing class of C (**).
>>
>> My feeling is that we have both missing metadata and missing jextract 
>> options here.
>>
>> (**) Consider this example:
>>
>> //a.h
>> import "b.h"
>>
>> void fn(struct S);
>>
>> //b.h
>> struct S { int i; };
>>
>> If you extract this with jextract, you get two headers, one for 'a' 
>> and one for 'b'. The function descriptor for 'fn', which is in 
>> 'a.class' will refer to the layout of S, which is in B.class. With 
>> your patch, a.class will also 'implement' b.class. Here, the resolver 
>> for a.class knows nothing about S. The only way to support this 
>> resolution is via ad-hoc prescanning of all classes in the signatures 
>> of a.class (which we currently do, but it's a mouthful, design-wise).
>>
>> My hope here is to come up with a mechanism to specify related 
>> headers both from a point of view of jextract flag (e.g. so that 
>> jextract will follow headers), but also in a way so that the 
>> information about the header relationship is preserved at runtime 
>> into some metadata; that way, the information can be used to perform 
>> layout resolution in a precise and well-defined way.
>>
>> While this patch defines no additional metadata, one could argue that 
>> the injected subtyping relationship it provides is, itself, some form 
>> of metadata we could exploit during resolution. And, using 
>> inheritance has the obvious advantage of exposing a model that 'makes 
>> sense' for Java users.
>>
>> With all these things in mind, let's give this code a try - and see 
>> if we can fit a story for better layout resolution on top of it.
>>
>> Cheers
>> Maurizio
>>
>>
>