Re: get CPU info, RAM info
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
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
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