We just announced that we no longer support JDK 1.4 in JAXP standalone builds. The main motivation was that we found such requirement made it hard to maintain a synchronized source with JDK6. Recently, we have made some performance improvements which will be in the jdk6 update 14 release. Due to the requirement for supporting JDK 1.4 however, we couldn't put back the same changes we made in jdk6 since features such as generics, StringBuilder were not available in JDK 1.4.

Another consideration was that J2SE 1.4.2 has reached its End of Service Life (EOSL) on October 30th, 2008. It is no longer necessary for JAXP standalone to support JDK 1.4.

So download JAXP 1.4 Weekly or Nightly and give it a test. Our performance team's tests using SPECjvm2007/SPECjvm2008 have shown tremedous performance improvement in certain areas. Besides, there have also been critical fixes such as 6536111 SAX parser throws OutOfMemoryError and 6506304 java.net.MalformedURLException: unknown protoco: c which have "earned" many votes and comments demanding a fix on SDN. These fixes will also be included in JDK6 update 14.

An issue (sjsxp issue 43) Tatu posted on SJSXP sparked a lot of dicussions in the JAXP Dev mailing list. The main observations on this part of specification are that it lacks the clearness on default encoding, the order of preference among the default, that set when the writer is constructed, and that set by calling writeStartDocument on the XMLStreamWriter or createStartDocument on XMLEventFactory. Also, the specifications of the writeStartDocument methods on XMLStreamWriter do not align well with the createStartDocument methods on XMLEventFactory. I've recorded the findings and added proposal 1 for each section on the StAX.next Discussion page. Please feel free to join our discussion and suggest your proposals.

Thanks.

I recently revisited the release notes for JAXP 1.4.0 and 1.4.1 and felt it's neccessary to update the compatibility guide to give it a more complete description about the current implementation of this feature.

Many of you are already familiar with this feature. But I thought it might be beneficial to people who newly come to JAXP or want to use the default XML processing in J2SE 6.

The secure feature, with a keyword FEATURE_SECURE_PROCESSING, was added in JAXP 1.3/J2SE 5 as described in the compatibility guide. The feature was designed to mitigate security risk exposed by using entity resolution and large constructs that may result in Denial-of-service attack. When the feature is turned on, default limitations are applied to entity expansion (default 64,000) and number of element attributes (10,000). These numbers were experimental in that they were tested on a general platform as having acceptable performance. Users may perform their own tests and reset the limitations. Refer to the Feature for Secure Processing section of the compatibility guide on how to reset the limitations.

Another restriction under the security feature was about extension functions. This security feature can be turned on and off using the factories. Again, please refer to the Feature for Secure Processing section of the compatibility guide.

In JAXP 1.4/J2SE 6, the security feature is turned on by default for DOM and SAX parsers. That is, the JAXP 1.4 RI sets default limitations to entity expansion and number of element attributes. JAXP 1.4 also added a limitation to maxOccur in XML schema as described in JAXP 1.4 Release Notes. The limit to maxOccur was set by default to 5,000. Again, this is experimental number with a reasoning that it happens very rarely in practical applications.

Going forward, we're re-evaluating the current security implementation and thinking that some enhancement might be neccessary. We would love to hear your experiences in securing your application and any comments on this topic. Here's a link to the JAXP Forum. Thanks.

JAXP 1.4.1 is the first patch release for JAXP 1.4 FCS which was released on Oct. 31, 2006. The JAXP team has worked actively with the community and teams within Sun to have brought many changes and fixes into the code base over the last 5 months. It's a great pleasure to announce the release and availability of the 1.4.1 stable build for download.

I would like to take this opportunity to thank everyone who has helped make this release possible. Thanks to the JAXP community, The Java Technology and XML community, as well as the SJSXP community who have contributed to this project.

On another note, to better serve our community, we have just created the JAXP forum under the Java Web Services and XML category. We'd like to welcome you to participate!

Thanks to Jeffrey who brought up the backward compatibility issue of the 1.0.1 release build. We've decided to make it consistent to the JAXP builds and ensure backward compatibility with JDK 1.4. I have just updated both the 1.0.1 release and latest builds in the download area. Thanks.

Sun Java Streaming XML Parser (SJSXP) 1.0.1 has been released on Feb. 14, 2007 and is available for download on Java.net.

The 1.0.1 release is the first since the SJSXP 1.0 FCS on April 11,2006. Thanks to the SJSXP Java.net community and our web services teams, we have been able to provide many updates and fixes to the technology. For a complete change log, please refer to the 1.0.1 Changelog. Among them, there were several issues that all pointed to the Filtered StreamReader. As a result, we've re-written the implementation. I thought it's therefore worth mentioning here.

As we've discussed in the Release Notes, there were two main issues in implementing the filtered stream reader. That is:
(1) On initiating a Filtered StreamReader, should the reader move to an acceptable filtered event?
(2) should the hasNext() method advance the stream in order to test if there is a "next" event?

We've decided to implement "yes" and "yes" to the above questions. The understanding was that hasNext should return an event accepted by the filter, which meant it had to search the stream for one. It might fail a special use case where the underlining stream might be called. But it satisfies usual use cases such as the "while hasNext; get next" pattern. Most important of all, the implementation passes the new TCK completely. We're hoping that this would be addressed when the JSR 173 Maintenance Release 1.1 opens up. We'd appreciate your comments.