commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Heinz Kredel <>
Subject Re: [Math] Serializable (again)
Date Tue, 15 May 2012 08:30:34 GMT
Hi all,

as I am also interested in short term serialization just for moving objects 
between a distributed virtual machines and not in long term serialization, I 
would support the discussion up to now. To express our intentions we could 
make an interface, say 

 public interface Transportable extends Serializable { }

and then implement this interface when ever containers should be short term 
serializable. This interface could then also document our intentions. And this 
would then allow the usage of CM in a distributed setting.



Am Mittwoch, 9. Mai 2012, 09:03:20 schrieb Luc Maisonobe:
> Hi Gilles,
> Le 08/05/2012 23:05, Gilles Sadowski a écrit :
> > On Tue, May 08, 2012 at 02:55:47PM -0400, James Carman wrote:
> >> I don't know that you want to get into supporting long-term
> >> serialization support.  I would say CM should support transient
> >> serialization (if that makes any sense), such as
> >> marshalling/unmarshalling.  If you guarantee long-term serialization
> >> support (reading data from serialized for much later, perhaps by
> >> another version of CM), then we get into the nasty serialization test
> >> cases like Commons Collections has/had.  Yuck!
> > 
> > That's the question: What does it mean to support serialization?
> It can mean many things. However, I thought we concluded last time that
> what [math] would not attempt to support long term serialization, i.e.
> reading again old versions. So we basically ruled out cross-version
> support based on SerialVersionUID.
> > Is there such a thing as short-term serialization?
> Yes, of course, and this what many people need. This is what James
> called marshalling/unmarshalling. This is a standard way to communicate
> between some applications that share a common basis. Of course [math] is
> not a distributed computing environment, but it should not prevent
> people from being used in a distributed environment.
> > CM's purpose is not distributed computing. A project could exist with
> > that purpose, and it would indeed choose the "best" possible library to
> > provide the "distribution" functionality. People on this list already
> > said that it should not be the standard (original) Java serialization
> > mechanism.
> And other people said there is a trade-off between a perfect library for
> this and a library that is cumbersome for people because it does not
> even provide the most basic serialization process for simple containers.
> I will take care of this issue, and will try to do this as cleanly as
> possible.
> Luc
> > Regards,
> > Gilles
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message