On Mon, Mar 12, 2012 at 5:30 PM, sebb <seb...@gmail.com> wrote: > On 12 March 2012 16:25, James Carman <jcar...@carmanconsulting.com> wrote: >> We could say we support short-term storage (or transmission-only) only when >> it comes to serialization. That would help eliminate some of the burden > > Perhaps, but why take on any burden without a good use case?
Couldn't look in svn (its slow like hell for me at the moment) to look at the class mentioned... but passing around CSV objects in an EJB environment is surely nice. Have not worked with EJB for quite a while, I think Classes must implement serializable when they are sent from one remote bean to another. > Any form of serialisation adds extra testing and maintenance overhead. > >> On Mar 12, 2012 11:23 AM, "sebb" <seb...@gmail.com> wrote: >> >>> On 12 March 2012 09:02, Jörg Schaible <joerg.schai...@scalaris.com> wrote: >>> > Emmanuel Bourg wrote: >>> > >>> >> Le 12/03/2012 00:16, Benedikt Ritter a écrit : >>> >> >>> >>> I just saw that CSVFormat implements Serializable, but neither does it >>> >>> provide a no-arg constructor nor any of the special serialization >>> >>> methods (and it has no custom serialUID). Is this the way it is >>> >>> supposed to be? >>> >> >>> >> I wrote a test and it seems the serialization works fine. I think the >>> >> no-arg constructor is only required if the class is expected to be >>> >> subclassed, which isn't the case for CSVFormat. The UID is generated >>> >> automatically by the compiler. >>> > >>> > Which silently imply that all compilers from all vendors generate the >>> same >>> > UUID in all versions ... which is not the case. >>> >>> Indeed, but merely adding a UUID is not enough. >>> The UUID needs to be maintained - when the class is changed, it may >>> need to be changed too. >>> If backwards compatibility is required, extra care needs to be taken >>> to make this work; if compatibility is not desired, the UUID needs to >>> be changed when appropriate to prevent incompatible versions causing >>> runtime failures. >>> >>> Adding Serializable effectively puts (some) implementation details >>> into the public API, and increases the maintenance burden. >>> >>> So unless there is a strong use case which cannot be solved in other >>> ways it's best to avoid using serialisation. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- http://www.grobmeier.de https://www.timeandbill.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
