river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Immutable Entry
Date Tue, 11 Jun 2013 12:55:38 GMT
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.
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message