notes on binding C++

[Samuel Audet]

Thank you all for your input! I am glad to hear that issues are being 
addressed and that feedback is welcome. :)

To put things into perspective, my main "pain point" is not about 
performance at all. JNI is already pretty fast and more functional than 
the alternatives available for Python or C#. It is not currently 
possible to come up with something as usable as JavaCPP with either of 
those, or even with Go or Rust, despite all the hype. Certainly, faster 
JNI is welcome, so I am happy to hear about optimization potentially 
happening on that front. (Thanks Vladimir!)

No, the main issue I am facing with JavaCPP is one of acceptance. What I 
am basically trying to come up with are native packages for Java. In the 
Linux world, everyone understands the usefulness of RPMs or DEBs, and 
similarly with Maven for Java libraries, but for reasons that are still 
unclear to me Java developers do not value the same kind of packaging 
system for native libraries. (Maybe because they are "unsafe" and 
frowned upon? Though that should be changing now with all the hype 
surrounding deep learning...) OpenCV from /Intel/ and TensorFlow from 
/Google/ both came up with bindings for Java that appeared after the 
ones for JavaCPP, that are slower, less feature-complete, and 
interoperate only with difficulty with each other, but people still use 
them in preference because they are "official"... So, you see, coming up 
with something that is faster, has more features, etc than JNI just for 
the sake of it will not help much in my opinion. JNI is already there. 
More people still use JNA than JavaCPP or JNR /combined/, even though 
JNA is unbearably slow and unsafe, and does not even try to support C++. 
The way I see it, having the Java from /Oracle/ brand behind it is what 
counts, but it would be nice if something actually revolutionary comes 
out of it!

And this is where I see using Clang/LLVM as having the best chance of 
success. To answer Henry's question, Microsoft already uses Clang in 
their products, Visual Studio already supports Clang as a compiler, they 
might even add an LLVM backend to their C/C++ compiler, and if that 
happens, LLVM will have effectively become the reference C++ runtime, 
such that we could just compile the IR to bytecode and we are done! Even 
if that does not happen, there are more people interested in translating 
x86 code (generated by MSVC, etc) to LLVM IR rather than directly to 
bytecode, thus enlarging the pool of limited resources (that Maurizio is 
referring to) that can work on these tasks. Clang already implements 
things like NativeInvoker and UpcallInvoker that work with C++ 
(including exception handling), which is what is needed for tools like 
JavaCPP. I am satisfied that at least one or two others are interested 
in an FFI using Clang and are actually working on it, so I will leave it 
at that for now. I already have too much to do with JavaCPP, and JNI is 
not the problem. Well, if scoped MemoryRegion and data layout 
descriptions could be made to work with JNI in some special optimized 
way too, that would be great. This is something that I see being picked 
up right away by others (OpenCV, TensorFlow, etc), in addition to 
JavaCPP (and by extension Deeplearning4j from Skymind).

Samuel


On 02/10/2018 01:38 AM, Bernard Traversat wrote:
> Samuel,
> 
> We welcome contributions specially on a complex project like Panama.  The team is currently experimenting with C interoperability.  We don’t want to stop there and we will be looking to support C++.  Clearly, we want to leverage the work you have done on JavaCPP. There is lot for us us to learn and collaborate on.
> 
> Cheers,
> 
> B.
> 
>> On Feb 7, 2018, at 7:44 PM, Samuel Audet <samuel.audet at gmail.com> wrote:
>>
>> On 02/06/2018 08:19 PM, Maurizio Cimadamore wrote:
>>> On 06/02/18 07:52, Samuel Audet wrote:
>>>> That sounds great and all, but it has been almost 4 years now, and the only feedback I am getting is that it does not yet support function-like macros, inline functions, C++ templates, etc. Ok, then, when? Why is a "limited amount of wrappers" taking so long?
>>> Hi Samuel,
>>> I think I've already responded to similar questions many times now, and I feel we're just going in circles; I sense your frustration, but unfortunately I do not have anything more to add to this discussion. I've told you what the focus is short/medium term (C interop), and what is the _rough_ plan after that. If that is not sufficient, or if you feel that we just got all the priorities wrong, or if you think we're just too slow, I'm sorry, but I don't think those kinds of concerns are of the kind that can be positively addressed over an email exchange.
>>
>> I am sorry, I think that came out the wrong way. What I was trying to say is that supporting C++ and making it as super efficient as you want it to be is a *very hard problem*, and you will require assistance from a lot of people--from outside Oracle--to pull this off. I am trying to make you realize that, and yes I am frustrated that I am unable to communicate this, even after almost 4 years...
>>
>> To make this conversation constructive, though, I am also trying to make suggestions, such as, why not use Clang? What is wrong with Clang? You already use it for jextract, and Graal already supports LLVM. Plus, people from Oracle Labs have already started work in this direction:
>> Bringing Low-Level Languages to the JVM: Efficient Execution of LLVM IR on Truffle (see "4. Native Calls and Memory Management")
>> http://ssw.jku.at/General/Staff/ManuelRigger/VMIL16.pdf
>> Is something like this going to be integrated into Panama?
>>
>> Another constructive comment I would like to make is, would it be possible to release all the relevant documents about jextract and Panama so that people outside of Oracle could participate and make this a community effort? If you need more data to convince managers that this is required in order for this project to succeed, I can help with that! However, as I mentioned previously, I feel that my help (or the help from any outsiders for that matter) is not welcome here. It would be great if this state of affairs could be improved! (This might be for you, Bernard?)
>>
>> Samuel
>