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

[Anthony Petrov]

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.)

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