get CPU info, RAM info

[ilya]

How using java to get the size of RAM, CPU information?

 

[Janwillem Borleffs]

How using java to get the size of RAM, CPU information?

Google for "java win32 api" to find examples of accessing the Windows API
that should allow you to access this information.

JW

 

[ilya]

But if I want to know for all operation systems?

 

[Janwillem Borleffs]

Google for "java win32 api" to find examples of accessing the Windows API
that should allow you to access this information.

Sorry, too much Windows-minded overhere ;-) You can also check out the
following:

http://www.hyperic.com/support/docs/sigar/org/hyperic/sigar/CpuInfo.html

Thread about this package with usage info:

http://forums.hyperic.com/jiveforums/thread.jspa?messageID=28722


HTH;
JW

 

[ilya]

Thank you for the information.

 

[Arne Vajhøj]

How using java to get the size of RAM, CPU information?

That information is not available as part of standard Java.

You can either:
- write C/C++ code for all the platforms you want to
support and call it via JNI
- find some existing code that does the above

I am not aware of any of the second.

Java is not the right language for this type of code.

Arne

 

[Roedy Green]

How using java to get the size of RAM, CPU information?

I wrote a JNI class for windows to get info about the CPU

see http://mindprod.com/pruducts.html#CPUSERNO

 

[Roedy Green]

But if I want to know for all operation systems?

If you find a library that does what you want, the author may have
implemented it in JNI for several platforms.

There not much of such stuff in the standard classes. The Java ethic
is you should not know much about your platform. The code is supposed
to work on all platforms, not be tweaked to work.

Look through the System properties. See
http://mindprod.com/applet/wassup.html

Worse comes to worse, you must write some C/C++ code for each platform
and glue it in with a common JNI interface.

see http://mindprod.com/jgloss/jni.html

 

[Mike Schilling]

If you find a library that does what you want, the author may have
implemented it in JNI for several platforms.

There not much of such stuff in the standard classes. The Java ethic
is you should not know much about your platform. The code is supposed
to work on all platforms, not be tweaked to work.

The OS-specific parts of the JRE [1] are, of course, precisely stuff that's
been tweaked to work on all supported platforms. Unfortunately, Java
doesn't make it easy toi do this yourself, partly because JNI is difficult,
error-prone, and inefficient for passing large amounts of data, and partly
because Java gives you no help in packaging a collection of
platform-specific JNI libraries and finding the proper one at runtime.

1. E.g., file I/O, networking, threading, etc.

 

[Roedy Green]

The OS-specific parts of the JRE [1] are, of course, precisely stuff that's
been tweaked to work on all supported platforms.

File i/o, networking etc are basically the same on all platforms. This
permits the same Java API to access the native code to handle the
minor variations.

Things like the registry are highly specific. Only Windows has one.
So you can't very well write platform-independent code, though the
preferences system is a rough stab at it. Sun won't help you. You must
look to third parties or JNI.

 

[Eric Sosman]

The OS-specific parts of the JRE [1] are, of course, precisely stuff that's
been tweaked to work on all supported platforms.

File i/o, networking etc are basically the same on all platforms.

Roedy, you should get out more. ;-)

This
permits the same Java API to access the native code to handle the
minor variations.

