RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation

Jini Susan George jini.george at oracle.com
Fri Jul 29 12:35:23 UTC 2016


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 at 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 <HYPERLINK "mailto:jini.george at oracle.com" \njini.george at 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: HYPERLINK "http://cr.openjdk.java.net/%7Esballal/sponsorship/8068004/webrev.00/" \nhttp://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/

Thanks,

- Jini Susan George

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160729/76892fbb/attachment.html>


More information about the serviceability-dev mailing list