[7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session)

[Alexander Zuev]

On 7/23/12 17:19, Artem Ananiev wrote:
>
> On 7/23/2012 2:53 PM, Alexander Zuev wrote:
>> Artem,
>>
>> these native methods should not be called according to the logic of the
>> class so we shouldn't safeguard them.
>
> Could you elaborate on that, please?
Sure. The only native method that is not related to drag and drop 
functionality
(which can not be instantiated in headless mode anyways) is private 
native String formatForIndex(long index);
It is being called from the protected method getNativeForFormat(long 
format) which, in turn, being called
by the drag-related methods or from public getters that check the index 
to be in the valid borders.
Since we do not register any native-backed flavors in the set this 
native method will not be called in headless mode.
>
>> I will create the sub-cr against the jdk8.
>
> Thanks!
>
> Artem
>
>> WBR,
>> Alex
>>
>>
>>
>> On 7/23/12 14:41, Artem Ananiev wrote:
>>> Hi, Alex,
>>>
>>> (cross-posting to awt-dev)
>>>
>>> I see several other native methods in CDataTransferer, e.g.
>>> formatForIndex(). Could you confirm, they cannot be called in the
>>> headless mode, so there is no need to protect them with headless
>>> check, please?
>>>
>>> Could you also file a SubCR against JDK8 with the idea we discussed
>>> offline: create a new CHeadlessDataTransferer class to use in the
>>> headless mode instead of CDataTransferer + headless checks, please?
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>> On 7/23/2012 1:09 PM, Alexander Zuev wrote:
>>>> Hello,
>>>>
>>>> please review my fix 7184951: [macosx] Exception at
>>>> java.awt.datatransfer on headless mode (only in GUI session)
>>>> CR description can be found here:
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951
>>>>
>>>> Webrev with the proposed change can be seen here:
>>>> http://cr.openjdk.java.net/~kizune/7184951/webrev.00
>>>>
>>>> The problem here lays somewhere deep in the Toolkit life cycle on
>>>> Mac OS X - at the time we initialize datatransfer the
>>>> Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later
>>>> when we trying to use it it returns HeadlessToolkit. That's definitely
>>>> wrong but at this stage it's too risky to fiddle with the life cycle
>>>> itself so this is a hotfix that deals with the fallout of the actual
>>>> error. The fix for jdk8 should be different.
>>>>
>>>> With best regards,
>>>> Alex
>>
>>