The changes submitted for Maintenance Review were withdrawn on 8 September 2006. with the following explanation:

The initial intent of the requested 1.1 MR of JSR 173 was to quickly resolve (for proposed inclusion into Java SE 6.0 "Mustang" release) a long standing and unfortunate 'cut and paste' bug that occurred in the 1.0 specification/RI javadoc for the XMLOutputFactory.newInstance(String, ClassLoader) method, wherein it erroneously returned a type of XMLInputFactory and not XMLOutputFactory as intended.

The proposed 1.1 MR 'fix' was to simply redefine the the return type of the static method to be the correct one, i.e XMLOutputFactory.

At the time of initiating this MR request it was the generally held belief that despite introducing an incompatible change in the API, the StAX community werre long aware of the issue, the API as erroneously specified was 'nonsensical' and therefore it was unlikely that should any StAX implementation have followed the spec, no StAX application would invoke it. Thus it was assessed that the risk associated with this incompatible change was minimal, and the MR was proposed as such.

Subsequent to the submission further discussion has occurred and it has been observed that should this change occur we would violate a invioable principle that the Java platform and JCP has strived to maintain; that no incompatible changes shall occur.

As proposed, should a class compiled against the proposed MR 1.1 API subsequently execute in an environment containing a compliant (and therefore buggy/different) 1.0 implementation of this API, the JVM would throw an NoSuchMethodError when it attempted to resolve the symbolic reference to the (1.1 specified) method (contained in the constant pool of the referencing class file) against the 1.0 class/method definition.

This error mode is specified by the semantics of the invokestatic bytecode [see JVM specification, 2nd Edition page 288 'invokestatic' bytecode definition and section 5.4.3.3].

Under these circumstances, and despite the assment of a minimal risk of this actually occurring, it is agreed that to continue is inappropriate and may set a highly undesirable precedent for the Java platform and the JCP.

We therefore respectfully withdraw this MR proposal.

It is the intent of the Maintainance Lead to shortly re-open this JSR to the broader StAX community for the consideration of this, and the resolution of other issues with the StAX 1.0 specification, to form the basis of a more general MR release, with it's own schedule, not tied to either Java EE 5.0 or Java SE 6.0 release schedules, but also intent on delivering a quality MR back to the community in a timely fashion.

Further it is proposed that in order to resolve this particular issue; this new MR will contain a change which will deprecate both XMLOutputFactory.newInstance(String, ClassLoader) and XMLInputFactory.newInstance(String, ClassLoader) and replace both methods with new (symmetric) static methods that, in the case of XMLOutputFactory, return the correct type.

Comments to: jsr-173-comments@jcp.org