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

[Samuel Audet]

Hi, thanks for the quick feedback!

There needs to be some sort of internal mechanics, that's fine, but 
whatever it is is not as relevant as what is going to get exposed to 
users. If the idea is to expose something like SystemABI to users of the 
JDK as implied in your reply, I'm not sure that's a good idea. Operating 
systems expose functions like dlopen(), etc, but C/C++ users simply cast 
those pointers to functions, and just call them! In fact, there are no 
standard ways to start enumerating parameters and set calling 
conventions at runtime before using them. So, in my opinion, Java 
doesn't need that either. JavaCPP could, in theory, be built on what the 
binder already provides. 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...

Samuel

On 12/02/2018 06:39 AM, Maurizio Cimadamore wrote:
> 
> On 01/12/2018 10:39, Samuel Audet wrote:
>> 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:
> 
> Sure - the use case I was envisioning is not for end users; of course 
> users will want higher level frameworks. But those frameworks have to be 
> built on something, and I think the proposed SystemABI interface seems 
> to  have the right set of primitives upon which to build.
> 
> When I was preparing some demo for the talks I gave few weeks ago I also 
> played with jextract and annotated interfaces and yes that works just 
> fine. Really, the use of jshell in my example was not the important part 
> - I was mostly trying to see how usable the SystemABI was. Clients for 
> that API are the binder, and could be rich frameworks such as JNR and 
> JavaCPP. I'm assuming that *not* having to have to spin annotated 
> interfaces in order to be able to play with the Panama backend can be a 
> feature in such instances.
> 
> Maurizio
> 
>>
>> $ /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.
>>>