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 > > > > >
