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

[Anthony Petrov]

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?

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