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
> 

Reply via email to