river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: River-29
Date Fri, 23 Apr 2010 01:09:50 GMT
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
>
>   

Mime
View raw message