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

Daniel D. Daugherty daniel.daugherty at oracle.com
Fri Jul 29 16:06:24 UTC 2016


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 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
>>     <jini.george at oracle.com <mailto:jini.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:
>>     http://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/
>>     <http://cr.openjdk.java.net/%7Esballal/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/4c4af964/attachment-0001.html>


More information about the serviceability-dev mailing list