Name: apR10100 Date: 12/13/2000
--------------------- 1.3's MediaTracker serialized form spec
Class java.awt.MediaTracker implements Serializable
The head of the list of Images that is being tracked by the MediaTracker.
refer MediaEntry class, that is absent in spec. This makes serialized form of
MediaTracker class incompatible between java implementations.
---------------- e-mail thread
This interface is meant to allow any instance of a class implementing it to
have it's state saved to and restored from a java stream.
MediaTracker, by its nature has a very transient state, with each of the
being tracked changing state independently of the MediaTracker object itself.
Also, the states of these objects will very likely have no meaning after the
deserialization of a MediaTracker, which could be at any time in the future.
MediaTracker also relies on a linked list of abstract MediaEntry objects,
currently with only one concrete subclass: ImageMediaEntry. While this
also implements the serializable interface, MediaEntry does not. All of the
state information about the tracked object is held in the MediaEntry class,
and thus is lost on serialization. As well as the state information, the
structure itself is held in MediaEntry, meaning that only the first added
of the lowest ID set will be serialized at all.
Finaly, the only object that a MediaTracker can hold is a java.awt.Image, a
class that is not itself serializable (and nor are any of its concrete
So, the only state in which a MediaTracker can be sucessfuly serialised is
the one in which it contains no tracked objects, and MediaTracker does not
implement an API which allows code to check if there are any present.
The PJCK1.2 test for the serialization of MediaTracker:
creates 4 Images, and one MediaTracker, does not add any of the Images to
the MediaTracker, and then tests for the correct serialization and
deserialization of the object, checking that the state of the tracked
of the saved object (of which there are none) matches the state of the
objects of the restored object (of which there are also none).
If the Images had been added, the test would of course fail with a
Our implementation of MediaTracker does not use MediaEntry or
classes, adding them to our Java implementation would increase code size and
provide no extra functionality, as they are never used, and can never be
to a serialized stream without an exception being thrown ending the
However, to pass the JCK test, these classes must be added, and extra code
added to our implementation of MediaTracker to attempt the serialization of
instances of these classes, which must fail by throwing an exception.