[9] RFR: 8173390: Investigate SymbolTable in SAXParser

[Aleks Efimov]

Hi Joe,

Thank you for your suggestions. New webrev can be found here:
http://cr.openjdk.java.net/~aefimov/8173390/9/01

Hi Daniel,
You're right that assertNotSame suites better here, i.e. it has nice 
output in case of failure. Because of that I removed the sout.println's 
from the test too.

With Best Regards,
Aleksej


On 15/02/17 20:16, huizhe wang wrote:
> Hi Aleksej,
>
> I just realized there were other dependencies on the SymbolTable 
> instance initialized in the constructor (line 575 in your new code), 
> which was probably why you kept the code from 574 through 579 after 
> adding new SymbolTable for each parsing process (850 - 854). As a 
> result, the SymbolTable will be created twice for the first parsing 
> process. One way to solve the issue is to check whether the 
> SymbolTable instance is new, or otherwise adding a reset function 
> would work as well. In both cases, there will be a bit change to the 
> SymbolTable to expose the count. What would you think?
>
> Thanks,
> Joe
>
> On 2/15/2017 8:31 AM, Aleks Efimov wrote:
>> Hi,
>>
>> Please, help to review the change required by JAXWS-RI code [1]: 
>> SAXParser needs to reset internal SymbolTable to enable pooling of 
>> parsers in SAAJ-RI code. Latest version of JAXWS-RI code (that is 
>> currently under review [2]) doesn't provide a workaround to reset the 
>> symbol table (it was done to remove module dependency on Xerces 
>> internal classes). So the solution is to reset the SymbolTable during 
>> SAXParser reset. The webrev with the changes and simple test that 
>> reproduces SAAJ-RI behavior:
>>     http://cr.openjdk.java.net/~aefimov/8173390/9/00/
>>
>> The fix was tested with all JDK/JCK (JAX[P|B|WS] related tests. No 
>> failures observed.
>>
>>
>> Thank you,
>> Aleksej
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8173390
>> [2] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/046386.html
>>
>