I have a library, that already uses a C++ version of gRPC, and I need to implement a Java wrapper.
Thus, I need to use Java Native Interface (JNI) to convert std::shared_ptr<grpc::Channel> to gRPC-Java Channel.
More specifically, I need to implement the following Java function:
public native ManagedChannel CreateChannel(String address);
that references this existing C++ function:
std::shared_ptr<grpc::Channel> CreateChannel(std::string address);
Is it possible to do this?
Possible? Yes. Easy? No.
The Channel/ManagedChannel API mainly has the newCall() method. Implementing that method would be annoying as you'd need to map MethodDescriptor and CallOptions to the C++ equivalents. But the bigger problem is it returns a ClientCall which would take more work to implement.
C++ uses a different API for flow control than Java, so you'd have to map those. The C++ callback API would be ideal in this situation, but it not currently available (time of writing: 2019 Q4). So that would mean creating threads and using the async API.
Very probably not. The Java implementation was not specifically designed to be interoperable with the C++ implementation, so it has its own pure Java ManagedChannel implementation.
Related
I'm working on rust right now because we want to switch to this technology. Today we only use c/c++. For me now the question arises, if it is possible to provide a library in rust, just like in c/c++. Of course I have seen several examples where rust library is called from c and vice versa. But my question aims at another use case. It is about an API that has a state and not just a stateless function. For example you would have to use an init function to create an object pointer which is returned to the caller. Any other function need this object pointer to provide the needed functions. I would be very surprised if this is not possible but unfortunately I have not found anything. In our Use Case we want to offer the API ( written in rust ) for c++, swing and Kotlin. Of course I know that I could also write this API in c/c++ but the use case relies on Rust for various reasons.
Thanks for your tips
Greeting
Dusan
Translated with www.DeepL.com/Translator (free version)
I have a SDK that will communicate with my Scanner device that is written in C++ language. I need to develop an Electron App that can access the Scanner device. I know there are many libraries available for scanner but I want to use this SDK since it will allow me to access full feature of the device and moreover it is provided by the device manufacturer. So, is there any way to implement this. Please suggest me any idea.
You can use the native V8 API for that. You will need to provide a layer over your C++ code and expose it as Javascript entities.
if there's also a C-style interface you could use node-ffi https://github.com/node-ffi/node-ffi
If you're using electron 3 (which in turn uses Node 10), you can use N-API which has great examples on how to wrap a C++ object into a JS object. N-API is stable and supported by Node 10, so it's a pretty good choice over NaN and node-addon-api for the long term.
https://nodejs.org/api/n-api.html
Here's a repository of examples that proves pretty useful. This one specifically is for wrapping C++ objects.
https://github.com/nodejs/abi-stable-node-addon-examples/tree/master/6_object_wrap/napi
I have a C++ app from which I want to call .NET (C#) methods. I was going to use C++/CLI, but it is only supported on Windows.
Since also we support the MAC, I'd like to call .NET from C++ in a way that will work on both Windows and Mac (with Mono).
What is the best way to do this?
EDIT: I should add that the c# code we wish to call is not ours. We have no way of making any changes to it. The c++ code, of course, is ours.
The easiest way is to expose the functionality via a function pointer. Both .Net and native code can interop with C/C++ code in the form of a function pointer. Function pointers are supported on all platforms where C++ code runs hence it can be written without any understanding of .Net.
Why do we need JNI to access the native when we can develop the entire application in JAVA.
Regards,
Sujanian
JNI is needed, when you can't develop the entire application in Java. This can happen for example, when there is a legacy library only available in C or when there is a need to communicate with a system driver. If you can write the whole application in pure Java, you of course don't need JNI.
When you can develop the whole application in pure Java, you do not need JNI. That is the preferred way, too.
However:
you may want to call into existing native code libraries. It may be possible to rewrite them in Java, but that could be a lot of work (in the port and in maintaining two versions later on)
you may need to write some low-level code to talk to the hardware/OS directly in ways that the JVM does not let you
Why do we need JNI to access the native when we can develop the entire
application in JAVA.
If by this you are asserting that you can always develop the entire application in Java, you are incorrect. You can't always do that, and JNI is there to cover the gap.
If on the other hand you mean 'if' instead of 'when', the answer is that you don't need JNI in those cases.
We have an old application which has a FORTRAN API to be called from other applications. After some time they built a ( C ) wrapper for the FORTRAN API.Then I'm now building a c++ wrapper , with a little data handling , for the C API.
So I'm thinking what is the best way of building an API that can be called from any programming language.
Now I'm planning to bulde RPC server from my c++ API. Then any client using any programming language can call it.
I found that the XML-RPC is a good one. But it needs HTTP server for connection.
The problem is that the applications that call our API are desktop applications.And I found that XML-RPC can not manipulate complex objects.
Is SOAP a good solution? Can the client side be easily implemented?
So what is the best technical solution for my situation? Which technology should I use?
comment: I do not have a permission for changing the Fortran API and the C API. And I need the c++ API because I'm adding to it new methods , and enhancing the code so the user can call the methods easily.
Best Regards,
The best way is to leave it alone and just use the C API. virtually all programming languages can directly call a C API, so there's no reason to create wrappers unless a particular language's programming model makes more sense a different way.
To clarify what I mean, look at GTK+. It is a C API and is usable in virtually any language. Wrappers exist in object-oriented languages that provide a pure-OOP approach to the GTK+ API because it makes sense for those languages, given the domain of the API.
Does an objectified interface make sense for your application? If not, there is no reason to bother making a C++ wrapper.
As to RPC, why doesn't a simple message-passing interface with shared memory suffice?
Any decent language has a foreign function API. Just call the Fortran functions directly. The compiler documentation will tell you how - calling Fortran in a shared library is very similar to calling C in a shared library, except different compliers may normalise the function names to lower case or not, or may add an underscore. Some FFIs may require some C wrapper code - Java for example - but many can just take a function name and parameter types and the name of the library to load.
Failing that, you can implement a streaming interface to the Fortran (read and write to standard output) and just pipe input to and from it - I've done that when quickly porting interactive ISPF Fortran applications to PC.
Since you want to expose the C++ API and extensions rather than the Fortran API, then look at SWIG, which automates the process for a variety of languages, as long as the C++ isn't too complicated.
SOAP, XML-RPC ect are normally used for computer to computer communication, is this what you want? Or is this all just running on one comuputer?
If it's just on one computer, just stick with C API, most systems can use that
If you model the C API as a REST style service, then you can also provide a HTTP service for applications that can't use the C API without, but only have one system to document