get CPU info, RAM info
in [Java Programming]
|
Prev: Still don't get LayoutManagers
Next: JNDI searches
From: Arne Vajhøj on 18 Apr 2010 21:58 On 14-04-2010 09:33, Eric Sosman wrote: > On 4/13/2010 10:24 PM, Arne Vajh�j wrote: >> On 13-04-2010 21:44, Mike Schilling wrote: >>> Arne Vajh�j wrote: >>>> On 12-04-2010 08:44, Eric Sosman wrote: >>>>> 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. ;-) >>>> >>>> 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. >> >> POSIX is pretty thin in many contexts. Way smaller than the >> Java library. >> >> It is not sufficient to create portable applications in general. >> >> But for the topics mentioned "File i/o, networking" I think it >> will do very well. > > It seems to me that "{Java,POSIX} can do {files,nets} on all > systems" is being mis-read as "{Java,POSIX} can do all kinds of > {files,nets}." My point -- and it's not new, nor complicated -- > is that the former is achieved by making the latter untrue. Again, > two of my counter-examples: Where are the {Java,POSIX} interfaces > for {resource forks,DECnet}? > > The response "Who needs 'em?" may cover a lot of cases, but > it surely does not cover all. There are certainly a lot of IO and network stuff not covered by POSIX. But Roedy started the "standard in C" subthread by referring to "File i/o, networking" in a reply to where Mike were referring to "The OS-specific parts of the JRE". Because the JRE does not support DECnet and resource forks, then those does not counter a claim that the IO and network in Java should be reasonable POSIX standard. (my guess is that there are a few pronlems anyway - there usually are when porting C) Arne
From: Arne Vajhøj on 18 Apr 2010 22:01 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
From: Eric Sosman on 19 Apr 2010 08:19 On 4/18/2010 9:58 PM, Arne Vajh�j wrote: > [...] > There are certainly a lot of IO and network stuff not > covered by POSIX. > > But Roedy started the "standard in C" subthread by > referring to "File i/o, networking" in a reply to where > Mike were referring to "The OS-specific parts of the JRE". Roedy's exact words were "File i/o, networking etc are basically the same on all platforms." I and others have offered examples to refute this overly broad claim. There is a subset of these (and other) capabilities that are widely available, a sort of least common denominator. But "Every city has a pizza joint" does not imply that all food is pizza, nor that a diet of nothing but pizza is good for you. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Eric Sosman on 19 Apr 2010 09:39 On 4/18/2010 10:01 PM, Arne Vajh�j wrote: > On 16-04-2010 14:16, Eric Sosman wrote: >> [... file flavors on (Open)VMS ...] >> 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. Wouldn't have worked for our purposes, because we needed to support "binary" files of arbitrary length, not just multiples of 512. Also, we needed to be able to seek to an arbitrary position, not just to 512-byte record boundaries. (Seems to me the library could have allowed this, but at the time it didn't -- this was, as I said, a while ago.) -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Martin Gregorie on 19 Apr 2010 09:45
On Sun, 18 Apr 2010 21:52:52 -0400, Arne Vajhøj wrote: > On 17-04-2010 07:20, Martin Gregorie wrote: >> On Fri, 16 Apr 2010 20:06:37 -0400, Arne Vajhøj wrote: >>> It is: sequential, relative and indexed. >>> >>> Random access (as opposed to sequential access) is possible to all >>> file organizations. >>> >>> Indexed is really a little database in itself. >>> >>> I believe that some IBM OS'es have similar functionality. >>> >> I think all mainframes from that period had more or less the same >> capabilities for accessing records in a disk file. I used ICL kit >> (first 1900 series and then 2900 series). These offered the following >> access methods: >> >> sequential - variable length records, prefixed with a length word >> stored in arrival sequence. >> self-indexed - fixed length records, retrieved by record number indexed >> - fixed length records, retrieved by a key field, stored >> in key sequence and accessed via a distributed index >> random - fixed length records, retrieved by a key field, >> stored via a hash of the key >> >> All four organisations could be read sequentially. > > And there were often pretty good language support for those accesc > methods in Cobol, Fortran, Pascal etc.. > That was a technology requirement: Here is my justification for saying that. Initially the computer prime input methods were cards and paper tape, followed by magnetic tape. Of these, the only character at a time i/o method was paper tape - Cards are an all or nothing deal - read the whole card or don't read it. Same applied to writing to it. Magnetic tape has always has its data written and read in blocks. If you commit to transferring a complete card image, then record-oriented i/o is the obvious thing to do. It was supported at the assembler level too: in a 1900 or S/360 the 'read' and 'write' instructions were handed a device reference, buffer pointer and buffer length and, in acknowledgement that peripherals were slow, there was also a 'wait for i/ o completion' instruction, so a typical assembler program could process a card while the next was being read. No threading involved, folks! Given this basis, it follows that: - tapes and disks, which both have fairly substantial wait times before date can be transferred were also best handled as record-oriented devices[1]. - Tape: pause while the medium gets up to speed - Disk: wait for heads to move to the required track and then for rotation to bring the required block under the heads. [1] in the case of disk and tape, initially the block was the record but it was soon realised that grouping several records into a block was more efficient. - paper tape could read or write a character at a time, but there's still a small start/stop time, so here too, dealing with a record is more efficient though its harder to manage since the program still reads single characters and must store the character its just read, check for the record separator and issue the next i/o operation before the tape reader or punch has stopped. - with this background it's logical that the early high level languages (FORTRAN, COBOL, RPG) would use record oriented i/o. The real anomaly is the trouble all more recent languages (C, Java, Algol 68, PL/1, etc.) have taken to hide the underlying record/block transfer nature of many i/o devices from the programmer. Algol 60, Pascal and BASIC fall in the middle: the Algol 60 spec leaves i/o as an implementation issue[2] and IIRC Pascal and BASIC can swing either way. [2] Eliott Algol was character oriented because the computers used paper tape as the prime i/o medium and introduced READ and WRITE as reserved words. All other implementations I've seen handled i/o by calling library routines. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | |