<AWT Dev> [8] Review request for 6847588: AWT test fails
Anthony Petrov
anthony.petrov at oracle.com
Thu Jun 13 04:43:34 PDT 2013
Hi Anton,
Indeed, this looks like another valid reason to stick with the
AWTAccessor.getPeer in this case. So I'm still supporting your original fix.
--
best regards,
Anthony
On 06/13/13 12:39, Anton Litvinov wrote:
> Hello Sergey and Anthony,
>
> Thank you very much for review of this fix. Anthony, thank you for
> approval of the current version of the fix and defending your position
> concerning appropriateness of usage of
> "sun.awt.AWTAccessor.ComponentAccessor.getPeer" method in this case.
>
> Since there was not reached an agreement about usage of either "getPeer"
> or "targetToPeer" method in your discussion, I would like to provide one
> argument against "targetToPeer" method in this case. The method
> "sun.awt.AWTAutoShutdown.getPeer" which will be called, if
> "targetToPeer" approach is used, will introduce acquiring of two
> different locks in "XKeyboardFocusManagerPeer" class that did not exist
> before, does not a chance of appearance of a deadlock exist in such
> case? May be, it makes sense to use "ComponentAccessor.getPeer" method
> at least from the point of not running the risk of getting a deadlock?
>
> Thank you,
> Anton
>
> On 6/11/2013 6:00 PM, Sergey Bylokhov wrote:
>> On 11.06.2013 17:21, Anthony Petrov wrote:
>>> On 06/11/2013 03:31 PM, Sergey Bylokhov wrote:
>>>> On 11.06.2013 15:04, Anthony Petrov wrote:
>>>>> In (X)KFMPeer.java we know we always operate on Window instances. The
>>>>> setCurrentFocusedWindow(Window) method will never be called with any
>>>>> other components. Therefore, to avoid the overhead of taking multiple
>>>>> locks I suggest to use the AWTAccessor.getPeer directly in this case.
>>>>
>> Also at least in XToolkit TTP has its own peers map for text
>> components: specialPeerMap
>>
>
More information about the awt-dev
mailing list