Yeah but isn't that a fundamental problem, not unlike how you version a service so not really a particular OO issue. But since we can't create a new immutable schema/endpoint daily, there are techniques which allows us to at least run longer within a given major contract spec, XMLDecoder/Encoder being one of them. Until versioning is treated at the language level, I don't see how this can be handled any different. It almost segways back to what Reinier Zwitserloot has been writing a lot about in this very forum.
/Casper On Nov 28, 4:55 pm, kirk <[EMAIL PROTECTED]> wrote: > Casper Bang wrote: > >> On second thought, how does using XML > >> suddenly magically get rid of the versioning issue? > > > By itself, it doesn't - but it is more resilient to change because as > > you evolve a bean, as long as you make sure to provide a default > > value, things will continue to work. This is because by design, only > > the changes to a default instance is ever serialized. So if you add a > > new field, old client code will simply ignore it. If new client code > > is fed an old bean, it will simply use the default value. It's > > actually quite clever on Sun's part. > > It al good in theory but it has been my experience that changes in > schema (which happen as a natural course of development in OO system) > will break all of these schemes. > > 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 -~----------~----~----~----~------~----~------~--~---
