Re: get CPU info, RAM info

From:

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>

Newsgroups:

comp.lang.java.programmer

Date:

Sun, 18 Apr 2010 22:01:10 -0400

Message-ID:

<4bcbb963$0$275$14726298@news.sunsite.dk>

On 16-04-2010 14:16, Eric Sosman wrote:

On 4/16/2010 1:10 PM, Mike Schilling wrote:

Eric Sosman wrote:

On 4/15/2010 5:35 PM, Mike Schilling wrote:

[...]
VMS also supports files that are not simply lists of bytes,
including both the simple case of sequential files with defined
record lengths and the more complex one of indexed files. In
neither of these does seeking to an arbitrary byte offset make sense.

Long ago when I worked with VMS, it supported three "file
organizations:" Sequential, Random, and Indexed. Of these, only
Sequential fit into the I/O model (or straitjacket) adopted by C
and later by Java.

And really, only sequential with stream/LF recordtype works well.

As I recall, we got a pretty good match for C's notions of
file I/O by using StreamLF for "text" files and Undef for "binary"
files.

Those are the logical choices. But the VMS traditional way is to
use fixed 512 for binary.

And really, only sequential with stream/LF recordtype works well. You can
read variable-length records, but AFAIK you can't write them. (Making
each
"write" call create a new record would be alien to the spirit of the
OutputStream interface, in which the only different between writing an
array
of bytes and writing the contents of the array one by one is (possibly)
efficiency.)

Right. And if VAR records are hard for Java to manage, VFC
records are *utterly* outside the model.

Indeed.

This is the sort of
capability loss I had in mind when I wrote that Java's I/O is a
"least common denominator:" Many systems can support Java's
simplistic notions of I/O, but many systems also support I/O
flavors Java just won't grok.

True.

But when Java or at least Java EE came to existance, then databases
had already replaced "more flat" files as the primary data storage.

There were simply not a big need.

The unending compromise: power
versus portability.

So true.

Arne