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
