[foreign] programmatic access to native libraries w/o binder

[Maurizio Cimadamore]

On 02/12/2018 02:27, Samuel Audet wrote:
> It doesn't make things any simpler than JNI, mind you, but I don't see 
> how having access to SystemABI would help either, at least at the 
> moment... 

Since JavaCPP uses concrete classes and native methods to embed native 
functionalities, yes, I can see that it would be hard to use the entry 
points in SystemABI in a meaningful way. Other frameworks such as JBR 
don't do this early binding to JNI - in such cases I believe that the 
internal implementation spun by these frameworks can take great 
advantage in having a blessed SystemABI which takes care of doing the 
blunt work in the fastest possible way; in fact, most of these 
frameworks had to write their own ABI impl (e.g. JNR is based on libffi).

I'd say that anything that spins classfiles at runtime would find this 
API useful; JavaCPP is not doing that, so of course there's no obvious 
benefit. Of course, if one day JavaCPP was rewritten to take advantage 
of the Panama backend stuff, then you will quickly run into cases where 
you'd just want to grab a method handle to call a given native function 
that is known to be there (e.g. one of those generated by JavaCPP 
itself). And, I think that in such cases, enforcing access through a 
Panama annotated interface is overly restrictive (and likely require 
costly bytecode spinning). Your framework would know what to do, what 
native types are involved etc - so you can just specify all these info 
and get the MethodHandle that will allow you to access the native 
function as quickly and with as less overhead as possible.

That said, this discussion is very abstract, given that, as said, 
JavaCPP does not currently work in this way - e.g. it has little need 
for bytecode spinning. So, at this point in time, SystemABI is, for you, 
just something to keep in mind in case you decide to change things later 
down the road.

Maurizio