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]>
