The following test case shows that the GraphicsConfiguration of a BufferedImage
will report the bounds of the first BufferedImage of that type that was
created.

------- BIGCTest.java -------
import java.awt.*;
import java.awt.image.*;

public class BIGCTest {
    public static void main(String argv[]) {
	int type = BufferedImage.TYPE_INT_RGB;
	BufferedImage img1 = new BufferedImage(10, 10, type);
	BufferedImage img2 = new BufferedImage(20, 20, type);
	GraphicsConfiguration gc1 =
	    img1.createGraphics().getDeviceConfiguration();
	GraphicsConfiguration gc2 =
	    img2.createGraphics().getDeviceConfiguration();
	System.out.println("config1 bounds = "+gc1.getBounds());
	System.out.println("config2 bounds = "+gc2.getBounds());
    }
}
-----------------------------

The bounds for the GraphicsConfig objects really are unrelated to the original
image.  For a screen component, the bounds would be the dimensions of the
screen that it lives on.  For an image, it should probably be the maximum
dimensions supported by the renderering system that is used to render into
those images (MAXINT, MAXINT for the reference runtime probably).

The bug here is not that it reports the information from "another image", but
that the information reported is not useful.
Posted Date : 2009-02-18 02:39:05.0

This still applies with the following java version:

$ java -version
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)

As I had to spent some time to work around this in our software and I'd rather see it fixed in OpenJDK, I wrote a small patch for this problem.

Both test case and bugfix are available here:

http://landschoff.net/hg/openjdk7-fixes/jdk/

The relevant commits are
http://landschoff.net/hg/openjdk7-fixes/jdk/rev/353e6a9b4077  (test case)
http://landschoff.net/hg/openjdk7-fixes/jdk/rev/7ef5c9af9544 (bug fix)
http://landschoff.net/hg/openjdk7-fixes/jdk/rev/38c6db113eb9 (optimization)

I'd be glad if this would be applied to the OpenJDK repositories. 

What's even more funny: At least in JDK6, update 12, setting 

int type = BufferedImage.TYPE_BYTE_INDEXED;

above will suppress the error (happens only for types [0..12])