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

[Samuel Audet]

Hi, Maurizio,

Could you elaborate on the use cases where using something like the 
SystemABI interface without the binder or annotated classes would be 
desirable? In particular, I'm interested to know under which 
circumstances an *end user* might be interested by those details. 
Specifically, JShell supports annotations just fine, so that's not a 
good reason. The following works with JavaCPP, and I'm sure we can do 
something similar with your binder:

$ /path/to/jshell --class-path /path/to/javacpp.jar
jshell> import org.bytedeco.javacpp.*;
jshell> import org.bytedeco.javacpp.annotation.*;
jshell> import org.bytedeco.javacpp.tools.*;
jshell> @Platform(include = "unistd.h") class Dummy { public static 
native int getpid(); }
jshell> new 
Builder().classesOrPackages(Dummy.class.getName()).outputDirectory("/tmp").build();
jshell> System.load("/tmp/libjniDummy.so")
jshell> Dummy.getpid()
$12 ==> 5217

We could easily make this cleaner too, see for example suggestions from 
Cyprien Noel (added in Cc) in this pull request:
https://github.com/bytedeco/javacpp/pull/138
The point is, I don't see any usability issues, but do you?

Samuel

On 11/28/2018 11:00 PM, Maurizio Cimadamore wrote:
> Hi,
> I took the patch at [1] for a spin with jshell. I wanted to see how easy 
> it was to call native functions using the SystemABI interface - e.g. w/o 
> binder and annotated interface. I think I'm pleasantly impressed! I did 
> some changes to the proposed patch as I wanted to put everything 
> SystemABI-specific in a public package (java.foreign) and I also added a 
> method on UpcallHandle to get a pointer. But overall these were minor 
> modification, mostly in order to be able to use this setup on jshell. 
> But let's dive on some code.
>