get CPU info, RAM info
in [Java Help]
|
Prev: Fun with casts
Next: JNDI searches
From: Mike Schilling on 16 Apr 2010 13:10 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. 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.)
From: Eric Sosman on 16 Apr 2010 14:16 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. > 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. 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. The unending compromise: power versus portability. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Arne Vajhøj on 16 Apr 2010 20:06 On 16-04-2010 09:07, 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. No - it is: sequential, relative and indexed. Random access (as opposed to sequential access) is possible to all file organizations. > Of these, only > Sequential fit into the I/O model (or straitjacket) adopted by C > and later by Java. As the only language (of those that I know) on VMS then C IO only has full support for sequential files. Of course access to the other organizations are possible using VMS specific libraries. And yes Java inherited that - and using the VMS libraries requires use of JNI (I have a nice lib for indexed files if anyone is interested). > Next time someone asks "How can I delete some data in the > middle of a big file?" and you answer "Copy the whole file but > omit the doomed data," consider that VMS' Random and Indexed > organizations support delete-in-the-middle directly (for suitable > notions of "middle"). I mention this for the benefit of anyone > who might think it "eccentric" to want to avoid copying and re- > copying an enormous file just to erase a little data. Indexed is really a little database in itself. I believe that some IBM OS'es have similar functionality. Arne
From: Arne Vajhøj on 16 Apr 2010 21:03 On 13-04-2010 22:20, Lew wrote: > Lew wrote: >> QNX uses message-passing over a real-time microkernel Javaat the core of > > Typo - the word "Java" accidentally pasted randomly into that phrase. That typo made it on topic ... :-) Arne
From: Lew on 16 Apr 2010 22:30
Lew wrote: >>> QNX uses message-passing over a real-time microkernel Javaat the core of Lew wrote: >> Typo - the word "Java" accidentally pasted randomly into that phrase. Arne Vajhøj wrote: > That typo made it on topic ... > > :-) Cute, but I thought it was the comment, "I see that there is a robust hard real-time Java (pre-5) implementation for QNX. "<http://www.aicas.com/qnx>" that made it on topic. -- Lew |