<AWT Dev> [7u6] Review request for 7181027: [macosx] Unable to use headless mode

[David Holmes]

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?

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.
>>>>>>
>>>>