A DESCRIPTION OF THE REGRESSION :
If an unchecked exception is thrown from the InputStream passed to java.awt.Font.createFont(int,InputStream), then a temporary file created by that method fails to be deleted. Further the file is not deleted when JVM exits.

  From Bug #6189812 (Java2D: createFont temporary font files still open on exit aren't removed on windows), I assume this is only a regression on Linux and Solaris.

REPRODUCIBLE TESTCASE OR STEPS TO REPRODUCE:
Check that you have no temporary font files on your system (e.g. with `echo /tmp/+~JF*.tmp`). Run the program below. Check again for temporary font files.

class CreateFontFileLeak {
    public static void main(
        String[] args
    ) throws java.io.IOException, java.awt.FontFormatException {
        class UncheckedException extends RuntimeException {
        }
        java.io.InputStream in = new java.io.InputStream() {
            public int read() {
                // Fluffed in someway.
                // Could, for instance, dereference a null returned by
                // Class.getResourceAsStream.
                throw new UncheckedException();
            }
        };
        try {
            java.awt.Font.createFont(java.awt.Font.TRUETYPE_FONT, in);
            throw new AssertionError("Should have thrown exception");
        } catch (UncheckedException exc) {
            // As expected.
            return;
        } finally {
            in.close();
        }
        // Unreachable.
   }
}

RELEASE LAST WORKED:
5.0 Update 6

RELEASE TEST FAILS:
mustang-b69

OBSERVED APPLICATION IMPACT:
There a larger variety of unchecked exceptions. For instance programming errors, such NullPointerException, and common abnormal conditions such as OutOfMemoryError. An application using this method may therefore be found to leak files, but for reasons that are difficult to pinpoint. As the FileOutputStream is not handled correctly, potentially the number of file handles available could be reduced until the garbage collector and finaliser do their job.

More seriously for users, a malicious, unsigned applet or JNLP/WebStart may abuse the feature. An arbitrary quantity of disc storage may be used up, which is not freed when the JVM exits. Further, with large numbers of file created, file names will become predictable. Combined with flaws of other software present on the system, this may allow an attacker executed foreign code as trusted.