Joern Huxhorn skrev:
Well, a stream could contain both LoggingEvent0916 and LoggingEvent0918 and the Deserializer would produce the correct output using instanceof and some defined conversion. The point is that the old class would not be lost as it is the case if just the serialVersionUID is changed. It could therefore still be deserialized. After thinking it over I believe that this is the exact reason why XMLEncoder/XMLDecoder was introduced in the first place - the ability to read in old classes.
I don't think that it is possible to get to work _well_ but I'm always happy for a good discussion.
Have you had the time to check my xml format? While it's not exactly terse ;) it's definitely human-readable. I think I have understood what the problem with my use of the "humanly readable" term is. It is not the actual XML with names and tags, but the data carried I am talking about. Timestamps are fine but is not really readable to a human.
I can easily live with one character tag and attribute names if the data in the fields carry meaning to the human eye :)
Well, I'm using yyyy-MM-dd'T'HH:mm:ss.SSSZ as the primary time stamp format and then apply some magic to change it into a valid xml timestamp, i.e. I add a colon between hh and mm of the timezone. It mad my sigh quite a bit when I realized that SimpleDateFormat did not support this...
A valid xml timestamp? According to what dialect? SOAP? Frankly I think that these date objects are expensive to reconstruct - perhaps you should look into this if performance is an issue to you? I believe the date object just serializes the long datestamp which is much cheaper to deserialize than to deconstruct a string into pieces and build a date/calendar object from it. Note you also need timestamp information for this so it most likely goes through a Calendar.
Point taken, I wasn't really thinking about that when I was implementing it, I primarily wanted to do it *right* ;)
It's an xs:dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime) which seemed reasonable to me. xs:dateTime expects a colon between timezone hh and mm while SimpleDateFormat does only support hhmm :p
I implemented your suggestion and it's - unsurprisingly - deserializing quite a bit faster, now. Hehe, if I read your tables correctly the lilithXmlUncompressedDeserializer went from 1.974544 sec to 0.497055 sec, which is four times faster so "quite a bit" is quite a bit of an understatement :)
Also the value is very close to the 0.493445 value for serializationUncompressedDeserializer so it appears that the two approaches have about the same runtime performance.
Now I just need to update the schema... and I really need to implement an EventWrapper Serializer that's using my xml so I can use it as the Lilith file format...! Performance and size is absolutely acceptable.
Now I just need to bully you into shortening all tags and attribute names into one character and skip any namespace prefixes :) Then we agree O:-)
I moved the benchmarks to http://apps.sourceforge.net/trac/lilith/wiki/SerializationPerformance so I don't have to change the closed bug all the time :p You _could_ also just reopen the bug :)
-- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"