Hi Tom,
Hmm... My Thoughts: Rather than make those fields protected, we could
make protected get methods return them?
Although the reference to the array is final, the contents of the array
are still mutable.
On one hand, MarshalledInstance implements Serializable, which means the
internal structure is publicly published, however if we want to access
MarshalledInstance from multiple threads, we want it to be immutable.
Really we should use defensive copying in MarshalledInstance's
constructor, as Mark has correctly highlighted, the array is still
mutable as it isn't defensively copied during construction.
However the original author's intent was for it to be immutable by
making the field final.
We'd also need to defensively copy the field in writeObject() and
readObject(), so an array reference cannot be stolen.
We can give a subclass access to the byte array by providing a protected
method that returns a copy of the array, subclasses can then utilise it
for overriding superclass methods and cache a transient copy.
We can't afford to ignore the march toward multiprocessor chips and
inevitable concurrency, the sooner we come to grips with it the better.
Immutable classes (eg String) are the simplest form of concurrency, I'd
like to utilise this pattern as much as possible.
Cheers,
Peter.
Tom Hobbs wrote:
Peter; I don't know about DiscoveryEvent's fields. I can't think of any
reason off the top of my head as to why they can't be made protected. I
remember a little while ago you were talking about MarshalledInstance for
some reason. (Or did I just make that up?) What are your thoughts on
RIVER-29?
Cheers,
Tom
