FULL PRODUCT VERSION :
java version "1.7.0_02"
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)

A DESCRIPTION OF THE PROBLEM :
Following common OO principles and doing something like, oh say, extending java.awt.Image is met with @#$! hardcoded limitations, such as those found in sun.awt.image.SurfaceManager.getManager(Image img). Where you have the famous last words:

   73 /*
   74 * In practice only a BufferedImage will get here.
   75 */
   76 try {
   77 BufferedImage bi = (BufferedImage) img;
   78 sMgr = new BufImgSurfaceManager(bi);
   79 setManager(bi, sMgr);
   80 } catch (ClassCastException e) {
   81 throw new IllegalArgumentException("Invalid Image variant");
   82 }

Which makes it difficult to implement custom image classes.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- Create a new class tat extends java.awt.Image
- Do some stuff to create a valid instance of your new fancy image class and write some code that gets you to a point where you can...
- Call something like Graphics2D.drawImage(Image, AffineTransform, ImageObserver)
- Witness the horror as you are lied to because drawImage doesn't really take an abstract Image, thanks to hardcoded implementation assumptions.


REPRODUCIBILITY :
This bug can be reproduced always.