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

[Sundararajan Athijegannathan]

I thought about this a bit more.  We have NativeHeader annotation that 
mentions a header path + declarations (it is called "NativeHeader" and 
not "NativeHeaders"). If we combine declarations from multiple header 
files, this annotation won't be accurate. Yes, NativeLocation does 
mention file - but that annotation is considered optional and it is 
considered as "debug info".

Also there is an outside chance of reaching per .class limitations when 
processing a deeply nested header file (if we fold all declarations in 
one interface).  May I suggest that we go with the current scheme (which 
is minimal changes) and revisit based on use-cases?

Updated webrev: 
http://cr.openjdk.java.net/~sundar/8208199/webrev.01/index.html

Change: Folded ConstantArray, IncompleteArray cases in HeaderFile.java

Thanks,
-Sundar


On 03/08/18, 9:56 PM, Maurizio Cimadamore wrote:
> I agree we need something to treat 'related' header files in a more 
> cohesive fashion.
>
> I've also recently stumbled onto a similar issue with the clang 
> Index.h header, which is importing few associated header such as 
> CXString.h - defining types which virtually ought to belong to the 
> same namespace.
>
> That said, I'm not sure using inheritance is the best way to provide 
> such coupling. An alternative would be, for instance, to simply 
> recursively add external header definitions into the main header (the 
> one importing them). For some reason, something like this would seem 
> more in spirit with C - where importing an header really amounts at 
> adding the imported definitions on the importee.
>
> I also think that we should provide some mechanism to control this 
> merging behavior; privately I've suggested an option 'follow-includes' 
> which takes a path (or a list of paths), and which allows to follow 
> headers onto specific folders. An option like this would be useful to 
> deal with what Henry set out to do yesterday - e.g. allow jextract to 
> recursively process headers in system libraries.
>
> So, in conclusion, I'm not opposed with the effort, but I'm not sure 
> we have found the right stacking yet.
>
> Maurizio
>
>
> On 03/08/18 15:07, Sundararajan Athijegannathan wrote:
>> Please review.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8208199
>> Webrev: http://cr.openjdk.java.net/~sundar/8208199/webrev.00/index.html
>>
>> Thanks,
>> -Sundar
>