Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Peter <jini@zeus.net.au>
Reply-To: Peter <jini@zeus.net.au>
To: dev@river.apache.org
Subject: Re: Immutable Entry
References: <1370953391.12414.11.camel@Nokia-N900-51-1>
	  <1370953511.26113.170.camel@cameron>
In-Reply-To: <1370953511.26113.170.camel@cameron>
Content-Type: multipart/alternative; boundary="=-RQnqPlfnOskYDI3a8MBM"
Date: Tue, 11 Jun 2013 22:55:38 +1000
Message-Id: <1370955338.12414.41.camel@Nokia-N900-51-1>
Mime-Version: 1.0

--=-RQnqPlfnOskYDI3a8MBM
Content-Type: text/plain; charset=utf-8
Content-ID: <1370955338.12414.38.camel@Nokia-N900-51-1>
Content-Transfer-Encoding: 8bit

Although a user dev could use final fields in their own Entry implementations and perhaps should even be encouraged to do so, an immutable Entry could be simply reconstructed with the modified state before being submitted back into a space.

What appears to be one object has many copies across distributed nodes, one more local copy won't hurt.

I'm thinking about a best practices web page for user devs.

Regards,

Peter.

----- Original message -----
>
> On Tue, 2013-06-11 at 08:23, Peter wrote:
> > I've been thinking about how Entry objects are immutable in serialized form
> > and of course how they are not in unserialized form.
> >
> > Should Entry fields be final by default?
> >
>
> No.  Javaspaces usage is frequently to take an entry, modify it and then
> put it back into the space.
>
> Greg.
>
> > The JMM makes an exception for Serialization, allowing final fields to be
> > frozen after construction during deserialization, provided it occurs before
> > sharing with other threads. It would allow Entry's to be shared safely among
> > threads, as long as their public fields aren't mutable, eg: an array.
> >
> > Regards,
> >
> > Peter.
>


--=-RQnqPlfnOskYDI3a8MBM--