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

[Anthony Petrov]

Hi Jeff,

On 7/15/2009 10:06 PM Jeff Dinkins wrote:
>>> though I prefer to minimize calling Swing stuff from AWT code. What 
>>> do others think?
>>
>> let's wait for the rest of the team
> 
> Is there any awt code that calls into swing already? (not including any 
> peer impls)
Yes, as Alex already mentioned, see, for instance, the 
Component.AccessibleAWTComponent.getAccessibleStateSet(). Also, see 
Window.setLayeresOpaque(). Still, all this looks quite awkward, 
especially when it comes to implementing a Swing's method specification 
in the AWT's code.

--
best regards,
Anthony

> 
> jeff
> 
>>
>> 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
>>>>
>>
>