Hi Seán,
On 6/11/13 10:31 AM, Seán Coffey wrote:
Thanks for the background information Joe. Can you run this by the CCC
team then ? (log a request for jdk7u)
In the CCC I had mentioned our intent to backport the fix to
jdk7u-dev - but maybe that went unnoticed...
-- daniel
regards,
Sean.
On 10/06/2013 23:13, huizhe wang wrote:
Hi Sean,
It was on my request that Daniel took the trouble to make the
backports on this and several of his previous JDK8 changes. Past
experience with 6u during jdk7 development showed that it was very
beneficial keeping the two in sync.
For this particular one, the behavioral change exists only
theoretically. The original implementation allowed plugging-in a
third party impl of DTMManager and/or XSLTCDTMManager, but it has
become an obsolete design. The only known impl was in an old version
of IBM SDK that was for IBM only. In reality, the plugin layer is
most often a performance drag and people actually set a System
Property to point to the default JDK implementation to avoid reading
the service file.
So I think this change is beneficial to JDK7. It's a performance
improvement. It helps keeping it in sync with JDK8 source. It also
removes lot of obsolete, unused code.
Thanks,
Joe
On 6/10/2013 9:44 AM, Seán Coffey wrote:
Daniel,
this looks like a behavioural change in an update release. I see you
logged a CCC for JDK 8 only.
I don't believe it's suitable for 7u integration. Alan, Joe - any
thoughts ?
regards,
Sean.
On 10/06/13 10:56, Daniel Fuchs wrote:
Hi,
This is a request for approval to backport JDK-8013434 to
jdk7u-dev.
With this changeset, DTMManager and XSLTCDTMManager will always use
their own default implementation.
JDK 8 Review thread:
<http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017606.html>
Bug URL:
<https://jbs.oracle.com/bugs/browse/JDK-8013434>
JDK 8 Changeset:
<http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e93beba07830>
The backport to jdk7u-dev is a simple hg import of the jdk8 changeset.
-- daniel
