Preliminary review for MACOSX_PORT-176: AWT Splashscreen support

[Anthony Petrov]

Hi Mike,

Thanks much for reviewing the fix! Please find my comments bellow.

On 12/08/11 01:55, Mike Swingler wrote:
>> http://cr.openjdk.java.net/~anthony/x-3-splashAndOSXGUILib.0/
>>
>> Note that instead of moving the NSApplicationAWT code to the libosxui, I instead introduced a new libosxapp. This is because osxui has too many dependencies on the AWT while we start the splashscreen even before calling user's main() method. Perhaps we could move some code from osxui to osxapp eventually, but not at this time.
>>
>> So, in a nutshell, the libosxapp is now responsible for creating and setting up an NSApplicationAWT instance. Note that since the splash screen takes off too early, user's code (e.g. SWT) won't be able to initialize their own application yet, and as such our application instance will be installed. Which means that our splash screen implementation is incompatible with SWT-based apps. By this reason I also didn't move the start up code from awt.m to the new libosxapp - it's simply isn't needed in case the osxapp is used from the splash screen code. Is this OK with everyone? Or are there suggestions on how to improve this part?
>>
>> In NSApplicationAWT.m there is an outstanding TODO item: we need to be able to install a "caching app delegate" so that we could catch all the openFile and other start-up notification, and then call the necessary methods manually once a proper application delegate is installed from the awt.m code. Note that we need this caching only when the splash screen is used. If an app doesn't use the splash screen, then the correct delegate is installed right from the start.
>>
>> Please take a brief look at the fix. Does it look good overall?
>>
>> I could push it now actually, and continue to work on the mentioned above issues separately, or I could complete them first, and then push my fix. Note that I'm not sure if the SWT-related issue has any reasonable solution at all, but the delegate callbacks caching mechanism needs to be implemented sooner or later anyway.
>>
>> What would be the best to do now?
>
> A few notes:
>
> * I think it makes sense to move the PropertiesUtilities class into libosx, where the rest of the non-UI stuff lives right now, and just link libosxapp against that (since it's useful from libosx, libosxui, and libosxapp). It probably makes sense to move the ThreadUtilities class to libosx too, for the same reasons.

This is a good suggestion. However, there's a problem with this 
approach. As soon as a makefile for a library defines the PACKAGE 
symbol, the library built with this makefile is directly linked against 
libjvm and libjava. While the linking command seems to be correct 
(@rpath and -L are specified as needed, and the otool -L confirms the 
@rpath for the libs is used), the library fails to load when requested 
from the Java launcher code (either directly through dlopen() or 
indirectly as a dependency of another lib loaded with dlopen()). The 
failure happens even though I'm loading the library only after the JVM 
has already been initialized (and hence, I suppose, the libjvm should 
have already been loaded). dlerror() reports it's unable to load exactly 
the libjvm.dylib in such cases.

I really have no idea how to resolve this issue. Perhaps these libraries 
are "real" JNI libs, and as such just must be loaded with 
System.loadLibrary() or something. (and yes, we do need the PACKAGE for 
the libosx.dylib since it needs to compile a bunch of Java classes). 
Unless there's a solution for this issue, I'll keep PropertiesUtilities 
and ThreadUtilities in the libosxapp for now.


> * You can remove the "AppKitThreadHelper" class. It is redundant with +[JNFRunLoop performOnMainThreadWaiting:withBlock:] or simply doing a -performSelectorOnMainThread: using the NSObject class itself as the target.

Thanks! Done.

> * Is the expectation that libosxapp be a common substrate that JavaFX or SWT can launch itself with AppKit directly without the AWT being involved? If so, a design question you may want to ask is, should the com.apple.eawt.* event handling be available from these other frameworks? I know SWT has had an interest in using the eAWT, and would jump at the opportunity to have have to load the AWT to do so.

I think that in the future FX could make use of libosxapp. At least to 
avoid code duplication between AWT and FX.

BTW, we've already got an issue with the eawt.OpenFilesHandler not being 
invoked for FX apps. But as long as FX or SWT are running their own 
event loop with their own NSApp instances I guess neither of them could 
use eawt right now. This is something that we could improve for Oracle 
JDK for Mac. In any case, I think this can be done separately rather 
than delaying the splash screen implementation.


> * I find it more than a little amusing that my last re-write of the eAWT event handling explicitly created queues for incoming events (prior to client code registering their handlers), but I put the queues on the Java side, and now you need them on the native side. I think the easiest way to handle this will to simply wrap the work of the event handlers in a block, dump those blocks into an NSArray (since blocks are objects), and then pump them onto the main queue once the eAWT handlers have been registered. This may also allow you to delete some of the queueing/locking code up in the Java side of the eAWT implementation.

Yeah, I'll implement something NSArray-based. I don't think we should 
remove the Java-level queuing though, since the native queue would 
really only be used when the NSApplicationAWT instance is created from 
the SplashScreen code. Otherwise a proper delegate is available from the 
beginning and as such we'll need to queue the events in Java code. Of 
course, this could be optimized somehow in the future.

I'll post an updated webrev once I implement queuing the delegate 
events. Thanks again for the review!

--
best regards,
Anthony