<Swing Dev> Review request: 6852592 (revalidate() must be smarter)

[Anthony Petrov]

One more concern that comes to my mind is that the logic stated in the 
Swing's method specification is going to be implemented on the AWT's 
side, which I don't like much. So definitely we need more opinions on 
this proposal.

--
best regards,
Anthony

On 7/15/2009 8:16 PM Alexander Potochkin wrote:
> Hello Anthony
> 
>>> Can we do the same for isValidatRoot()?
>> Yes, that is a smaller solution (in terms of the code size), 
> 
> smaller fix is less error-prone
> and gives better maintainable code for future changes
> 
>> though I prefer to minimize calling Swing stuff from AWT code. What do 
>> others think?
> 
> let's wait for the rest of the team
> 
> Thanks
> alexp
> 
>>
>> -- 
>> best regards,
>> Anthony
>>
>>>
>>> Thanks
>>> alexp
>>>
>>>> Hello Swing and AWT teams,
>>>>
>>>> This is a fix for the problem discussed recently (see the thread 
>>>> "Lw/Hw mixing vs revalidate()/validate()/invalidate()"). The webrev:
>>>>
>>>> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.0/
>>>>
>>>> Please review.
>>>>
>>>> A couple of notes:
>>>>
>>>> 1. We need to get a CCC approval for the API specification changes. 
>>>> This will take some time.
>>>>
>>>> 2. The Container.invalidate() previously had a block of code that 
>>>> was executed w/o grabbing the TreeLock (a call to the 
>>>> LayoutManager2.invalidateLayout())). Now the code is moved to the 
>>>> invalidateImpl() which is always invoked under the TreeLock. This 
>>>> doesn't seem to be a problem: actually only the initial call to the 
>>>> Container.invalidate() ran the code off the lock. All subsequent 
>>>> recursive calls to this method did in fact happen under the lock. 
>>>> Therefore I assume that this change is OK.
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>
>