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 modifi
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
Makes sense - thanks for the extra explanation!
Cheers,
Martijn
On 3 February 2014 22:49, Alan Bateman 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?
Il 03/feb/2014 22:50 "Alan Bateman" ha scritto:
> 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.
Indeed!
Mario
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 (as
Yes,
And it would be even nicer if we could get some of the patches integrated
upstream so that it could be eventually possible to not maintaining this
code, but instead use upstream bundles directly.
Not sure how this could be done, but would be awesome.
Cheers,
Mario
Il 03/feb/2014 22:14 "Mart
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).
Ch
