From: Arne Vajhøj on
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
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
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
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
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 |
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: Fun with casts
Next: JNDI searches