This may be a bit of an odd question, but I would like to know if you can use Java inside c++14. I don't really care for GTK (I find it confusing and over complicated). Swing, however, is very easy to use, and you can get a working project very quickly. So I would like to know if you can use Java Swing inside c++, so I can use Swing as the foreground, as in what you see like graphics, and use c++ for the background, as in stuff you cant see, like calculations and objects and stuff. So if I can have c++ code tell Swing what to look like, or when to update, that would be very useful for the project I have in mind. Thanks in advance for any advice I may receive.
EDIT: Being able to use c++14 inside Java would be acceptable as well. Also, if anyone could get me example code also, this would be very helpful. Thanks!
You shouldn't run Java from C++, but rather C++ from Java. Oracle gives you a way to load native shared libraries, using JNI.
So you would create your view in Java, using Swing, then you would update your view by calling C++ functions that were pre-compiled and exported in a shared library.
That said, using JNI is quite tricky and the speed improvements of C++ might not be worth it; so you should consider using only Java (or only C++ and a library to create your GUI, such as Qt)
In which direction you go is a matter of taste (loading the JVM from a C++ program or loading DLLs from the JVM side).
Usually you go the way which is more logical, e.g. if you already have a C++ program you likely want to load the JVM from the C++ side. That would be your case. Especially if the Java you want to add is essentially "scripting" the C++ application.
If you already have a Java program and want to access a C++ DLL, you load the DLL from Java and write a simple JNI / native Java class.
In our times you would use tools like JNA for that (instead of JNI): https://github.com/java-native-access/jna
Or you can use SWIG to generate wrappers for your C++ classes: http://www.swig.org/
Related
I have a compiler for a domain specific language that outputs a .net dll (that can then be used to do whatever the DSL said it should). It works well under .net but now I need to make the compiled dll functionality accessible from Java. The interface changes depending on the DSL, much like it would if I was implementing an F# type provider.
Ideally, I would like something along the lines of Reflection.Emit except that it would generate Java bytecode. It is important that the end-user can debug their Java code that uses my generated library from a Java GUI, so I don't think I can just use IKVM to instead include the Java code in .net. I also cannot use a commercial product such as JNBridge because all the users would need to install it, and call it every time their DSL code changes.
Is there a better solution than generating a .java file in text format and compiling it with a Java compiler? The .java file would just be a light-weight interface talking to the .net dll over some IPC mechanism (perhaps a named pipe), and its purpose would be to provide a typesafe interface similar to what would be seen from a .net application (except with indexers, getters, setters, overloads, etc replaced with some sort of horribly verbose syntax). Many thanks.
Java native interface is a way to call native code from Java (That dll isn't running on the JVM, thats for sure). Throw your dreams of "Write once run anywhere" in the bin now.
If you want to use dlls then you have to use JNI (or something similar or based on JNI like jni4net). It's not as pleasant as say, using c++ from c#, but it's pretty doable and far and away the best way to use dlls from java (I think the second best is re-writing the native code).
Alternatively you could run a windows process alongside your java app and soap/json/namedpipes/etc between the two, is that what you suggest in the last paragraph?
This would be odd for a small solution, but for a larger modular project it's not so crazy. I would recommend using sockets to communicate between the two, because I think sockets are easiest. It says client/server in the example, but it could be two processes (java and f#). ... This causes problems for performance, synchronisation, firewalls etc.. ahhh, just use JNI.
I have a Java GUI application that has been interacting quite nicely with a standard C++ based DLL on the back end via SWIG-generated files. The back end program is currently a combination of C++ and managed C++/CLI. The problem is that we may eventually port all of it to C++/CLI.
Please correct me if I'm wrong, but from what I've been able to tell, SWIG currently doesn't work with C++/CLI and there are no plans to make it do so. I imagine that I could do write JNI code to make it work. But using SWIG was a whole lot easier. So what other options are there? The simpler to use, the better.
It is not correct to say that SWIG won't work with C++/CLI... You should be able to use the generated interop stubs exactly the same way you did. I didn't encounter a scenario where switching on the CLR support broke existing well formed C++ code...
I'm trying to make a program like AutoHotKey, but with a graphical interface.
I'm using java.awt.Robot
Now I want to make the code for checking the state from a key (In AHK: getKeyState)
Of course somthing like a KeyListener without having focus.
I read already something with JNI and C++, but....
I can't find some information.
Can somebody help me??
There are lot of good JNI resources for starting out with JNI Programming like the Sun JNI Tutorial. Almost all Tutorials assume a good knowledge of C/C++ because the Java Native Interface (JNI) is the bridge between native C/C++ code, the Java Virtual Machine and everything running in there (meaning your Java Bytecode).
What you may want to do first is to find a key capturing library for your operating system of choice (you didn't mention anything specific here) in C++ and try that out as well as checking if there are already some Java bindings (libraries that use JNI and offer Java classes) to interact with. I didn't find any promising on a quick search unfortunately.
works perfect for windows 32/64 Bit. It's not necessary to integrate the dll files into the (eclipse)workspace / deployment process. Amazing Lib:
Hot stuff!
http://ksquared.de/blog/2011/07/java-global-system-hook/
Is there a way to call STL libraries from JNI, I believe JNI provides a C like interface for native calls, how do we achieve this for the C++ template libraries?
I agree that if you're looking for just the plain STL, you could probably use a Java library instead. However, if you insist on wrapping STL, SWIG provides some STL wrapping in JNI out of the box (see this for the basic mechanism), which should produce relatively stable, tested code.
I know this is possible, although I haven't done it myself. But JNI code can crash the JVM if you are not VERY CAREFUL. Also, JNI code is much more difficult to maintain than Java code. I was on one project where the Java -> JNI -> STL and COM code was thrown away and we replaced it with C# accessing the same STL and COM and a socket. We never looked back.
If you are doing only a small amount of JNI, it may be worth it. If you are creating a large interface via JNI, I strongly recommend instead writing the component that interacts with STL in C# instead of Java, and using a socket to communicate between the C# and Java components. It will be far easier to write, test, and maintain.
I have to ask why you find it necessary to use the STL libraries from Java. Is there something in them that's not provided by Java's own massive set of libraries?
I understand why you'd have to call your own code (and I'm assuming you've profiled the Java code and found it wanting, otherwise your effort is wasted) but you seem to be asking how to call STL stuff directly.
We've often had trouble with JNI and it makes our code less portable, so you have to have a very good reason for wanting to use it in our shop, and you have to prove with hard data, why the Java-supplied stuff is not adequate.
Yes. You required to use the swig typemap to convert C++ STL classes to Java objects... and vice versa.
For more information, please visit,
http://www.swig.org/Doc2.0/Android.html
Are there inexpensive or free gateways from .NET to Java? I'm looking at some data acquisition hardware which has drivers for C/C++ and .NET -- I really don't want to do any programming in .NET.
Update: I haven't done what I originally wanted to do, but I've done something similar, using JNA to encapsulate some functions from a DLL, in order to control a USB hardware device from Java. (the DLL comes from the device manufacturer) It works really nicely. Thanks!
You could also try to use JNA for accessing the native library. JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code—no JNI or native code is required. If their API is fairly straight foward, this might be the path of least resistance.
See their getting started guide where they call some native code (printf and GetSystemTime).
Well, there's JNBridge and EZ JCom, just from a Google search.
You could also use IKVM which is a slightly different approach.
(Any reason for not wanting to learn .NET, out of interest? It's a nice platform, and C# is a lovely language...)
If they have C++ versions of the drivers then you could write a wrapper around it using JNI and then load that in Java. JNI can be a bit of a pain, but it would let you use the C++ version of their drivers and not have to deal with .Net at all if you don't want.
I am partial to the recommendation to jump in the deep end with C# since it is so similar to Java. I did this and used IKVM to compile my favorite Java libs. to .NET assemblies and you get [nearly] all the core java runtime classes to boot, so if you tire of trying to find just the right C# collection type, you can always go back to java.util. (No generic collections though. Not sure why.)
Depending on what platform you're on, you have several choices for free IDEs too. For windows you can get Visual Studio Express for free but I also use SharpDevelop. You can also get the Mono IDE on Linux (and a few flavours of Unix, I think ?).
The C# learning curve is shallow if you already know Java. I only blew off 1.5 limbs on landmines that came out of nowhere for reasons I still don't understand, but workarounds were easy to come by. The worst thing about it was the darn developer docs which are AWFUL on account of being so slow. I really miss the snappiness of JavaDoc. Not only are the online docs incredibly slow, the problem is compounded by someones's iffy decision to put class summaries, constructors and methods/properties all on seperate pages so it just takes forever. Someone said to get the docs installer and install docs locally for a slightly improved experience. Not a bad idea I suppose.
I am author of jni4net, open source interprocess 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.
If you have a Java application, the JNI mentioned by the others will be the way to go. You write some wrapper classes, and that's it.
If writing the wrappes is a too big task (depending on the number of methods you have to wrap), have a look at SWIG . I think it generates wrappers automatically, but I never actually used it.
If you want to code in the Java language, but you don't care if your program will run on the JRE/JVM, then you might as well use Microsoft J#. Basically, it's writing Java-Code wich is compiled to .NET-Bytecode and can use the .NET classes of the driver as well as your existing Java classes. With J# you will run into problems if your existing Java-code is newer than Java 1.4, look at this question on how to solve them.
From that point on, you could later add code in J#, C# or any other .NET language. However, you won't get back to the JRE/JVM easily.