The Java API's can access a sort of "least common denominator"
of capabilities found on most systems (on all Java-hosting systems,
although that's a tautology). But where do I find the Java classes
that support DECnet, or ISAM files, or AF_UNIX sockets, or resource
forks, or security designators (not sure if that's the right term),
or doors, or ...?

Portability always involves some sacrifice of capability. It's
a matter of balance, not of universality.

 

[Joshua Cranmer]

File i/o, networking etc are basically the same on all platforms. This
permits the same Java API to access the native code to handle the
minor variations.

I might believe that networking is mostly similar (since Windows sockets
is pretty much POSIX sockets verbatim, last I recall), but file I/O more
complicated than the C standard library is quite different. For example,
Windows doesn't have a notion of Unix permissions, and most other OS's
don't have a notion of group-based permissions. So file permissions is
already unreliable.

Of course, if you really want incompatibility, let me point you to the
AWT. There are Windows 32 widgets, X widgets, GTK+ widgets, QT widgets,
and Cocoa widgets (for Mac). And that's just for "basic" Windows, Mac,
and Linux. Windows CE has its own set of widgets, and apparently some
less commonly-used systems also have their own sets of widgets.

And then, just to really home it in, you get applets. I don't think
NPAPI (the closest thing there is to a cross-browser plugin API)
supports enough to implement the java.applet stuff. At the very least,
you'd need separate plugins for Internet Explorer and Gecko-based
browsers. At the worst, a separate one for IE, Gecko-based, Webkit-based
(do Chrome and Safari share the same plugin API?), Opera, and the less
significant browsers. In either case, because of how the plugin model
works, you probably need separate builds for 32-bit and 64-bit, or, on
Linux, each of the various machine architectures.

Other similar messy libraries: threading, sound, new I/O, accessibility
(most likely), and printing.

In short: a fair amount of the Java API has to be reimplemented on every
platform. Too many APIs are nowhere near cross-platform; desktop or
GUI-related APIs actually tend to be specific to a typical desktop on
Linux (GNOME/GTK+ versus KDE/QT).

Things like the registry are highly specific. Only Windows has one.

GConf on GNOME desktops is roughly equivalent. There also exist
approximates on OS X and KDE. Granted, most of these are strictly
per-user preference systems, but considering that they are written on
systems intended to be running multiple users, that's probably a good thing.

 

[Mike Schilling]

The OS-specific parts of the JRE [1] are, of course, precisely stuff
that's been tweaked to work on all supported platforms.

File i/o, networking etc are basically the same on all platforms.

Only if "all platforms" means Lunux, Unix and Windows, period.

 

[Arne Vajhøj]

The OS-specific parts of the JRE [1] are, of course, precisely stuff
that's been tweaked to work on all supported platforms.

File i/o, networking etc are basically the same on all platforms.

Only if "all platforms" means Lunux, Unix and Windows, period.

I am not sure that I understand the period part.

Some of the API's are defined in the C standard. They will be
everywhere.

Other API's are defined in POSIX. OS'es like OpenVMS and Z/OS
are POSIX compliant.

According to Wikipedia QNX and VxWorks are also POSIX compliant. And
Symbian has a compatibility package.

Arne

 

[Arne Vajhøj]

The OS-specific parts of the JRE [1] are, of course, precisely stuff
that's
been tweaked to work on all supported platforms.

File i/o, networking etc are basically the same on all platforms.

Roedy, you should get out more. ;-)

The C and POSIX standards define a lot. And most platforms are
either compliant or close.

The Java API's can access a sort of "least common denominator"
of capabilities found on most systems (on all Java-hosting systems,
although that's a tautology). But where do I find the Java classes
that support DECnet, or ISAM files, or AF_UNIX sockets, or resource
forks, or security designators (not sure if that's the right term),
or doors, or ...?

Portability always involves some sacrifice of capability. It's
a matter of balance, not of universality.

Very true.

Arne

 

[Arne Vajhøj]

The OS-specific parts of the JRE [1] are, of course, precisely stuff that's
been tweaked to work on all supported platforms.

File i/o, networking etc are basically the same on all platforms. This
permits the same Java API to access the native code to handle the
minor variations.

Things like the registry are highly specific. Only Windows has one.
So you can't very well write platform-independent code, though the
preferences system is a rough stab at it. Sun won't help you. You must
look to third parties or JNI.

Various other OS's has gotten registry compatibility libraries.

But fundamentally it is a non portable feature.

Arne

 

[Mike Schilling]

The OS-specific parts of the JRE [1] are, of course, precisely
stuff that's
been tweaked to work on all supported platforms.

File i/o, networking etc are basically the same on all platforms.

Roedy, you should get out more. ;-)

The C and POSIX standards define a lot. And most platforms are
either compliant or close.

Perhaps this has changed since I worried about this stuff, but at one time
"POSIX compliant" meant "A simple-minded test suite could be made to compile
and run", not that you'd actually use the POSIX interfaces for anything that
mattered.

 

[Lew]

Roedy Green wrote, quoted or indirectly quoted someone who said :

I am not sure that I understand the period part.

Some of the API's are defined in the C standard. They will be
everywhere.

Other API's are defined in POSIX. OS'es like OpenVMS and Z/OS
are POSIX compliant.

According to Wikipedia QNX and VxWorks are also POSIX compliant. And
Symbian has a compatibility package.

Since you mention QNX, an older version of which I used for many years some
time back, let me say that it is a really pleasant OS to use, and blazingly
fast. Programming for it was, and by all accounts still is pretty much like
programmin for any *NIX platform, but with some extra goodies that make it a
joy to work with.

QNX uses message-passing over a real-time microkernel Javaat the core of its
activities, and was the earliest and most effective OS of my experiencing at
leveraging some of the advanced multitasking features that have been built
into Intel CPUs since the '286.

As for the portability question, at the top QNX looks like Linux or other
*Nices. While its file system is more advanced than most, or was back then (I
once completely recovered a file system that had lost all its directory
nodes), it still uses the same kinds of C calls, inodes and so forth that most
programmers know.

I see that there is a robust hard real-time Java (pre-5) implementation for QNX.
<http://www.aicas.com/qnx>

Just adding my personal experience to endorse what Arne said.

Even if "Lunux, Unix and Windows" were all that Java supported, or supported
well, that's still the great majority of OS installations. (One can basically
count Mac in that group.)

 

[Lew]

QNX uses message-passing over a real-time microkernel Javaat the core of

Typo - the word "Java" accidentally pasted randomly into that phrase.

 

[Arne Vajhøj]

Even if "Lunux, Unix and Windows" were all that Java supported, or
supported well, that's still the great majority of OS installations.
(One can basically count Mac in that group.)

MacOS X is certified Unix today.

Arne