<AWT Dev> [8] Review request for 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified

[Artem Ananiev]

On 10/4/2013 3:37 PM, Anthony Petrov wrote:
> On 10/04/2013 02:57 PM, Artem Ananiev wrote:
>> On 10/4/2013 2:45 PM, Anthony Petrov wrote:
>>> On 10/02/2013 05:07 PM, Artem Ananiev wrote:
>>>>>> You're right, it's not necessary. However, since we touch this code
>>>>>> anyway, I'd be glad to have this redundant code removed.
>>>>>
>>>>> It's not redundant. Please see my message below in the quote for
>>>>> details.
>>>>
>>>> Do you mean the following quote:
>>>>
>>>>>>>>> However, your fix effectively disallows a component to belong to
>>>>>>>>> any
>>>>>>>>> toolkit other than the default one, because its getToolkit() will
>>>>>>>>> never return anything else (unless you extend the component's
>>>>>>>>> class
>>>>>>>>> and override the method).
>>>>
>>>> ? Extending the Component class and providing different implementation
>>>> for getToolkit() is the way to achieve this functionality. Without this
>>>> extension, it doesn't matter if Component.getToolkit() calls to the
>>>> peer
>>>> or directly returns the default toolkit.
>>>
>>> I can't say I fully agree with that. When using the default toolkit, you
>>> don't need to extend public AWT classes. I don't see why you would have
>>> to do that when using a custom toolkit.
>>
>> Sorry, I still don't get it... To me it looks like we don't change
>> anything. The current behavior is preserved, Component.getToolkit()
>> returns the default toolkit. Ability to extend the Component class and
>> change getToolkit() is not affected. All the weird cases like
>> co-existence of two different toolkits in the same process, or component
>> peers that are not created by the current toolkit, etc. are not worth
>> thinking about to me.
>>
>> Could you provide a sample, which works with the current implementation
>> and won't work after the proposed fix, please?
>
> No, unfortunately I don't have a working sample. I'm only considering a
> theoretical possibility of several toolkits co-existing in a single VM.
> I looked over the addNotify() implementation and see that it relies upon
> the getToolkit() method. So indeed, w/o overriding it you can't
> construct an AWT widget using a 3rd-party toolkit. OTOH, such a toolkit
> might provide a factory method for components, and set its peer field
> before returning the component instance to the app (w/o actually
> extending the class). This case would break with the current fix.
>
> Also, w/o clear understanding of the reason why the
> ComponentPeer.getToolkit() and the corresponding logic in
> Component.getToolkit() were introduced in the first place, it looks kind
> of scary to just drop this method so late in the JDK8 release cycle.
>
> Since this part of the fix isn't mandatory for the specification change,
> I still suggest to file a separate issue and investigate it later
> because it doesn't seem urgent (as opposed to the spec change itself.)

Based on my past experience, I would bet such a separate issue will 
never be fixed/implemented. So I still believe this redundant method in 
the ComponentPeer interface should be removed as a part of this fix.

As a summary, what we have now. On one hand, the fix is useful 
(redundant code is removed) and doesn't change the current behavior. I 
don't see why it's considered scary... On the other hand, possibility to 
have multiple AWT toolkits in a single VM is pure theoretical. De-facto 
it hasn't been supported for years. It is possible to create your own 
Toolkit, but all the AWT/Swing code will use the default toolkit anyway.

Thanks,

Artem

> --
> best regards,
> Anthony
>
>>
>> Thanks,
>>
>> Artem
>>
>>> Can we file a separate P4 issue to evaluate this later, and only change
>>> the specification with 7081584 ?
>>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>>> --
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> SAM
>>>>>>>>
>>>>>>>> On 01.10.2013 21:47, Anthony Petrov wrote:
>>>>>>>>> Hi Sergey,
>>>>>>>>>
>>>>>>>>> I'm wondering what compatibility impact of this change is. The
>>>>>>>>> specification for Component.getToolkit() suggests that in theory
>>>>>>>>> several toolkits may co-exist in a single application. And
>>>>>>>>> thanks to
>>>>>>>>> delegating to the ComponentPeer, the Component.getToolkit() could
>>>>>>>>> return the actual toolkit for this component.
>>>>>>>>>
>>>>>>>>> However, your fix effectively disallows a component to belong to
>>>>>>>>> any
>>>>>>>>> toolkit other than the default one, because its getToolkit() will
>>>>>>>>> never return anything else (unless you extend the component's
>>>>>>>>> class
>>>>>>>>> and override the method).
>>>>>>>>>
>>>>>>>>> I really don't know whether this is widely used, but I think this
>>>>>>>>> may
>>>>>>>>> impact some applications.
>>>>>>>>>
>>>>>>>>> Also, imagine a window is made to belong to another toolkit
>>>>>>>>> somehow,
>>>>>>>>> even with your changes. Now, why should its ability to be
>>>>>>>>> always-on-top depend on the default toolkit instead of the
>>>>>>>>> window's
>>>>>>>>> own toolkit?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>>
>>>>>>>>> On 09/27/2013 08:49 PM, sergey malenkov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Could you please review the following fix:
>>>>>>>>>> fix:http://cr.openjdk.java.net/~malenkov/7081584.8.0/
>>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-7081584
>>>>>>>>>>
>>>>>>>>>> The specification of the Window class waits for CCC approval.
>>>>>>>>>> This
>>>>>>>>>> fix
>>>>>>>>>> removes the getTookit method from the ComponentPeer class and its
>>>>>>>>>> subclasses.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> SAM
>>>>>>>>>>
>>>>>>>>