<AWT Dev> [9] Review Request: 8032187 [macosx] The fix for MACOSX_PORT-424 should be reworked

[Anthony Petrov]

I agree that the listener should receive all the events for compound 
controls. They make sense because all the parts of compound controls are 
accessible via our public API, so the app could just assign listeners to 
specific sub-components if it needed to.

However, this isn't true for our internal LWAWT components hierarchy. 
This hierarchy is hidden from users (they can't access the underlying 
Swing components via public API, and moreover, they shouldn't be able to 
do so even if they want to). It is an implementation detail of the LWAWT 
toolkit. And therefore, I don't see a reason to post events related to 
this hidden hierarchy to a listener that can be installed using the 
public API.

Can we find another way to filter the events out?

--
best regards,
Anthony

On 2/5/2014 1:26 AM, Sergey Bylokhov wrote:
> On 04.02.2014 23:06, Anthony Petrov wrote:
>> Hi Sergey,
>>
>> From the bug report:
>>> After discussion, it was decided to accept MACOSX_PORT-424 as not a
>>> defect
>>
>> Are you saying that user code will start receiving hierarchy events
>> related to the internal hierarchy of our LWAWT peers? Why would anyone
>> want to process these events and why would we want to post them to
>> user code? Is there any way to filter them out?
> Documentation of Toolkit.addAWTEventListener() states:
>       * Adds an AWTEventListener to receive all AWTEvents dispatched
>       * system-wide that conform to the given <code>eventMask</code>.
> ....
>       * Note:  event listener use is not recommended for normal
>       * application use, but are intended solely to support special
>       * purpose facilities including support for accessibility,
>       * event record/playback, and diagnostic tracing.
>
> And components intentionally cannot filter them out. All our non trivial
> compound components posts lots of such events.
>
>> While I agree that using reflection is a bad idea, but is there any
>> other real problem with the original fix for MACOSX_PORT-424? I.e.
>> does that fix break anything? If not, can we simply replace usages of
>> reflection with AWTAccessor-like mechanism?
> The problem not in reflection but in replacing global list of listeners.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 2/4/2014 3:52 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk 9.
>>>   - Initial fix for MACOSX_PORT-424 was reverted back.
>>>   - delegate.addNotify(),because it was called from
>>> delegateContainer.addNotify();
>>>   - Testcase was updated to filter out events not from the Frame:
>>>    84             if (e.getSource() instanceof Frame) {
>>>    85                 counter++;
>>>    86                 notify();
>>>    87             }
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8032187
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8032187/webrev.00
>>>
>
>