JDK 7/8 falling back to headless toolkit in ssh login session

[Mike Swingler]

Phil, the crux of the problem is that the session you get when you SSH in isn't an "Aqua" session - so while apps you launch may be able to connect to the window server and show a window, lots of subtle stuff is going to be broken that relies on the session:
* The connection to the pasteboard server -> DnD and some copy/paste operations won't function properly
* App foreground activation doesn't occur correctly (LaunchServices)
* The "robot" operations may also be busted, but I haven't checked recently.
* Any AppleScript events to or from the process

Since these are design issues that are unlikely to ever be addressed by Apple (they have been present since OS X 10.0) we decided for Java 7+ that we will not further the misconception that you can fully interact with the logged in user from an SSH session.

~Mike

On May 27, 2013, at 7:51 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Hi Phil,
> 
> We explicitly decided to fall back to the headless mode when running over ssh. Please see this message:
> 
> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-December/001883.html
> 
> --
> best regards,
> Anthony
> 
> On 05/24/13 23:16, Phil Race wrote:
>> When we ssh into an OS X system as the currently logged in user, we
>> would like to run automated tests that display on the screen. However
>> I found that I need to explicitly tell it the toolkit to use to get this
>> to work
>> "AWT_TOOLKIT=CToolkit java ..."
>> 
>> else it falls back into a path where it selects the headless toolkit
>> which then complains when we try to create a window :
>> 
>> java -jar SwingSet2.jar
>> Exception in thread "main" java.awt.HeadlessException:
>> No X11 DISPLAY variable was set, but this program performed an operation
>> which requires it.
>> at
>> sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:77)
>> 
>> at SwingSet2.main(SwingSet2.java:222)
>> ....
>> The X11 message is a bit confusing but is basically the fallback code
>> assuming
>> that the headful toolkit would have been X11.
>> 
>> And SwingSet2 uses the SplashScreen API which displays an image before
>> AWT starts running, so we get the oddity that you see the splash screen
>> displayed
>> for a moment before AWT decides that can't have been possible and shuts
>> down :-)
>> 
>> The ultimate root of the problem is a function called "isInAquaSession"
>> which uses
>> The OSX GetSessionInfo call. JFK checks the returned bit flag for
>> sessionHasGraphicsAccessFlag
>> which is however "clear", even though as far as I can tell, it should be
>> "set".
>> SwingSet2 seems to work just fine when run as
>> AWT_TOOLKIT=CToolkit java -jar SwingSet2.jar
>> So it appears GetSessionInfo is unreliable, or maybe too picky over
>> something
>> that doesn't matter ?
>> 
>> So are we required to forever use the workaround above, or is there
>> something
>> we can do to get the right answer ?
>> 
>> -phil.
>>