<AWT Dev> [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session)
alexander.zuev at oracle.com
Mon Jul 23 06:28:10 PDT 2012
On 7/23/12 17:19, Artem Ananiev wrote:
> On 7/23/2012 2:53 PM, Alexander Zuev wrote:
>> 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
(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.
>> 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?
>>> On 7/23/2012 1:09 PM, Alexander Zuev wrote:
>>>> please review my fix 7184951: [macosx] Exception at
>>>> java.awt.datatransfer on headless mode (only in GUI session)
>>>> CR description can be found here:
>>>> Webrev with the proposed change can be seen here:
>>>> 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,
More information about the awt-dev