With the change to stringbuilder I am ok with it Best Lance
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad On Mar 26, 2014, at 1:44 PM, Aleksej Efimov <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> >> 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> >>> 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/~aefimov/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 >> >> <mime-attachment.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 >