<AWT Dev> [7u6] Review request for 7181027: [macosx] Unable to use headless mode
swingler at apple.com
Sat Jul 14 06:52:28 PDT 2012
On Jul 13, 2012, at 5:40 PM, David Holmes wrote:
> On 14/07/2012 12:23 AM, Mike Swingler wrote:
>> On Jul 13, 2012, at 6:22 AM, Anthony Petrov<anthony.petrov at 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:
>>>>> 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.
In OS X, it is unsafe to communicate with any Cocoa code in a headless/server environment, so this is actually a good match for our usage.
Any font usage or printing done in this mode would have to fall back to only font files and CUPS sockets, and not rely on the CoreText/CoreGraphics API. Trying to add font or printing in a server context might be a reason to sub-class or extend HToolkit - but I imagine some of that implementation would be common with the XToolkit, and that would be an interesting design discussion how to tease all that apart and recombine it in a modular way that would allow CToolkit to delegate to it without introducing a dependency on X11.
More information about the awt-dev