On 03/02/2014 21:13, Martijn Verburg wrote:

Hi Huizhe,

Is there a possibility to look at having a more loosely coupled relationship between Xerces and what is core JDK? I'm thinking about (in combination with) Jigsaw that you could allow the Xerces components to be kept up to date more often (assuming API compatibility etc is retained).

Just to mention that are already service provider interfaces so you can deploy with other parser libraries (or a more up to date Xerces). One of things that we did as part of preparing for modules (JEP 162, JDK 8) was to rev the JAXP API to clean up these the service provider interfaces (for SAX, DOM, XSLT, XPath, Validation, Streaming, Datatype) and specify the use of the ServiceLoader. So we're in a much better place now. As regards getting the Xerces code in OpenJDK in sync with the upstream project then that clearly would be desirable and probably more of a longer term goal. I'll let Joe speak to how much the code has diverged but one area of difference is that the original Apache code wasn't really intended to ever be on the boot class path or run with a security manager. In any case, I think this JEP is a good step as it brings the implementations closer and also revs the support on a number of standards. -Alan

Makes sense - thanks for the extra explanation! Cheers, Martijn On 3 February 2014 22:49, Alan Bateman <Alan.Bateman@oracle.com> wrote:

On 03/02/2014 21:13, Martijn Verburg wrote:

...

Hi Huizhe,

Is there a possibility to look at having a more loosely coupled relationship between Xerces and what is core JDK? I'm thinking about (in combination with) Jigsaw that you could allow the Xerces components to be kept up to date more often (assuming API compatibility etc is retained).

Just to mention that are already service provider interfaces so you can deploy with other parser libraries (or a more up to date Xerces). One of things that we did as part of preparing for modules (JEP 162, JDK 8) was to rev the JAXP API to clean up these the service provider interfaces (for SAX, DOM, XSLT, XPath, Validation, Streaming, Datatype) and specify the use of the ServiceLoader. So we're in a much better place now.

As regards getting the Xerces code in OpenJDK in sync with the upstream project then that clearly would be desirable and probably more of a longer term goal. I'll let Joe speak to how much the code has diverged but one area of difference is that the original Apache code wasn't really intended to ever be on the boot class path or run with a security manager. In any case, I think this JEP is a good step as it brings the implementations closer and also revs the support on a number of standards.

-Alan

Thanks Martijn, Mario and Sean for the comments and Alan for the explanation. The Xerces implementation has forked mainly in the following areas: 1. integration The JDK StAX implementation shared the same scanner with that of SAX/DOM parsers. This part of code has been significantly modified. 2. JDK specific requirement As Alan already commented, the original Xerces implementation was not designed to be on the boot class path. There are therefore changes that are specific to meet the JDK's requirement. We do share the improvement, but the eventual changes in Xerces were made by the Xerces team and may be different. 3. JDK support Yes, Xerces still supports JDK 1.4. JAXP and JAXP in JDK however no longer supported JDK 1.4 since 2009, that allowed us to have introduced changes that used features from JDK 5. JAXP 1.6/JDK8 and later are now at source level JDK 6 and above since the ServiceLoader was introduced in JDK 6. It is desirable to get the sources in sync. As Alan said, this update is a good step towards that goal. JAXP 1.6/JEP 162 and JDK9 provide opportunity for us to look further. We shall keep in this in mind in any future changes. Thanks, Joe On 2/3/2014 2:08 PM, Sean Mullan wrote:

On 02/03/2014 02:19 PM, huizhe wang wrote:

...

The JDK contains an older Xerces implementation, version 2.7.1. Although there were updates in JDK 7 to bring in some changes, we did not bring it completely up to date to any later release. The goal of this JEP is to complete the update and bring the JDK to Xerces' latest release, 2.11.0.

Xerces 2.11.0 supports JDK 1.4.2 (!) and up. I am curious if you intend to avoid using newer language features or APIs in the JDK implementation so that you can stay closely in-sync and integrate future updates more easily?

--Sean