Piggypack Encoding/Decoding on RandomAccessFile

[Jan Burse]

The synchronization between resource clients, in
this case a random access mechanism and a stream
mechanism attached to the same file descriptor, will
require a unified view that they share, otherwise
completely independent views with no interaction
between them whatsoever.

From what I have learned from Stanimir my estime
of java.nio has raisen. Kind of think now that it
is a *bad ass* nice API.

@Lew: But I agree, being sceptical can be good.

Bye

 

[Jan Burse]

If you need sequential stream access to all or part of
that data, have sequential clients work with scraps piped
through the lower-lying direct access instances rather
than fight over the same prey.

What is "scraps piped"? How do you eliminate the common prey
through "scraps piped"? Will you not only create a buffering
layer, but the problem will not be evaded?

Bye

 

[Lew]

If you open the raf with mode "r" no such issues
pertain. If you open the raf with mode "rw" then
of course you have an update problem if multiple
threads access the raf, not to speak what happens
accross processes.

Not true. Two clients reading from the same file descriptor interact with each other as you yourself have discussed extensively upthread.

This isn't about update of the file, it's about update of the descriptor. It's also not about threads at all.

But the channel also offers locks. You can even
parameterize them by ranges. And they are even
synchronized accross processes. It happens that I
have used the locks for byte based access, but I
guess they are also useful when a character reader/
write is placed on the byte stream.

Interesting but not relevant to my point.

 

[Lew]

What is "scraps piped"? How do you eliminate the common prey
through "scraps piped"? Will you not only create a buffering
layer, but the problem will not be evaded?

Let's say you want to stream in a UTF-8 entry from the 'RandomAccessFile' (or any other 'DataInput'). If you attach the stream directly to the file descriptor, you have to figure out exactly where to begin somehow or you will not get a validly decoded string. OTOH, the 'DataInput' already knows where the characters begin, as it reads the source using 'readUTF()'. It canthen make that string available via a 'StringReader' wrapper.

And no, the problem of where to start is not "evaded". It's just isolated to one place. The problem of conflicts between the streamed reader and the'DataInput' is completely evaded.

 

[Roedy Green]

You have not established that bugs are left in deliberately, nor that even if they are it's the "focus on money" that makes them do that.

Then I suggest start reporting bugs and joining beta forums.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Capitalism has spurred the competition that makes CPUs faster and
faster each year, but the focus on money makes software manufacturers
do some peculiar things like deliberately leaving bugs and deficiencies
in the software so they can soak the customers for upgrades later.
Whether software is easy to use, or never loses data, when the company
has a near monopoly, is almost irrelevant to profits, and therefore
ignored. The manufacturer focuses on cheap gimicks like dancing paper
clips to dazzle naive first-time buyers. The needs of existing
experienced users are almost irrelevant. I see software rental as the
best remedy.

 

[Roedy Green]

You have not established that bugs are left in deliberately, nor that even if they are it's the "focus on money" that makes them do that.

Pure B.S., like most pseudo-socialist rhetoric.

Another source of evidence is the release notes of when the vendor
expects you to pay for an upgrade when the only important difference
is bug fixes. The sloppier he is initially, the more money he makes.

--
Roedy Green Canadian Mind Products
http://mindprod.com
Capitalism has spurred the competition that makes CPUs faster and
faster each year, but the focus on money makes software manufacturers
do some peculiar things like deliberately leaving bugs and deficiencies
in the software so they can soak the customers for upgrades later.
Whether software is easy to use, or never loses data, when the company
has a near monopoly, is almost irrelevant to profits, and therefore
ignored. The manufacturer focuses on cheap gimicks like dancing paper
clips to dazzle naive first-time buyers. The needs of existing
experienced users are almost irrelevant. I see software rental as the
best remedy.

 

[Jan Burse]

Another source of evidence is the release notes of when the vendor
expects you to pay for an upgrade when the only important difference
is bug fixes. The sloppier he is initially, the more money he makes.

Yes, windows 3.1 was quite simple. And it took years
and billion$ to get windows 7. I think B. Gates is
the one who openly stated his concept of early
release and let the customer pay. But I would need
to cite reference, otherwise people would call me
paranoid.

But on the other hand it is the only reasonable
way to develop software. To put it quickly into
the wild, to gather bug reports, user feedback
and new requirements. How could you do this when
you keep it in the lab. It would only generate cost,
but when putting in the wild, you can have the
cake and eat it too.

LoL

 

[Jan Burse]

'DataInput' already knows where the
characters begin, as it reads the source using 'readUTF()'.

But the problem is posed that I want to piggy pack arbitrary
encoders/decoders, not only UTF-8. For example UTF-16 etc..
Or some cyricllic code page which then needs to be mapped to
unicode.

How do think this is solved by readUTF()? And why do you
think that the file positions do not communicate between
the input stream and the raf, although they derive from
the same file descriptor. In fact they do.

Bye

 

[Joshua Cranmer]

Roedy Green wrote in his tag line:

Facts not in evidence.

You have not established that bugs are left in deliberately, nor that
even if they are it's the "focus on money" that makes them do that.

Given some of the limited experience I have with corporate development,
I would reason that it is very likely that most companies will release
products with known software bugs. However, this is not because they
want to make money on the upgrades but rather because they need to
actually release software at some point in time.

I will admit that all of my experience with software is related to
consumer-targeted software and not enterprise-targeted; however, in
consumer-targeted software, I am not aware of a single instance where I
had to pay for a bug-only fix.