[foreign] rethinking Panama annotations

[Sundararajan Athijegannathan]

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.

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

* 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); }

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