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. >
