On 14/07/2012 12:23 AM, Mike Swingler wrote:
On Jul 13, 2012, at 6:22 AM, Anthony Petrov<anthony.pet...@oracle.com> wrote:
On 7/13/2012 5:09 PM, David Holmes wrote:
On 13/07/2012 10:58 PM, Anthony Petrov wrote:
I dug into the code history a little. The following Mike's changeset is
"to blame" for using HToolkit in headless mode on the Mac:
http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf
I've looked through the LWCToolkit.m which implements native methods
specific to the real, headful Mac toolkit, and actually all of the code
seems to be related to headful behavior only.
Note that in the headless mode the awt_LoadLibrary.c will still load the
correct lwawt dynamic native library, so all the necessary steps to
initialize the app from Mac OS X perspective will be performed anyway,
and all the native methods required by CFontManager and other C* classes
will be available also.
So basically I don't really see a problem with using the HToolkit class
for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will
wrap the real toolkit instance into a HeadlessToolkit class anyway, so
code that relies on instanceof checks against a toolkit instance should
not be affected by this choice in any way.
David, do you see any specific issues with using HToolkit on a desktop
(Mac) system?
No. I'm just wary of it. I'm curious what would have been done if this HToolkit
class had not existed?
Either it would have been introduced, or the LWCToolkit/LWToolkit classes would have been
made "more headless-aware," so to speak. I think Mike could shed some light on
his decision.
I was looking for a way to ensure that once the choice to be headless was made, there would be no
way to undo it. We've had problems in Java SE 6 and prior where the old CToolkit was "mostly
headless", but could still try to make contact to the window server for somethings (edge cases
in fonts, IIRC). This would "mostly work" for a while under an SSH session, but would die
some hours later after Mach bootstrap session expired, and lead to diagnosing some fairly
frustrating bugs.
With HToolkit, the boot comes down immediately about what you can and cannot do
- and the implementation looked simple enough, I didn't see much risk. It was
there, it worked, I went with it.
Anyway, to conclude the reviewing thread, given that we don't (currently) see
any problems with using HToolkit on the Mac, and the fact that it's already
been used in headless mode on the Mac for a while, I'm fine with the fix
proposed by Leonid.
I personally don't see why HToolkit couldn't be used unilaterally for headless
mode on all platforms. Wouldn't any breakage show an improper layering
violation that should not have been allowed to occur in the first place?
It was introduced for platforms with absolutely zero "graphics" related
capabilities - not even libraries installed let alone hardware. The
pre-existing "headless" toolkits still required some of this support
for, as I recall, printing/font related things - which must still be
supported even in headless mode. As long as this is passing the full set
of TCK/JCK tests then it is usable.
David
-----
Regards,
Mike Swingler
Apple Inc.
