Re: List filtering and JList indexes trouble.

Hey there,

   My opinion is that mapping indexes to Images directly is a flimsy design for some of the reasons you have already found. I would make my JList display "container objects" that know how to provide an image on demand regardless of whether the image is currently in memory or not. It would look something like:

public class ImageContainer {
   private WeakReference<Image> imageRef;

   private final String fileName;

   public ImageContainer(String fileName) {
      this.fileName = fileName;
   }

   public Image getImage() {
      // check our weak cache first
      Image image = imageRef == null ? null : imageRef.get();

      // image will be null if either:
      //    a) this is the first time it has been requested
      //    b) the Garbage Collector chose to discard the imageRef's contents
      if (image == null) {
         // load the image on demand now and cache it weakly
         image = loadImageFromDisk(fileName);
         imageRef = new WeakReference<Image>(image);
      }

      return image;
   }

   private static Image loadImageFromDisk(String fileName) {
      ...
   }
}

In this implementation each ImageContainer is capable of loading and caching its Image, but since the caching is done weakly it will never be the cause of memory problems in your JVM. This design essentially allows your Garbage Collector to control your eviction policy for Images from memory instead of you (as is the case when hard references are used).

Once you have converted to using ImageContainers (or some similar concept) you can filter, sort, slice and dice them as much as you want, but each ImageContainer can still "stand on its own and return you its image", regardless of its index in any given EventList or data structure...

James