Lance, thank you for the review.
Aleksej
On 03/28/2014 03:33 PM, Lance @ Oracle wrote:
With the change to stringbuilder I am ok with it
Best
Lance
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance
Andersen| Principal Member of Technical Staff | +1.781.442.2037
<tel:+1.781.442.2037>
Oracle Java Engineering
1 Network Drive <x-apple-data-detectors://34/0>
Burlington, MA 01803 <x-apple-data-detectors://34/0>
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Sent from my iPad
On Mar 26, 2014, at 1:44 PM, Aleksej Efimov <aleksej.efi...@oracle.com
<mailto:aleksej.efi...@oracle.com>> wrote:
Lance,
The document implementation (DocumentImpl) returned by
'builder.newDocument()' should implement org.w3c.dom.Node and
org.w3c.dom.Document interfaces, but shouldn't have the
'getXmlVersion' method (in Node, Document and DocumentImpl) - it's a
main item required by Apache bug. So it means, that we need to
substitute all three classes (Document,Node and DocumentImpl). The
test should be executed with JDKs Node, Document, but DocumentImpl
should be compiled against incorrect interfaces. I don't see, how I
can implement it with jtreg keywords (the main problem is splitting
the compilation of DocumentImpl (fake Node, Document) and the test
run (only fake DocumentImpl).
The only reason why StringBuffer is not used here - the process of
how updates were moved from Xerces to JAXP: revision by revision. And
I don't think that it should prevent us from replacing it with faster
StringBuilder =). Will change it to StringBuilder.
Thank you,
Aleksej
On 03/26/2014 09:04 PM, Lance Andersen wrote:
Any reason not to use StringBuilder in place of StringBuffer
in XMLEntityManager.java
other than the above and my question on the need of using run.sh, it
is OK
On Mar 26, 2014, at 12:54 PM, Lance Andersen
<lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>> wrote:
Hi Aleksej,
Do you really need to use run.sh? If possible it would be better
to try and avoid providing a script and use the jtreg keywords.
Best
Lance
On Mar 26, 2014, at 12:39 PM, Aleksej Efimov
<aleksej.efi...@oracle.com <mailto:aleksej.efi...@oracle.com>> wrote:
Hello,
Can I ask for a review for the update of DOMSerializerImpl class
[1] to the latest Apache Xerces implementation.
The following changes were made:
1. The DOMSerializerImpl update: The Xerces class was used as a
base [2]; the 476047 and 473125 revisions from Xerces was
excluded (they will be resolved as a part of JDK-8035467 - move to
Xalan serializer bug); the jaxp 632 revision was applied to new
version of this class.
2. The DOMSerializerImpl.java file was reformated, because of
not-good formatting in original file from Apache repo [2].
3. Other changes related to the DOMSerializerImpl update were
applied from Xerces repo to JDK(the full revisions list can be
found in the JBS [1]).
4. All license headers were updated to the latest version of
Apache header in modified files.
5. New regression test was added to reproduce a problem described
in Apache bug XERCESJ-1007 [3].
Webrevs for these changes:
http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jaxp
<http://cr.openjdk.java.net/%7Eaefimov/8035437/webrev.00/jaxp>
http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jdk
<http://cr.openjdk.java.net/%7Eaefimov/8035437/webrev.00/jdk>
Testing:
JCK tests (api/xsl api/xinclude api/javax_xml api/org_xml
xml_schema): pass
JTREG tests (javax/xml, jdk_other): pass
Thank you,
Aleksej
[1] https://bugs.openjdk.java.net/browse/JDK-6339023
[2]
http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xml/serialize/DOMSerializerImpl.java?revision=944789&view=markup
[3] https://issues.apache.org/jira/browse/XERCESJ-1007
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
<mime-attachment.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance
Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
