Viktor Klang wrote: > So basically, what you're saying is that: > > final static long serialVersionUID > > Is a brilliant solution for version management? ok, I left out the bad part hoping no one would notice ;-)
Kirk > > On Fri, Nov 28, 2008 at 11:10 AM, kirk <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > Hi All and particularly Joe > > Just catching up on some older podcasts. In episode #215 you all got > into an argument about serialization. Joe states that > Serialization is a > pattern that should never have been implemented. I disagree.. > strongly. > How serialization has been implemented from an API point of view is > brilliant. It provides perfect package stability between your > application and the code implementing serialization. You can > change your > code without anyone needing to change serialization. Serialization can > change without anyone needing to change their application. It all > depends upon keeping the API, the Serializable interface stable. There > is no magic here, the serialiation framework depends on a stable > definition of Serializable also. > > Not having methods in the interface is also quite brilliant. This > allows > serialization to work while imposing minimal constraints on the > developer. All I have to do is implement the interface. The framework > can use reflection to find read, write methods, the static array > ObjectStreamField, or the fields themselves. If you've implemented the > read/write methods, you've filled out the template for double > dispatch, > a very good pattern for (re)building an execution context that > maintains > a nice level of decoupling. It is a pattern that is ill understood and > is quite powerful in it's ability to allow you to park code where it > belongs (which acts to minimize the amount of code you need to > write and > encourages better separations and decouplings). > > That said, we could have made Object the target of the > serialization API > and made everything serializable. We could of had subclasses of Object > optionally override read and write. But then this argument could > be made > for a number of other features (events??). The question is, where > do you > draw the line. > > I'm sad that no one stood up for the Serialization interface. May even > half your code share in the beauty of this often and unjustly maligned > implementation. > > Regards, > Kirk > > > Speaking @ devoxx > Speaking @ jfokus > > > > > > -- > Viktor Klang > Senior Systems Analyst > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
