Using JDK splash screen from Web Start

Anthony Petrov anthony.petrov at oracle.com
Wed May 2 04:34:32 PDT 2012


On 5/2/2012 5:00 AM, Mike Swingler wrote:
> On May 1, 2012, at 5:15 PM, Scott Kovatch wrote:
> 
>> On May 1, 2012, at 4:11 PM, Mike Swingler wrote:
>>
>>> On May 1, 2012, at 3:28 PM, Scott Kovatch wrote:
>>>
>>>> Hello,
>>>>
>>>> Java Web Start supports showing a splash screen based on an image resource in the JNLP file. To do this, we load libsplashscreen.dylib and call SplashInit, SplashLoadFile and SplashClose (no animated image support, sorry.)
>>>>
>>>> This used to work in JDK 6, but now it doesn't. I verified that I'm getting the image and passing it into SplashLoadFile, but no window appears with the image.
>>>>
>>>> Looking at the implementation in JDK 7 I'm thinking that something is either starting up the AWT, or that there is a dependency of some kind on the AWT. Is this the case? Should libsplashscreen be linked against libawt?  Use of AWT code is not an issue here because Web Start starts a new process that shows the splash screen, but right now I'd be happy if it just worked.
>>>>
>>>> Any info/help is appreciated.
>>> The Java SE 6 splash-screen support was not contributable, because it directly use raw CGS windows (which were conveniently thread-safe from the Java main() thread).
>>>
>>> In JDK7, I believe the windows are now NSWindow based, and won't show up until AppKit has already started and the event loop in pumping. I'm not sure why it isn't work at all, even with a delay.
>> Sigh… That breaks the contract of the splash methods. Looking at SplashPlatformInit, I see two things. One, it assumes that it isn't being called on the main thread, because it attempts to call [NSApplicationAWT sharedApplication] in a main queue dispatch. Two, it assumes that libawt is available.
>>
>> For Web Start neither of these are true. We spawn a process for the splash screen with 'javaws -splash <port> <filename>', which eventually just calls SplashInit, SplashLoadFile and SplashClose when it gets a signal to quit. All of this happens on the main thread. Now I'll have to imitate java_md and spawn a thread that calls all of this stuff. And link against AWT!

Splash screen doesn't require to link against AWT. All the code needed 
to start up a NSApp instance for the splash screen has been extracted to 
the libosxapp dynamic library - that's what the splash screen needs to 
be linked against.

And yes, I think you have to do something similar to what we do in java_md.


>> I would like to be constructive here, but I can't. This is frustrating. :-\
> 
> I believe one of my early suggestions when this was first brought up was to create a private "_splash" binary in the JDK bundle who's only job is to show the image in it's own process/event-loop…but the idea was dismissed as too complex. Perhaps it still is…given the payoff, but it's the next logical step I would take if I had the cycles.

We decided to drop this idea because it would involve inter-process 
communication between the _spalsh and java processes because a java app 
may want to manipulate the splash screen. I'm not saying that this is 
impossible to implement, but it looks like too much of an effort for 
such a toy feature as the splash screen. Besides, I don't see why would 
such an approach be preferable to what we have already implemented, why 
would we have to re-implement it. Are there any issues with the current 
implementation?

--
best regards,
Anthony


More information about the macosx-port-dev mailing list