I need to write a small client application which gives CPU information such as CPU_TYPE, Processor_Speed, Serial number, UUID, operating system, physical memory and etc...
Does any one knows very straight approach for getting these information.
Thanks in advance
Viswanathan G
For CPU try org.hyperic.sigar.cmd.CpuInfo.
For OS try System.getProperties().
On Windows you could use WMI to get the necessary information by simply executing a (or several) simple scripts.
On linux you can do something similar by parsing information out of proc/cpuinfo and other stuff (not an expert there).
minimal example for win
I'm not aware of any framework that is crossplatform for this kind of information - mostly because there's just no way to get this information without delving deep into the platforms insides. Depending on how much data you need you may get by by parsing the data from some trivial scripts or you could use frameworks for all platforms you need.
I'm pretty certain there's no way to do this in pure Java. You'll need to use JNI or some other native-code interface to get information from the underlying OS. Unfortunately, this will also make your Java program not portable to other operating systems.
I'd just call some native command for that. On Linux it is cat /proc/cpuinfo.
Java is not good tool for this purpose but still can easily collect information from such native tools/calls.
Related
I would like to find hardware information such as the hardware ID, manufacturer and type of graphics card, CPU type etc. from within MATLAB. Preferably without installing any additional toolbox or third-party scripts.
I assume this could be done by directly accessing the Java interface.
It's not very easy to do this in a platform-independent way.
I would start by taking a look at cpuinfo from the MATLABCentral File Exchange. This does quite a bit of what you're asking for (although not everything). It does it by including separate code paths for Windows, Unix and Mac, and running the appropriate commands on each.
It's a third-party script, which I know you specified that you didn't want, but it is freely available and authored by a MathWorks developer - and even if you can't use it directly, you could perhaps at least read through it to see how you might proceed to implement things yourself.
I want to replace the current Java process by a new one just like the Unix exec does. There has been already a similar question here, but I'd prefer a solution consuming as few memory as possible (the accepted answer suggest to use ClassLoaders, which could lead to memory leaks; a similar simple solution would be to use another process just to start the proper one). It can be surely done in a platform-dependent way using JNI, and I think I can do it for Unix (and a solution for Unix seem to already exist), but I know nearly nothing about the corresponding Windows API. What Windows function should I call? Has anybody done it already?
With Windows there are many subsystems to choose from that run on the base OS, so it helps to have some sense of what you are aiming for. For example, if you can use the C run-time library then you can just use the _exec() family of functions which are very similar to their unix cousins. Perhaps you can modify jniexec to work with windows using these.
The Win32 API doesn't include the concept of 'exec'. THe POSIX API does. The low-level WinNT API has the building blocks, but it's quite complex to use them, and, at least in the past, required recourse to undocumented functionality.
Is it possible to write an antivirus program in Java such as that it can intercept a program from being executed? Can I have such a deep control of the OS in Java?
update:
what about c#? same restrictions apply or that is a better way?
Having such influence on the OS is possible. There is only the problem, that you will lose the platform independency or at least have to write the code for every given platform due to the reason that such actions require quite deep access of the system which could be achived with JNI, which would tie the method you use it in to the OS.
I don't think that sort of control is possible with Java, primarily because it uses a VM and is shielded from the OS. Or rather the OS is shielded from the Java VM. This is by design.
Edited to add for clarity: I am assuming that you want to write the entire solution in Java, and not mix languages.
I am not convinced that it would work even with JNI.
In the case of "intercepting" when the OS starts a new process (or writes to a file or whatever), you need to write some kind of driver or kernel module which hooks into the OS. That driver/module is most certainly written in native compiled code. So the OS is the one in charge here, and will eventually call your native module.
So, as I see it, Java is not even involved here.
Thats the basic approach anyway. It may be possible using something like pam in Linux which is configurable to do almost anything related to security and file/process permissions and can call other processes to do its bidding. Seems far fetched though to run a JVM instance for each new process the OS tries to start.
As HalloDu said, this is technically possible with the use of JNI. However, IIRC, most antivirus programs use some sort of driver to intercept opened files and scan them before allowing the OS to continue using the file. This being the case, the amount of native code you would have to write (in C or possibly C++) would be substantial and is likely to outstrip your Java code in size.
When writing low-ish level apps, I'd stick to C. However, it might make sense to code things like the GUI in a higher level language, though Java wouldn't be my choice there either, because it's kind of a pain to interface with C. Personally, I'd do the whole damn thing in C just because mixing languages tends to be a pain. If I had to mix languages, my choices would by C and python, simply because ctypes makes interfacing with C really easy.
It is possible with the JNI. You would mostly be using Java for a GUI and C/C++ for any other sort of antivirus work though.
What is the point in making your own Antivirus? It is a lot of work, but I guess it would be cool if you made it a portable one that block and removes all the more nasty ones. If you must persist, ClamAV, it is an open source and pretty good AV (no realtime protection) but programmed in C++.
Your best bet might be to write the GUI and much of the logic in Java, then have a C or C++ back-end that does the scans.
You can then re-use the front-end across platforms and keep the platform specific stuff in the lower levels.
This way you can use the strengths of both languages--Java's platform independence and ease of use and C/C++'s ability to directly access the underlying platform.
How can I retrieve a hard disk's unique ID using Java+JNI on Linux, Windows and Mac?
To sum it up: you can't do this with just Java
I do not think there is a simple, uniform way to do that.
You can however create seperate logic for all cases; on linux you could check /proc (using the java.io package). There are probably similar ways on OS X and Windows, or, if not, you could execute a shell script or batch file on these systems and parse the output.
Or you could use JNI, though that would mean building your module for all environments.
You could use Java+JNA (https://github.com/twall/jna/), but then you'd have to figure out how to gather that information by using native libraries on each of the platforms you'd like to support.
The benefit is that you wouldn't have to compile any C/C++ code for each of the platforms. If you decide to go with that option someone else might be able to tell you how to figure out the harddisk IDs on the different platforms using C/C++ code/libraries.
AFAIK, on Linux you need to read something from /proc or /sys, on Windows I would look through MSDN and see what you could find that is usable in Visual Studio (C++) and for Mac someone else would have to fill in. Solaris/BSD should probably be supported too if you do it right. In fact, for most of the POSIX-compatible OSes out there I think you should be able to do it somewhat uniformly.
As already in indicated, you can't within the boundaries of the question. However, you might be able to do it with a combination of java and native code specific for each platform via the JNI layer.
I may be wrong, imho, this canNot be done without using JNI.
Build your app in two parts
Native component that will use either a script/application to query the hardware, and output to a file
Your java app to read from the file and do whatever
I know of at least one post which has same words like this. But this is not exactly same as that post. I'm trying to work a way to "share" data between a .NET and Java application. I'm not concerned about objects, but just plain strings if u like.
I have a .NET application capturing real-time data and a Java application which has capability to analyze and work on this data. I'm looking for ways to re-use this same java app without coding it entirely in .NET.
My problem is that the data is "fairly" REAL-Time (.NET), and so has to be the analysis (Java). I can live with microsecond delays but I can't afford one second delay. WebServices, Queues (as in Messaging Queues), RDBMS are some of the options I can think of. Is there any better way?
Or has anybody got some real performance numbers for the solutions I mentioned above to select one of them? And just to get started: RDBMSs' are not "THAT" good for concurrent (connections doing) insertion/updation/reading, at least with the crude way of doing DBMS stuff. (Deadlocks?)
What are "objects" if not a mechanism for describing "data"? But I digress - I suspect I would look at a TCP socket between the two. If the data is very basic, then fine - just write directly to the stream; if there is any complexity, perhaps use something like "protocol buffers" to provide an easy way of reading/writing dense data to a stream without having to write every last byte yourself.
I think microsecond delays are going to be a challenge for any approach here... will millisecond delays do?
For completeness:
Another possible is to use Named pipes, it should be pretty quick, and I'd imagine (being a java guy I can only imagine) that .NET has native support for them. The down side is that on windows you'll have to either write a JNI extension or use a library like JNA to poke around at the Win32 API from Java.
Sounds like a local socket could do. The latency should be in low ms or less.
Depending on your program you may get some milage out of what #Cowan reports in answer to 'Any Concept of shared memory in java', his answer is: Any concept of shared memory in Java
In summary: he say's that you can use memory mapped files between two processes on the same machine. This in theory could work between .NET and java assuming .NET has some memory mapped file support.
Different machines communicate with each other by sending messages into sockets. Please check the below link for example.
Socket programming in the real world
Answers provided here are great. One idea that might be of interest, but is probably asking for more trouble than it's worth is to load both VMs in a single process (both the JVM and the CLR can be loaded within a native Windows application) and give them access to native code. Java via JNI and .Net via the mapping functions to native code that they allow.
You could also leverage native queue semaphores to wake up a thread on one side or the other when data is updated.
While JNI transitions are expense, they would probably still be faster than the native local socket implementation.
How is your Java application currently deployed? It sounds to me like you're willing to make some modification to it, so I'm assuming you have access to the source code.
I know this is a little out there, but could you compile the Java application in the J# compiler, so that your .NET app has native access to it?
You can convert your compiled java application to .NET by IKVM. After that you can change logic of your .NET application so it will not make data transfers to Java application, but just call data processing code written in Java as it were written and compiled for .NET.
There are a number of JMS servers which support .NET and Java clients. These can perform messages in under a millisecond.
However you might like to try an RPC solution like Hessian RPC or Protobuf RPC. These can achieve lower latencies and can give the appearance of direct calls between platforms. These support .NET and Java as well.