[concurrency-interest] Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated]

[David Holmes]

I don't think we should be looking at changing the current behaviour at 
all. Certainly not for JDK7 (rfe for 8 perhaps?)

I think the most we can do with the spec is add cautionary 
(non-normative) notes.

David

Rémi Forax said the following on 12/23/10 02:49:
> On 12/22/2010 04:55 PM, Chris Hegarty wrote:
>> On 12/22/10 03:34 PM, Gregg Wonderly wrote:
>>> On 12/22/2010 9:10 AM, Chris Hegarty wrote:
>>>> On 12/22/10 03:07 PM, Rémi Forax wrote:
>>>>> On 12/22/2010 02:45 PM, Chris Hegarty wrote:
>>>>>> Have we thought about catching/swallowing these exceptions?
>>>>>
>>>>> What do you want to do in the catch block ?
>>>>
>>>> Would it make sense to simply swallow the exception ( do nothing ) and
>>>> continue
>>>> with the next element? Clearly if contains() throws and Exception then
>>>> the
>>>> collection does not contain the given element?
>>>
>>> It seems that Logger use here might be useful. A FINE level log of the
>>> stack trace would allow the user to discover why the failure/success
>>> return was not as they expected. From some perspectives, I'd be tempted
>>> to log at WARNING for myself as this does represent an unexpected, yet
>>> non-fatal condition in the software.
>>
>> Yes, this is a good proposal. I guess we need to establish whether we 
>> consider passing these "incompatible" collections a programmer error 
>> or not. I was just trying to ensure that we had considered all options.
>>
>> -Chris.
> 
> The main problem with logging is that you may see a lot of records
> if the application compares huge of collections of turtles and nipples 
> (i.e collections of incompatible type)
> Moreover if a code relies on catching a CCE in that case, if we log or 
> silently ignore the CCE,
> the performance will drop.
> 
>>
>>>
>>> Gregg Wonderly
> 
> Rémi