Why the NPE using static method of DatatypeConverter?

Question

I have stared at this short code too long, and cannot for the life of me see how it can throw a NullPointerException on line 6. Why the NPE?

cl         


        

Answer 1

public static String printBase64Binary( byte[] val ) {
    return theConverter.printBase64Binary( val );
}

JAXB Providers are required to call the setDatatypeConverter api at some point before the first marshal or unmarshal operation (perhaps during the call to JAXBContext.newInstance). This step is necessary to configure the converter that should be used to perform the print and parse functionality

Try setting the converter first

/**
     * This method is for JAXB provider use only.
     * <p>
     * JAXB Providers are required to call this method at some point before
     * allowing any of the JAXB client marshal or unmarshal operations to
     * occur.  This is necessary to configure the datatype converter that 
     * should be used to perform the print and parse conversions.
     * 
     * <p>
     * Calling this api repeatedly will have no effect - the 
     * DatatypeConverterInterface instance passed into the first invocation is 
     * the one that will be used from then on.
     * 
     * @param converter an instance of a class that implements the 
     * DatatypeConverterInterface class - this parameter must not be null.
     * @throws IllegalArgumentException if the parameter is null
     */
    public static void setDatatypeConverter( DatatypeConverterInterface converter ) {
        if( converter == null ) {
            throw new IllegalArgumentException( 
                Messages.format( Messages.CONVERTER_MUST_NOT_BE_NULL ) );
        } else if( theConverter == null ) {
            theConverter = converter;
        }
    }

Answer 2

Without the specifics of the environment I cannot be certain this is the case but if you are using JAXB RI then it's possible that you are running into the issue described by this JAXB bug: http://java.net/jira/browse/JAXB-761.

While the bug doesn't specifically address the issue you were having (it is related to the parseDate method), the root cause may be the same. It was detected in version 2.2.1 of JAXB but may have been there beforehand in 2.1.x versions, and JAXB 2.1.1 appears to be the most recent release integrated into 1.6 (integrated in 1.6u14).

The issue states that it was resolved with JAXB 2.2.4, which was integrated into 1.7.

Additional note - a related issue was documented regarding a NPE for parseBoolean when attempting to use with 1.6u31 which may be of interest (though little help, the description is very short): http://java.net/jira/browse/JAXB-902. This suggest this could still be an ongoing issue depending on if you are using RI or another JAXB implementation.

Answer 3

It seems as though there are bugs in JAXB within JDK7 right now, as evidenced by this issue on Camel:

https://issues.apache.org/jira/browse/CAMEL-4893

which ultimately links to this issue https://github.com/javaee/jaxb-v2/issues/860 in the JAXB project on java.net.

I'm not entirely sure if you are running into this same thing or not, but perhaps try using JDK6 with the latest JAXB version there and see if the same NPE happens or not.