On May 19, 2005, at 5:08 PM, David Jencks wrote:
My first reaction is that you have seriously misrepresented everyones positions. However, I don't have time right now to go into much detail, as I am still attempting to work on certification.
I'm sorry, I didn't mean to misrepresent. I have only been following this at a medium level, and was personally overwhelmed by the technical details, so this was partly for me :)
I have attempted to be clear all along that I fully support keeping serialization and think that the arguments against it are way overblown. As such, depicting Jeremy as the sole holdout against the tide of xml-goodness is ludicrous.
Sorry, in the flood of emails, I forgot you were also saying we should keep serialization. Again sorry.
Also, my impression was that we had all agreed at the start that we would do our best to keep xml processing out of the runtime. I guess I should have had everyone sign up on this since it looks like fewer people remember this every day.
I am still against lots of xml processing, but I have changed my mind about serizlization. I do not want to see xml tightly integrated into any code, I rather see a marshalling layer that converts xml to a nice java bean tree that represents a configuration. That way, someone can start with just java code, property files, or whatever. I think serialization is great for caching and rpc, but I don't like it for long term storage or configuration information.
I don't know many details about object serialization. I would like to see a concrete demonstration of problems with serializing a reasonable attribute value, such as a javabean or strategy object.
I think that is part of the big problem here. Too much talk not enough code. I think we should get the advocates of a technique to show the code for class upgrade.
-dain
