Agreed that it could be considered as a defense-in-depth fix. But, in this case Page data could be huge. I think it was not cloned in first place to avoid copying many big byte[] instances around.
-Sundar On 7/29/2016 9:36 PM, Daniel D. Daugherty wrote: > Two points: > > 1) if Findbugs reports the same issue on JDK9 code, then we want to > address such that we reduce any Findbugs noise > > 2) Fixing it could be considered to be a defense-in-depth change. > > Dan > > > On 7/29/16 7:19 AM, Sundararajan Athijegannathan wrote: >> Well, we can't code for that kind of overrides - Findbugs or any such >> tool is about normal mode of execution. With that argument, people >> can override classes using -Xpatch option as well! >> >> -Sundar >> >> On 7/29/2016 6:05 PM, Jini Susan George wrote: >>> >>> Thank you, JB and Sundar. Sundar, would that hold true even if >>> –XaddExports is used ? >>> >>> >>> >>> Regards, >>> >>> Jini. >>> >>> >>> >>> *From:*Sundararajan Athijegannathan >>> *Sent:* Friday, July 29, 2016 5:11 PM >>> *To:* serviceability-dev@openjdk.java.net >>> *Subject:* Re: RFR: (XS): JDK-8068004: >>> [Findbugs]sun.jvm.hotspot.debugger may expose internal representation >>> >>> >>> >>> If cloning is done to avoid exposing byte[] outside SA, this fix is >>> not needed in jdk9. In jdk9, none of the SA packages are exposed and >>> code outside SA cannot access this. Besides, Page data may be very >>> big - cloning that ever constructor and getter may be too costly. >>> >>> -Sundar >>> >>> >>> >>> On 7/29/2016 5:07 PM, Jaroslav Bachorik wrote: >>> >>> Hi Jini, >>> >>> >>> >>> 'null' seems to be a valid value for 'data' field in both of the >>> places you are using 'data.clone()' - you should guard for null >>> and call 'clone()' only if the passed in value is non-null. >>> >>> >>> >>> Cheers, >>> >>> >>> >>> -JB- >>> >>> >>> >>> On Fri, Jul 29, 2016 at 11:29 AM, Jini Susan George >>> <jini.geo...@oracle.com <mailto:jini.geo...@oracle.com>> wrote: >>> >>> Hi all, >>> >>> Please review the fix for the following SA defect (to avoid >>> exposing internal representations by storing or returning >>> externally mutable objects directly). >>> >>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8068004 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/ >>> <http://cr.openjdk.java.net/%7Esballal/sponsorship/8068004/webrev.00/> >>> >>> Thanks, >>> >>> - Jini Susan George >>> >>> >>> >>> >>> >> >
