notes on binding C++

Fri Feb 23 17:12:34 UTC 2018

Hi guys,

things are moving right direction, nice reading!

I will add here more offtopic solution not solving our use cases, but also
interesting approach to include C execution in Java apps, as its all about
breaking the bridge in any way and stay high performance:
https://mihosoft.eu/?p=1345

This one is completely on the fly :-) I like that.

Ladislav

Have a good weekend.

2018-02-12 15:56 GMT+01:00 Samuel Audet <samuel.audet at gmail.com>:

> 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
>>>
>>
>>
>