As I understood Joe, his issue is with the fact that build-in binary serialization is a bad idea because a class definition will inevitably mutate over time. So while implementing Serializable is great for when you are in full control on both ends, say when using it for caching, java.beans.XMLEncoder/XMLDecoder really is superior. On some level this is just another facet of static vs. dynamic, you either have a mutual contract or you don't.
What Serializable as a marker interface does provide, is a way to express a type-safe API around it (i.e. ObjectInputStream takes a Serializable) but whether it actually buys you very much I don't know. In Effective Java, Josh Bloch argues for marker interfaces. I believe both C# and Scala chose to externalize this aspect and rely on annotations for such expression of intention, something Java did not originally have as an option. /Casper On Nov 28, 11:10 am, kirk <[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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
