Lazy JSR spec writers

Can’t believe the JSR 173 spec writers were so lazy!

When did you last feel like flagellating a JSR editor? Well, Chris Fry (BEA) and his team of JSR 173 expert group members definitely deserve this rich reward for a stupid mistake of copy-and-paste. You’d say we all do that some time or the other. In this case, the spec has produced a lingering result due to the copy-and-paste error.

Copy-and-paste

The StAX API uses the standard service provider initialization techniques and requires that users beseech the “standard” factories for an instance of various XML factory classes. Lazily enough, the spec editors copied a method to instantiate the InputFactory and used it ditto for instantiating the OutputFactory. 

Only that they forgot to change the signature of this method, so it also returns an InputFactory.

So the code for:

public static XMLInputFactory newInstance(String factoryId,  
ClassLoader classLoader)
throws FactoryConfigurationError {
return (XMLInputFactory) FactoryFinder.find(
factoryId,
"com.bea.xml.stream.MXParserFactory",
classLoader);
}

was copied as:

public static XMLInputFactory newInstance(String factoryId,
ClassLoader classLoader)
throws FactoryConfigurationError {
return (XMLInputFactory) FactoryFinder.find(
factoryId,
"com.bea.xml.stream.XMLOutputFactoryBase",
classLoader);
}

Don’t believe me? Then take a look for yourself.

Why am I complaining now?

I am working with this library in an OSGi run time, where I have to use this two-arg factory creation. But I can’t quite do this with the existing StAX API and I don’t see any existing fix for this BUG. Sun closed a bug filed for this in August 2005 saying that the spec needs to be changed and they can’t do anything. Codehaus recorded a bug in September 2005 that has yet to be worked on. Seems like the Extreme Lab at Indiana is tracking this issue as well to make it a part of some maintenance release.

Are you working with an alternative for pull parsing that works better with large amounts of character data? Let me know…

Tags:

Add a Comment

Your email address will not be published. Required fields are marked *