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.
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.
--
best regards,
Anthony
David
-----
--
best regards,
Anthony
On 7/13/2012 1:26 AM, David Holmes wrote:
On 12/07/2012 10:33 PM, Anthony Petrov wrote:
The logic is all in src/solaris/native/java/lang/java_props_macosx.c.
The getPreferredToolkit() returns the HToolkit constant when the
headless mode is needed on the Mac. And the GetJavaProperties() will
then choose the sun.awt.HToolkit as the toolkit. Interesting.
Interesting indeed. But my concerns remain. HToolkit was not intended
for general use. OSX seems to be handling headless mode in a
completely different way to Solaris/linux.
Of course it may be that on OSX you run into the same conditions when
headless that required the introduction of HToolkit. But somebody
should have made a very conscious decision to do that.
But it all seems to work fine in headless mode on the Mac, right?
You mean apart from this bug? ;-) I see a few bugs involving headless
on OSX.
Cheers,
David
Leonid, did you run headless regression tests with your fix, btw?
--
best regards,
Anthony
On 07/12/12 12:58, Leonid Romanov wrote:
Perhaps Anthony might be able to answer your question: he has tinkered
a lot with headless related stuff.
David, are you implying that in the current form my fix is no-go?
On 12.07.2012, at 5:15, David Holmes wrote:
On 11/07/2012 11:46 PM, Leonid Romanov wrote:
Hi,
Please review a fix for 7181027: [macosx] Unable to use headless
mode. The problem here is that for headless mode
"java.awt.graphicsenv" system property should be
CGraphicsEnvironment because the way GraphicsEnvironment.createGE()
method works: it first instantiates GraphicsEnvironment instance and
then wraps it with HeadlessGraphicsEnvironment if in headless mode.
This means twe can't use java.awt.graphicsenv property to determine
whether we are in headless mode or not. So, I've replaced it with a
toolkit check: if it's HToolkit, then we are in headless.
sun.awt.HToolkit was introduced for use by SE-Embedded's reduced
headless JRE. How did the OSX port end up using it ???
Headless handling on OSX should be like regular headless on Linux,
Solaris.
David
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027
Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/
Thanks,
Leonid.
