Code review request, JDK-8010814, More buffers are stored or returned without cloning

Weijun Wang weijun.wang at oracle.com
Tue May 21 03:36:15 UTC 2013



On 5/16/13 5:52 PM, Xuelei Fan wrote:
> On 5/16/2013 5:22 PM, Weijun Wang wrote:
>> Hi Xuelei
>>
>> I'm busy on something else, so probably have no time (or cannot
>> concentrate) to read in details.
>>
> Not urgent fix, so please review these request only when you available.
>
>> In my opinion, there are several cases as to whether to clone or not:
>>
>> 1. MUST NOT clone, because the value must be shared so that change at
>> one side appears on the other side.
>>
>> 2. MUST clone, public available methods that leads to security issues.
>>
>> 3. So so, although public methods, cannot be used to do bad things.
>>
>> 4. Not an issue. Internal methods.
>>
>> In the patch, are the first two cases #1 or #3.
>>
> It's #2.

I mean the cases in BerDecoder and BerEncoder. You only add comments

    // shared buffer, be careful to use this class

>
> For #1 and #3, I added a few comment lines in 8010815.
>
>> Sorry I also have no time to read
>>
>>    JDK-8010814, More buffers are stored or returned without cloning
>>    http://cr.openjdk.java.net/~xuelei/8010815/webrev.00/
>>
>> but I am not sure if those env cases belong to #1.
>>
> I think both fixes are for #2.

I'm not sure.

Take Continuation for example, the class is used to continue a previous 
method. For me it looks like the environment should be shared between them.

Can you give an example that shows the environment should not be shared?

Thanks
Max


>
> Xuelei
>
>> Thanks
>> Max
>>
>>
>> On 5/16/13 5:08 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> There is another fix to avoid the use of mutable objects.
>>>
>>> webrev: http://cr.openjdk.java.net/~xuelei/8010814/webrev.00/
>>>
>>> Thanks,
>>> Xuelei
>>>
>



More information about the core-libs-dev mailing list