Re: Piggypack Encoding/Decoding on RandomAccessFile
Jan Burse wrote:
Thank you for pointing to this API. Wasn't aware.
I just had a look at the API, and also found:
public static Reader newReader(ReadableByteChannel ch,
CharsetDecoder dec,
int minBufferCap)
So via the minBufferCap parameter also problems of
overreadinging the underlying raf can be solved to
some extend, if this is a problem.
This has been a very interesting question and ensuing thread. I've seen th=
is sort of multiple interaction (conflict) of resource clients a couple of =
times but most of those cases were unintentional and considered bugs.
One lesson is that such situations are always fraught with peril.
Which is why they pay us the big bucks. Fraught with peril is the programm=
er's bread and butter. But you can't be careless, and the questions addres=
sed in this conversation are key.
Inevitably I wonder if the functional need can be served at a different lev=
el of the architecture. Here's the syllogism:
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 v=
iews with no interaction between them whatsoever.
The questions here address how the problem would be solved in breadth at th=
e resource-access level. The baseline model is two concurrent clients with=
shared state.
What about a solution in depth with a serial model?
'DataInput' and 'DataOutput' make good first responders to mixed-format bin=
ary files. That's why 'RandomAccessFile' implements them. They're intended=
for the sort of low-level operations with manual bookkeeping for data loca=
tion as discussed. They are the clear choice for direct access to the reso=
urce.
If you need sequential stream access to all or part of that data, have sequ=
ential clients work with scraps piped through the lower-lying direct access=
instances rather than fight over the same prey.
--
Lew