Looking at Thrift and Google Protocol Buffers to implement some quick RPC code. Thrift would be perfect if the generated C++ code compiled on windows (which is what I need). And of course, GPB creates RPC stubs, but no implementation.
Is there a way to get Thrift Windows friendly? Or, even better, are there any RPC implementations available freely for generated C++ protobuf stubs (a Java counterpart would be nice too, but is not necessary).
Thanks
Try Zeroc ICE
Is there a way to get Thrift Windows friendly?
According to this page on the Thrift wiki, it is not possible.
The following instructions are for making the thrift compiler only. The Thrift C++ runtime library does not currently work on Windows. This means that you'll be able to compile ThriftIDL files to C++/Java/Python/etc., but you won't be able to compile and run the generated C++ code under Windows.
You can installing thrift following this "guide".
Look also at my solution at the bottom, to let it works on windows.
Related
I have somoe C# source code that I want to be available for java applications under linux OS.
How can I call some C# method from java code?
I have found http://www.mono-project.com/Java but this looks like writing java code in .net environment. It is not what I look for. Rather I need to create new java library that will expose all functionality from C# code, the new library must be executed in pure java environment. Maybe that is possible with IKVM I am not sure.
Use Mono to compile your C# classes on the Linux platform of your choice;
Use JNI to write a set of facade classes between your java code and the compiled C# code.
The closest tool I can find that might be useful would be JNI4Net
I think you would still need Mono to run a .net framework on Linux as well.
Your question is going to be closed (I voted too) simply because it would finally lead to a tool recommendation.
Your best approach is to rewrite them in Java. Or alternatively, there are existing tools (commercial or free) to convert C# to Java,
CSharpJavaMerger Framework
RemObjects C# who compiles C# to JVM.
and many others
Mono is not something you should consider at this moment. Yes, IKVM.NET only helps running Java code on Mono/.NET, and it won't help you in your case.
It's not clear if you can execute the c# project or not through mono, if you can, then process intercomunication is the way to go.
If you are doing it in Linux I should use a pipe channeling to intercomunicate both processes, works really well and is easy to use.
If you can't execute the c# process, then that's another history, you cannot call directly a .net assembly from java.
And also, using mono on Linux per today gives great results (except for ASP .net), we are using it and are getting really good results (faster responses than Java in most scenarios).
I'm afraid the answer to my question is no, but I'm asking it anyway just in case.
What I would like to do is stream audio from a chrome browser to a server written in Java via WebRTC. My understanding is that to accomplish this I need a Java implementation of peerconnection. All I've found so far is the libjingle Java API for android but that hasn't been particularly useful for integrating into my server app (I'd prefer an actual Java implementation, not just a C++ wrapper).
If a library to do what I want really doesn't exist does anyone have any pointers for how I might approach actually implementing the WebRTC spec myself? When I look at such a large spec I don't really know where to start.
You can use IceLink. We (I helped develop it) wrote a Java implementation for it, as well as .NET and Objective C.
This is a complete Java WebRTC signal server written with Java i/o sockets. https://code.google.com/p/jfraggws/ Just make a project, include the .Java file and include rt.jar in the project. Next set the port on the Html 5 client and plug in your servers IP. You now have java webrtc.
I'm looking for a way to implement RPC between Java and C. What are the options to do this?
Best Wishes
p.s I have web java application which is hosted on Glassfish server and C daemon. I need to directly call functions from bought sides.
The whole point of RPC is to let two opaque processes on different systems talk to each other over a network. The languages used are irrelevant, except that you have to learn the corresponding RPC libraries for both languages.
Google Protocol Buffers address some of the difficulties with serialization, and provide a "RPC service" abstraction. You'll need to implement the "remote" part -- sending the data across, etc. -- but it'll give you cross-language compatible serialization.
The Google implementation doesn't natively support C -- only C++ -- but it looks like C is one of the languages for which there is an add-on.
Another option is the open source "thrift" library (originally from facebook). It also supports generating local stubs in a multiple of languages. Though I suspect the protocol buffer library as suggested by #Louis Wasserman is higher quality than thrift.
There are couple of java libraries implementing oncrpc:
http://code.google.com/p/nio-jrpc/ and
http://sourceforge.net/apps/trac/remotetea/wiki/WikiStart.
We need to use a Java library from C++ code. An idea that I had is that if we could build a C++ client for Java RMI (ideally using some framework or wizard), than we could run the Java lib as a separate server. This seem cleaner than trying to run Java VM within a C++ application.
Alternatively, if you have any other idea on how to use Java from C++, I'd be glad to hear. We work on Linux.
thanks a lot,
David
RMI is intimately linked with the JVM (and Java serialisation), so that isn't reasonable. Not unless the C++ client includes a JVM.
CORBA is the obvious platform-independent equivalent. It is a bit design-by-committee and is now considered very untrendy. WS-/JAX-WS is kind of the modern equivalent with lots of XML, but may be considered a bad attempt at CORBA. REST is an attempt at a lightweight WS-, but see Joel's Stackoverflow DevDay rant on claimed "simplicity".
You could go old school and just shove byte over TCP/IP (or pipes). Or if local, just exec the C++ program. Or use a native interface: JNI built into the JRE, or JNA a nicer layer over the top.
Don't bother with RMI. If you're willing to take the step of making the Java application a separate server, have your C++ client communicate via JMS (Java Messaging Service). ActiveMQ is a free JMS message broker implementation that provides embedded services as well as C++ client libraries. The JMS protocol is dead simple to use (at least from Java). Its probably not as flexible as doing REST, but it would likely be an easier implementation.
JNI was the intended solution to the problem of C/C++ to Java integration. It's not difficult.
Message Queues are better for larger grained interactions, or remote interactions where the message queue is accessible over the network.
CORBA and RMI were also intended to be network access mechanisms.
From your description you don't want that. You want to consume a Java library in C++, and to do that, you use JNI.
How to start the JVM and invoke a Java method, from C++ (JDK doc)
I'm wondering if a Java library can be called from a VB.net application.
(A Google search turns up lots of shady answers, but nothing definitive)
No, you can't. Unless you are willing to use some "J#" libraries (which is not nearly the same as Java) or IKVM which is a Java implementation that runs on top of .NET, but as their documentation says:
IKVM.OpenJDK.ClassLibrary.dll: compiled version of the Java class libraries derived from the OpenJDK class library with some parts filled in with code from GNU Classpath and IcedTea, plus some additional IKVM.NET specific code.
So it's not the real deal.
I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.
You can call Java from .NET if you wrap it in some form to make it accessable and the easiest way is typically to use a Runtime bridge like
http://www.jnbridge.com/
Other way is to wrap your API with java webservices.
check this also http://www.devx.com/interop/Article/19945
Nothing out of the box.
Most java/.net interop that I know uses web services.
If you can create COM components with Java, you can use tlbimp to create an interop assembly for using in VB.Net.
If can create standard DLLs that can be used from C++ with Java, you can write P/Invoke declarations and call them from VB.Net.
If you can create a web service with Java, you can generate proxy class from the WSDL and call it from VB.Net.
In any case, chances are the Java component will live in a separate process. I doubt you can load both the Java VM and the CLR in the same process.
If you have the source code and compile it using the J# compiler, then the answer is yes. If you want to call any pre-Java 2 (aka 1.2) libraries, then these are included pretty much verbatim with J#. More recent stuff is going to be tricky though (i.e., it's not there).
An example where this is used commercially are the yFiles graph layout algorithms from yWorks. These were originally just a Java library, but for the past few years they've been offering a .NET version, which is just the Java version compiled with Visual J#.
It's not without problems, and there are some limitations that you can't get around, but it can be done. So... unfortunately this answer looks pretty shady as well.
You could use JNI to instantiate a virtual machine and then use Java Classes. It will be some fun, though, because you would need to use C++ as a bridge between VB.Net and Java.
This article in java world has a quick tutorial on how to use Java from C++ and viceversa.
http://www.javaworld.com/javaworld/javatips/jw-javatip17.html
If you have the source, Visual Studio will let you convert Java code into c#.