get CPU info, RAM info
in [Java Programming]
|
Prev: Still don't get LayoutManagers
Next: JNDI searches
From: Arne Vajhøj on 8 Apr 2010 19:40 On 08-04-2010 06:12, ilya wrote: > 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
From: Mike Schilling on 11 Apr 2010 01:21 Roedy Green wrote: > On Thu, 8 Apr 2010 04:29:04 -0700 (PDT), ilya <bumsys(a)gmail.com> > wrote, quoted or indirectly quoted someone who said : > >> 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. 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.
From: Eric Sosman on 12 Apr 2010 08:44 On 4/12/2010 4:54 AM, Roedy Green wrote: > On Sat, 10 Apr 2010 22:21:07 -0700, "Mike Schilling" > <mscottschilling(a)hotmail.com> wrote, quoted or indirectly quoted > someone who said : > >> 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. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Joshua Cranmer on 12 Apr 2010 09:25 On 04/12/2010 04:54 AM, Roedy Green wrote: > 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. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Mike Schilling on 12 Apr 2010 12:40
Roedy Green wrote: > On Sat, 10 Apr 2010 22:21:07 -0700, "Mike Schilling" > <mscottschilling(a)hotmail.com> wrote, quoted or indirectly quoted > someone who said : > >> 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. |