In a previous SO question, it was mentioned that USB devices can be mounted using the following approach in Windows:
MOUNTVOL C:\USB: \\?\Volume{ebc79032-5270-11d8-a724-806d6172696f}\
My question is what is that String starting with \\?\Volume called, and what is the best way to retrieve that. I would rather not use .NET if possible since you can't really 'bundle' the .NET runtime without physically installing it on the machine as far as I know.
I would also be interested in using JNA if that is possible.
You can't bundle the Java "...runtime without physically installing it on the machine..." either.
Enumerating the device after it is mounting should be straightforward. Actually mounting the device should NOT be straightforward since Java (and .NET) are both designed to abstract away the hardware.
I recommend that you pick a more appropriate tool for this. Either choose to simply invoke another process to run the mount command (knowing that it won't be portable), or choose a tool that does not abstract away the hardware, or at least less so (perhaps Python?).
EDIT: Clarification on JVM install...
Excellent point--a JVM installation can be much less invasive than a .NET installation since the latter MUST integrate with the OS while the former merely CAN integrate with the OS. So, yes, including a private JVM install is viable and perhaps desirable.
NOTE: The question includes the mount command for the USB device, which tends to emphasize that aspect as a primary requirement.
What kind of USB device are you looking for? The bit you quote is only applicable to USB disk drives, not USB devices in general.
Related
I'd like to obtain the host's full network usage, that is, the current upload and download rates. How can I do that in Java? If it makes that easier, assume the platform is Linux.
How can I do that in Java?
Doing this in Java is a bad idea ... unless there is a strong requirement to have the information in a larger Java application.
You can't do it in pure Java. There are no standard Java APIs for accessing this kind of information.
I Googled for something Java-specific and free that matched your requirements, but didn't spot anything. (YMMV ... please feel free to repeat the search for yourself!).
There are OS specific tools for looking at network stats, etcetera, and one could attempt to run these tools as external processes from Java and "scrape" the output. But that would necessarily be OS / tool specific.
You could attempt to replicate what these tools are doing in Java, but this may involve native library calls, and would certainly be OS specific. (On Linux, you may be able to get the information you need by reading from the /proc file system ... but there could also be access control issues.)
Nethogs: http://nethogs.sourceforge.net/ is probably the tool you're looking for.
Most people use prefer this as it splits bandwith usage up by process.
I see the new Desktop class (which I'd like to use for its browse(uri) method) includes checks to verify that it's supported. If I'm distributing my application for multiple operating systems, should I expect that it will sometimes be unsupported, and stick in code like this "Bare Bones Browser Launch" as a fallback method, or would that be extremely rare? Any particular OSes for which I might expect problems?
(I'm distributing for Mac/Win/Solaris/Linux, but feel free to answer about any exceptional OSes if you know something about them.)
You should program defensively.
From How to Integrate with the Desktop Class:
Use the isDesktopSupported() method to determine whether the Desktop
API is available. On the Solaris Operating System and the Linux
platform, this API is dependent on Gnome libraries. If those libraries
are unavailable, this method will return false
(emphasis mine)
I think the point is the reverse, what does Java require an OS to support? They are giving an OS an out, by allowing the JVM implementer to just return false, say it is not supported, and move on, and still be 100% Java compliant (whether or not that is "write once run anywhere" I'll leave to your own evaluation).
Techniques like the Bare Bones Browser Launch or more complicated libraries like BrowserLauncher, will always only work on a limited set of OSs and browsers than what generic code that is made for the general Java standard is going to give you.
So the upshot is, use a technique like the Bare Bones launcher if an OS you are specifically targeting doesn't support Desktop.openURL, but then you will have to write it to specifically work on that OS - there is no reason to think that the technique works for a given OS and a given JVM on that OS, it just represents what we used to have to do to launch a browser prior to Java 6.
Is Java completely Platform Independent ?
if not then, what care needs to be taken to see that your code written in Java can run on Multi Platforms. Basically it should work on Targeted Platforms like Windows (Various versions), Linux (all flavors), Mac and Solaris.
While in practice, most compiled byte code is platform independent, my experience in my 12 years of developing on the Java platform has taught me that there are still idiosyncrasies from platform to platform.
For example, while developing a Java 1.4 Swing application for PC and MacOSX the behavior of dialogs was different if the parent frame is null.
Another example might be with working with the file system and files in general. The Java API has methods to help shield the developer from differences in path separators (/ vs \). When writing to a file, it important to use the FileWriter API as intended so that return characters and such are generated properly for the platform that it is being written on.
So while the motto is "write once, run anywhere" my experience has been for production envs it is write once, test, everywhere.
As a result, having strong unit and integration tests can help with this, as you can execute those tests on the various platforms you want to distribute your software.
Despite some minor issues here and there, it is cool to see your code running on Linux, Unix, Windows and MacOSX (BSD Unix) using the same JARs.
As djacobson pointed out, the answer is a qualified "yes". For the most part, Java developers don't have to worry about platform dependencies. However, you may run into problems when you're dealing with APIs that handle traditional OS and platform functions.
When dealing with File I/O, for example, it's easy to make your code platform dependent by ignoring the differences between file/path separators across platforms (i.e. using '\' rather than File.separator).
For the most part, yes. Because Java compiles to bytecode that's executed by its virtual machine, it can generally be expected to behave the same way regardless of the system sitting under the virtual machine.
However. Not even virtual machines are immune to bugs. A quick Google search turns up the following, for example:
http://www.ibm.com/developerworks/java/library/j-diag0521.html
Differences in behavior can vary from JVM to JVM. Hopefully you won't end up with code that depends on any of these cases... but careful research is worthwhile to know what the limitations of your infrastructure are.
You problem will not be executing your code, but more likely the assumptions you have to make about file paths, available external commands (if you need them), necessary file permissions and other external factors that don't really fall under the "Java" problem domain. Unless you're planning on using native code (via JNI) extensively, Java will not be your problem, your environment will.
Which brings us back to the old adage: "write once, test everywhere".
Threading priorities is one thing to consider. Other OS like Solaris for example has more thread priorities than windows. So if you are working heavily on multi-threading, OS is something that may affect the program's behavior.
The main thing to be concerned with is UI code, to make sure that it is represented properly on all the platforms you will be running on.
Another source of possible issues is deploying to different app servers. There might be incompatibility issues between them.
Java other than that is platform independent, This is also one of its weaknesses, since you are coding to a common denominator and many features of each individual OS are not available.
There are very few and they should be pretty obvious. like System.getProperty("os.name") is clearly OS dependant or it wouldn't work. The most common one is System.exec() as it calls another application which is on your system, again you should know if the application you are calling works the same on every system or not (unlikely).
Along with the above concerns, the main problem I had was actually building on different platforms, which may not be what your asking, but may be something to watch out for.
OS X is especially guilty of this when using the Apple Distribution of Java (why anyone would want to put out their own packaging of Java I don't know but that is a separate argument, and on OSX i dont think you have a choice but to use their java). The Libraries that you may or may not be relying on are in completely different directories, eg libraries instead of lib if my memory serves me correctly. And the IBM java I think packages Classes in different Jars in some cases. Ridiculous!!
Hope that helps.
I am planning on implementing a NIDS (Net Intrusion Detection System) in the Java programming language.
After searching, I found two libraries for this.
1) Jpcap
2) jNetPcap
Which one should I use and why?
Which is more preferable to use?
It appears development has stopped on Jpcap. Their last release was 2007. In contrast, jNetPcap has had very recent releases. The underlying libpcap C library that they both wrap has continued to evolve, so I would go with jNetPcap for that reason.
On the other hand, libpcap is a fairly simple API. If you are comfortable with C, then you may gain performance advantages by using the library directly instead of going through a Java wrapper. Something to consider, anyway.
One simple idea I've had for network intrusion was to listen for messages on the braodcast IP address. New comers to the network may likely need an IP address from the DHCP server. If this is so, then they will have to send out a broadcast that a DHCP server will respond to . You could write a program that sits on client A and displays popups whenever it hears something on the broadcast address.
If it's still an issue, use .NET version jnetpcap. I built a NIDS for a master's term project and I tried to use Java and get jpcap and similar working but it was near impossible. So I went for the most viable option c# and it worked alot easier, even thought I didn't know it then.
Also use ikvm since you will need to use weka.jar from .NET as well.
Since both the java implementation (OpenJDK) and Android's virtual machine DalvikVM are opensource it must be possible to implement Sun's JavaVM on top Google's DalvikVM. This would make it possible to run JVM based apps and languages (Clojure, Jython) out-of-the-box on the android.
Is there an ongoing effort to produce such an implementation of the Sun JVM?
The OpenJDK makes use of native code so it would be a non-trivial port... there is at least one VM (JikesRVM) that is written in Java, unfortunately it is not a completely working implementation of Java.
Since DalvikVM runs classes that were converted from .class files it should be possible to convert the classes over. Then the "only" issue is when languages generate bytecode on the fly - for that it would require the extra step of converting the generated bytecode over to the DalvikVM format while the program is running on the DalvikVM.
Hmmm.... sort of a JITT (Just In Time Translator) that covertes class files to a DalvikVM files at runtime on the phone. I wonder how slow that would be.
Porting OpenJDK to Android platform is possible. There are effort like : Shark, Zero and caciocavallo that vastly ease the port process (= no ASM, simple AWT peer). Plus Android is nothing but a linux kernel behind. The only question is when will it be done by anybody ?
By the way, both iphones and android phones got Jazelle compatible processor, somebody with very strong processor hacking skills would be very welcome to add Jazelle support to OpenJDK.
Doing so, we could choose between : very light resource acceleration (Jazelle) and JIT ;-)
About iPhone, it is the same thing : a port is possible. Only Apple has put a section in the the iPhone license that clearly forbid VM usage. As per European law, to me, this license section is unlegal. Two reasons : You can not force/link buy of two of your product. Here I tune and Iphones are linked. You can not refuse to sell something that you can sell. Here as soon as a VM would be build for iPhone, if it is refused to be put on the iTune store, then this point will apply. Is there anybody that want to chalenge Apple licence legality on earth ? I don't think so, unhappy people will be flying to Android or any other platform.
In the meantime I have found a possible solution (only JavaME):
"MicroEmulator is a pure Java implementation of Java ME in Java SE."
Running Java ME applications on Android
technically it should be possible to interpret hotspot byte-code on dalvik vm or dalvik's byte-code on hotspot, but it will never be efficient (not mentioning elegant) design for a long run. the cost of doing that might become very high especially with respect to maintenance in the future evolution of such a split ecosystem.
i think, from the very beginning, dalvik vm is a matter of power/market control rather than innovative effort to improve java virtual machine ecosystem. dalvik vm and hotspot vm are lake two highway bridges across the same river build in parallel five meters from each other. it divides and brings confusion to java technological ecosystem.
google is, in my opinion, definitely the technological leader with innovative contributions over last decade that dwarf far more conservative oracle, but in this very subject they have shaken the java ecosystem in nearly destructive way. we (programmers) should strive for a single uniform solution to this problem. that is the main idea behind the concept of "virtual machine" anyway - it should not belong to neither google nor oracle.
try GNURoot app (proot ptrace container) with debian Wheezy;
apt-get update
apt-get install openjdk-7-jre
/usr/lib/jvm/java-7-openjdk-armel/jre/bin/java ...
(including long path)
I don't think the problem is technical. In theory you can migrate OpenJDK to the iPhone for example, but there are legal restriction in place.
See http://davy.preuveneers.be/phoneme/ for MIDP, Foundation and Personal Profile jvms for Android ARM apks. (Thank you Davy!!!)
I have repackaged the Foundation jvm for command line use and host it at vkfox.com/android/bin/foundation-jvm.bin for your pleasure. One could use the eclipse compiler in the JavaIDEdroid free app, or the old kopi or kopisusu compilers with this jvm, togeather with the stubbed cdc + foundation jar file from a J2ME jdk for an onboard development system. Using the features of TerminalIDE -- console and sun compiler -- with indicated ref jars would also get you there. This is essentially equivalent to a headless jdk1.4 with the possibility of MIDP or awt graphics.