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

[Maurizio Cimadamore]

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