[foreign] rethinking Panama annotations

[Maurizio Cimadamore]

On 22/11/2018 03:23, Sundararajan Athijegannathan wrote:
> The new proposal looks good!
>
> Apart from fixing the 2^16 constant pool limitation, I like the 
> proposed scheme:
>
> * NativeFunction can have additional metadata as well - for eg. if we 
> want to rename a native function (say to satisfy general Java naming 
> scheme for methods), we can include native symbol as additional property.
I think in my proposal I suggest to use function layout annotations to 
that end; using another annotation atttribute is of course a possibility 
- but since for globals we use layout annotations...
>
> * Annotations are closer to the actual entity being annotated
>
> * And class file size is reduced!
>
> Comments:
>
> * Can we infer name for NativeSetter, NativeGetter, NativeAddressOf? 
> i.e., if name is not specified, pick it from method name pattern? Just 
> to reduce verbosity for hand-written struct declaration.
We *could* but I think we *shouldn't*. Hardwiring a name convention in 
the binder seems wrong.
>
> * For callbacks, can we have this? One less annotation :) A callback 
> is a FunctionalInterface with special annotation on the lone abstract 
> method..
>
> @FunctionalInterfacestaticinterfacevisitor { @NativeFunction(desc = 
> "(i32)v") publicvoidfn(inti); }

That is more or less what I ended up proposing, see example in the end 
of the document. The @Functionalnterface on top doesn't buy much (the 
binder would still have to look for the abstract annotated method), so I 
left that as optional.

Maurizio

>
> -Sundar
>
> On 20/11/18, 7:03 AM, Maurizio Cimadamore wrote:
>> Hi,
>> I put together a writeup which captures our current thinking w.r.t. 
>> Panama annotations; the document outlines a possible way to replace 
>> the current system of toplevel annotations with a leaner system of 
>> member annotations.
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/panama-annos.html
>>
>> Comments welcome.
>>
>> Cheers
>> Maurizio
>>