RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME

[Joe Wang]

On 11/17/16, 1:50 PM, Langer, Christoph wrote:
>
> Hi Joe,
>
> thanks for the clarification about formatting. It was particularly 
> good for me to learn about the line in between license header and 
> package name as I was not sure whether it should exist or not. I'll 
> update my outstanding webrevs with that regards. And I'll keep going 
> to do formatting and warnings cleanups as I go...
>

Thanks!  That helps a lot. We had over 5000 warnings, hopefully we'd get 
rid of them all over a period of time.

Best,
Joe

> Best regards
>
> Christoph
>
> *From:*Joe Wang [mailto:huizhe.wang at oracle.com]
> *Sent:* Donnerstag, 17. November 2016 20:58
> *To:* Lance Andersen <lance.andersen at oracle.com>
> *Cc:* core-libs-dev at openjdk.java.net; daniel Fuchs 
> <daniel.fuchs at oracle.com>; Langer, Christoph <christoph.langer at sap.com>
> *Subject:* Re: RFR (JAXP) 8158619: Very large CDATA section in XML 
> document causes OOME
>
> Thanks Lance, Daniel, and Christoph.  I adopted the changes as suggested.
> http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ 
> <http://cr.openjdk.java.net/%7Ejoehw/jdk9/8158619/webrev/>
>
> The changeset has been in my workspace for over a month now. So it's 
> good to get it out of the way.
>
> On raw type, other warnings and obsolete code:
>       we made the top 3 in terms of the number of warnings. We're 
> trying to correct that as we go with fixing a small set at a time 
> within the scope of the current change. It's not being ideal since 
> often times we have to stop where it affects the signatures (or have 
> to expand to other classes). Eventually, we'd have to bite the bullet 
> and conduct a complete overhaul of the code.  I actually did it in the 
> jaxp standalone repo with regard to the obsolete types, but it was 
> lost in the middle of transition during the jdk7.
>
> On format, I agree with Daniel, we can at least fix the very-long 
> lines near the changes, and not to introduce new ones. For other 
> formats, it's tempting to just hit the NetBeans - format function. But 
> then, it'd generate a huge amount of changes that could make it 
> difficult for the reviewers.  One thing we could do is not to include 
> format changes in webrevs, and instead just make a note that 
> NetBeans-format will be done before check-in. But even that might be 
> unnecessary since it would make it hard to trace back changes in the repo.
>
> After all is said (about format), we are unfortunately to live with 
> the messy format we inherited, but we shall fix the long lines though.
>
> **it's interesting to note that NetBeans-format will remove the line 
> between License header and package name, which is required by the 
> Licencing tool**
>
> Thanks,
> Joe
>
> On 11/17/16, 5:43 AM, Lance Andersen wrote:
>
>     Hi Joe,
>
>     Overall looks good.
>
>     I agree with Daniel that you might want to reconsider
>     reworking JdkXmlUtils.getValue to make it a bit more robust incase
>     of an surprise Object passed for value.
>
>     HTH
>
>     Best
>
>     Lance
>
>         On Nov 16, 2016, at 5:12 PM, Joe Wang <huizhe.wang at oracle.com
>         <mailto:huizhe.wang at oracle.com>> wrote:
>
>         Hi,
>
>         Please review an enhancement adding a property to allow for
>         specifying the chunk size of CDATA.
>
>         JBS: https://bugs.openjdk.java.net/browse/JDK-8158619
>         webrevs:
>         http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/
>         <http://cr.openjdk.java.net/%7Ejoehw/jdk9/8158619/webrev/>
>
>         Thanks,
>         Joe
>
>     <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.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>