Does anyone know of a way to issue commands to a hard drive within Java? Does Java even support this kind of hardware interaction?
For example, if I have a SCSI hard drive that I would like to inquiry, is there a pre-existing Java method to do this, or would I have to write my own?
http://en.wikipedia.org/wiki/SCSI has some general information on SCSI commands in case you aren't familiar.
Java doesn't support talking directly to hardware like that. However, you can use JNI to call a C/C++ function from Java that can.
Three words "JNI or JNA". I strongly recommend taking a look at the latter to see if it suits your situation, instead of just opting for JNI.
No, since Java runs in a "virtual" machine rather than a real one. But it could be used as a bridge as dj mentioned earlier using JNI.
According to Wikipedia JNI can also call assembly directly. JNI could be used to call complete programs written in C or C++
you need to write the HDD interface code in C/C++ and then call that from Java using JNI
Related
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/
Is it possible to call matlab function in java, if so, How can I use it.
For example there is a function in matlab called scatter3 and plotter3
How can I use them in Java.
Thank you
There are undocumented ways to call MATLAB from Java. You can learn a lot more about them from #YairAltman 's blog Undocumented MATLAB. Some of these methods are captured in the matlabcontrol package.
Since the functionality is undocumented and subject to change (and since matlabcontrol is not updated frequently), you should not rely on this ability for anything critical.
I have two options - I can either use JNI or use Runtime.exec to execute a C++ library.
The C++ program is CPU intensive and long running i.e. some calls may take up to a couple of hours to return.
What are the pros and cons of each?
Which approach should I go for?
If you need to interact with the C++ library, go for JNI.
If it's a standalone program that you just want to invoke (and perhaps grab the output), Runtime.exec() is much, much simpler.
Have you looked into JNA as a third option?
From the JNA site:
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. This functionality is
comparable to Windows' Platform/Invoke
and Python's ctypes. Access is dynamic
at runtime without code generation.
See their getting started guide for an introduction.
Using JNI may restrict your ability to move from 32bit to 64 bit. You may also find you have to tune the application memory settings as well.
Unless you know how well the C++ stuff is written - it could make your app more unstable. You are lucky in that the C++ bit takes a few hours - so just call it externally.
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.