Sorry, I meant dropping backward compatibility for JDK 1.1 since ObjectInputStream#readFields requires JDK 1.2.
At 00:14 20.11.2001 +0100, you wrote: >Robert, > >I also noticed that ObjectInputStream#readFields method was introduced in >JDK 1.2. I have no qualms about dropping support for JDK 1.2. However, if >that is going to be the case, then the Priority class can be made >serializable while still conserving the flyweight property by implementing >the readResolve method: > > >Java Object Serialization Specification >--------------------------------------- > >3.6 The readResolve Method > >For Serializable and Externalizable classes, the readResolve method >allows a class to replace/resolve the object read from the stream >before it is returned to the caller. By implementing the readResolve >method, a class can directly control the types and instances of its >own instances being deserialized. The method is defined as follows: > > ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException; > >The readResolve method is called when ObjectInputStream has read an >object from the stream and is preparing to return it to the >caller. ObjectInputStream checks whether the class of the object >defines the readResolve method. If the method is defined, the >readResolve method is called to allow the object in the stream to >designate the object to be returned. The object returned should be of >a type that is compatible with all uses. If it is not compatible, a >ClassCastException will be thrown when the type mismatch is >discovered. > >For example, a Symbol class could be created for which only a single >instance of each symbol binding existed within a virtual machine. The >readResolve method would be implemented to determine if that symbol >was already defined and substitute the preexisting equivalent Symbol >object to maintain the identity constraint. In this way the uniqueness >of Symbol objects can be maintained across serialization. > >-------------------------------------------------------------------- > >This is exactly the semantics we want for the Priority class! > >Regards, Ceki > > >At 23:19 18.11.2001 -0500, you wrote: >>I'm pretty happy with the new version posted at >>http://traxel.com/tools/LoggingEvent.java >> >>It's now reading 1.1.3 and 1.2, and deserialization >>has been refactored to a satisfactory level. >> >>Known Issues: >> >> - It has not been rigorously tested. >> >> - startTime is static, so when you serialize, >> then compare startTime to timeStamp you get >> a meaningless number (startTime is coming >> from the server, timeStamp is coming from >> the client). This could be solved by making >> startTime an instance parameter, and initializing >> it to application start time in the constructor >> (have a class parameter systemStartTime). >> Then readObject could simply overwrite the >> instance parameter with the serialized value. >> >> This is, of course, assuming that the objective >> is to be able to tell how long into it's life >> the application was when the log was generated. >> >> >>-- >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
