Question about JDK-6925410

[Frederick Zhang]

Thanks a lot for the prompt response, Alan!

If this is the case I think it's probably better to get the Spring folks
involved. I've submitted a PR [1] to their project to see how they
think about this.

[1] https://github.com/spring-projects/spring-framework/pull/27239

On 4/8/21 5:53 pm, Alan Bateman wrote:
> On 04/08/2021 03:38, Frederick Zhang wrote:
>> Hello everyone,
>>
>> I've got a question about JDK-6925410 [1] and I hope this is the right
>> place to ask.
>>
>> I'm experiencing some slowness when handling XML request bodies in
>> Spring. After digging into the code, it led me to [2] where it
>> instantiates XMLReader upon every request. And the reason of the
>> slowness here seems to be related to JDK-6925410, since after
>> pre-assigning a parser via
>> '-Dorg.xml.sax.driver=com.sun.org.apache.xerces.internal.parsers.SAXParser'
>> the slowness was gone.
>>
>> Although I understand creating new XMLReader instances every time is an
>> anti-pattern, JDK-6925410 mentioned that there was a fix put in place on
>> jaxp's side so I'm wondering what the fix was?
>>
>> I tried downloading relevant sources from [3][4][5] for comparison but
>> some links were broken. Then I checked out the latest JDK code [6] and
>> it's still doing the class scanning but the method has been marked as
>> deprecated. May I know if people are simply suggested to migrate to
>> SAXParserFactory or there's another way of using XMLReaderFactory to
>> avoid the scanning without pre-assigning any parser?
> Yes, this has ben deprecated for many releases. The scanning to locate an XMLReader implementation is specified so I don't think that can be dropped without a specification change and/or coordination with the defunct SAX project. jdk-dev isn't the right place to go into all this. Best to bring a test case to core-libs-dev for discussion.
> 
> -Alan.

-- 
Best regards,
Frederick Zhang

Email: frederick888 at tsundere.moe
PGP:   8BFB EA5B 4C44 BFAC C8EC 5F93 1F92 8BE6 0D8B C11D