[foreign] RFR: simplify implementation classes

[Samuel Audet]

On 05/29/2018 09:07 PM, Maurizio Cimadamore wrote:
> On 29/05/18 06:18, Samuel Audet wrote:
>> That's an interesting restriction indeed. I must admit I have never 
>> read that document from start to finish. :) Thanks for the link!
>>
>> If Panama can eventually support enough C++ such that we don't need 
>> any boilerplate wrappers and this gets fixed, then I think we're good.
>>
>> But in the event this doesn't happen, there should be an easy 
>> (standard) way to get classes that need JNI loaded by the system class 
>> loader. Is there an existing standard practice for this right now? All 
>> I can find are workarounds whose procedures vary from framework to 
>> framework...
> Not sure if we can call it standard practice, but many of the approaches 
> I've come across so far reach out to dlopen directly, bypassing the VM. 
> Panama was doing this (with its library loader), JNR is also doing 
> something similar:
> 
> https://github.com/jnr/jffi/blob/master/src/main/java/com/kenai/jffi/Library.java#L151 

This still doesn't solve the issue about how to get JNR itself loaded by 
the system class loader. Do people just put it in /path/to/jdk/lib and 
forget about it? I'm pretty sure that's not recommended by Oracle...

> Now, one of the benefits of getting C interop right is that we could 
> start experimenting at defining some Panama Posix interfaces; if we get 
> there, it will be easier for (expert) developers to explicitly handle 
> library life-cycle according to the needs of their application.

FWIW, I'm not convinced that POSIX is still relevant. Windows still 
doesn't even have dlfcn.h, etc. I'm sorry I have to say this one more 
time, but I really think we should be looking at LLVM and C++ instead...

Samuel