[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-macosx-port-dev
Subject:    <AWT Dev> [7u6] Review request for 7181027: [macosx] Unable to use headless mode
From:       swingler () apple ! com (Mike Swingler)
Date:       2012-07-14 13:52:28
Message-ID: 54F9A10C-BFAE-4429-B7A0-035CDA1AF327 () apple ! com
[Download RAW message or body]

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

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.

Regards,
Mike Swingler
Apple Inc.


[prev in list] [next in list] [prev in thread] [next in thread]