Name: apR10100			Date: 12/13/2000



--------------------- 1.3's MediaTracker serialized form spec

Class java.awt.MediaTracker implements Serializable 
Serialized Fields 
head
java.awt.MediaEntry head
The head of the list of Images that is being tracked by the MediaTracker.
 
addImage(), removeImage()
---------------------------------------------------------

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
  objects
  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
  subclass
  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
  list
  structure itself is held in MediaEntry, meaning that only the first added
  object
  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
  implementations).

  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:

    tests/api/java_awt/serialization/MediaTrackerTests.java

  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
  objects
  of the saved object (of which there are none) matches the state of the
  tracked
  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
  NotSerializableException.

  Our implementation of MediaTracker does not use MediaEntry or
  ImageMediaEntry
  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
  added
  to a serialized stream without an exception being thrown ending the
  attempted serialization.

  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.
----------------
                      
======================================================================