FULL PRODUCT VERSION :
java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode)

But I had the same problem with 1.4.1 and up to 1.4.2_06

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]


A DESCRIPTION OF THE PROBLEM :
This is a repost of the bug 4749727 which was prematurely
declared fixed for 1.4.2. It *is* fixed in 1.5.0, but not in the 1.4 branch.
The location of the bug in the source is indicated below.

PROBLEM:
The class org.xml.sax.EntityResolver declares resolveEntity()
to throw an IOException.
The SUN Java implementation matches the spec in 1.5.0 but not in 1.4.2

JDK 1.4.2 does not declare the IOException for resolveEntity
JDK 1.5.0 does declare the IOException

The result is that I can't build a filter extending DefaultHandler that
will compile in 1.4.2 and 1.5.0.

The cause of the problem in the 1.4.2 source is evident.
The inconsistency in javadoc should've also raised a warning
to whoever compiled it.

    /**
     * Resolve an external entity.
     *
     * <p>Always return null, so that the parser will use the system
     * identifier provided in the XML document. This method implements
     * the SAX default behaviour: application writers can override it
     * in a subclass to do special translations such as catalog lookups
     * or URI redirection.</p>
     *
     * @param publicId The public identifer, or null if none is
     * available.
     * @param systemId The system identifier provided in the XML
     * document.
     * @return The new input source, or null to require the
     * default behaviour.
     * @exception java.io.IOException If there is an error setting
     * up the new input source.
     * @exception org.xml.sax.SAXException Any SAX exception, possibly
     * wrapping another exception.
     * @see org.xml.sax.EntityResolver#resolveEntity
     */
    public InputSource resolveEntity (String publicId, String systemId)
// throws IOException, SAXException
        throws SAXException
    {
        return null;
    }

As you can see, the more general line is commented out!

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile source code given below with 1.4.2 and 1.5.0 versions of javac.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The correct version is Filter15 and it should compile in 1.4.2 and 1.5.0.
ACTUAL -
Filter14 compiles in 1.4 but not in 1.5, and Filter15 compiles in 1.5
but not in 1.4.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
These result from compiling the test cases below using the Java
version listed above

C:\test>javac Filter15.java
Filter15.java:10: resolveEntity(java.lang.String,java.lang.String) in Filter15 cannot override resolveEntity(java.lang.String,java.lang.String) in org.xml.sax.helpers.DefaultHandler; overridden method does not throw java.io.IOException
    public InputSource resolveEntity(String publicId, String systemId)
                       ^
1 error

C:\test>javac Filter14.java

C:\test>

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.DefaultHandler;
public class Filter14 extends DefaultHandler {
    private final DefaultHandler mFiltered;
    public Filter14(DefaultHandler filtered) {
        mFiltered = filtered;
    }
    public InputSource resolveEntity(String publicId, String systemId)
        throws SAXException {
        return mFiltered.resolveEntity(publicId,systemId);
    }
}
------------------------------------------------------------
import java.io.IOException;
import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.DefaultHandler;
public class Filter15 extends DefaultHandler {
    private final DefaultHandler mFiltered;
    public Filter15(DefaultHandler filtered) {
        mFiltered = filtered;
    }
    public InputSource resolveEntity(String publicId, String systemId)
        throws IOException, SAXException {
        return mFiltered.resolveEntity(publicId,systemId);
    }
}


---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The obvious workaround is a local reimplementation of
DefaultHandler. Not so hard, but a bit ugly.