<AWT Dev> [9] Review Request: 8033367 [macosx] Appletviewer was broken in jdk8 b124

[Anthony Petrov]

Hi Petr,

The fix looks good to me. One minor nit: every file that includes 
AWT_debug.h will contain its own copy of the 
ShouldPrintVerboseDebugging() function and the debug flag. Could we have 
only one copy instead?

--
best regards,
Anthony

On 6/3/2014 3:18 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review a little fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8033367
> The fix is available here:
> http://cr.openjdk.java.net/~pchelko/9/8033367/webrev/
>
> The problem:
> We were doing too much in JNI_OnLoad. Loading many classes, making sync calls to Appkit thread, loading classes and native libs from Appkit thread and so on.
> This was causing deadlocks and crashes that we've workarounded for 8. But for 9 I've rewritten the AWT startup code to make JNI_OnLoad do a bit less work.
>
> The solution:
> Now loading awt native lib does not trigger loading AppKit and starting NSApplication. Instead we just load a library and tell Cocoa we are going to be multithreaded.
> We start Appkit when Toolkit is created, so now we avoid problems with deadlocks on runtime lock.
>
> An issue with the fix:
> I've made GraphicsEnvironment also load AppKit, because we use an NSView for a scratch surface in an OpenGL context. Really this is quite likely not needed as we are
> (should be) using FBOs for offscreen rendering. But getting rid of an NSView-based scratch surface is a separate big project, so I'll file a bug for it and now let's load
> Appkit when GraphicsEnvironment is initialized too.
>
> Testing:
> I have run all JCK, all regression tests, sanity-tested JFX interop and SWT interop, checked applets and webstart, tested headless mode. Everything seems to work fine,
> but anyway this fix is extremely risky. But this should be done if we want to avoid a problems like JDK-8033367 or JDK-8031050.
>
> Thank you.
> With best regards. Petr.
>