<AWT Dev> Review request for CR-7179050 : [macosx] Make LWAWT be able to run on AppKit thread

[Artem Ananiev]

On 1/15/2013 7:07 PM, Sergey Bylokhov wrote:
> Hi, Petr.
> Small comments from the quick view:
>
> ThreadUtilities performOnMainThreadWaiting should not be called from the
> main thread with YES. I guess it should throw the same error as before
> the fix.

I don't have a strong opinion on that, but the new behavior is 
consistent with how +performOnMainThreadWaiting:block: is implemented.

Thanks,

Artem

> 15.01.2013 18:54, Petr Pchelko wrote:
>> Hello, AWT team.
>>
>> Please review a fix for the issue: [macosx] Make LWAWT be able to run
>> on AppKit thread
>> http://bugs.sun.com/view_bug.do?bug_id=7179050
>>
>> The fix is available at:
>> http://cr.openjdk.java.net/~art/pchelko/7179050/
>> <http://cr.openjdk.java.net/%7Eart/pchelko/7179050/>
>>
>> A lot of simple refactoring is done here:
>> 1. The JNFRunLoop calls are changed to ThreadUtilities calls which do
>> the thread check before calling JNFRunloop.
>> 2. AWT_ASSERT_NOT_APPKIT_THREAD calls are deleted where it is safe. I
>> did not touch printing code and Drag and Drop code as in these parts
>> the situation is much more complicated, and it would be better to
>> investigate them separately.
>> 3. AWT_ASSERT_APPKIT_THREAD calls immediately following the
>> performOnMainThread are removed because it is obvious that we are
>> running on Appkit thread.
>> 4. AWT_ASSERT_ANY_THREAD - this was a very surprising assertion which
>> does nothing. Probably it was originally designed to mark methods
>> which could be called from any thread, however now it occurs in the
>> code only occasionally, so it only confusing. It is removed
>> 5. The CPlatformWindow method nativeSetNSWindowSecurityWarnongPosition
>> was private, never called and all it did was throwing an Unsupported
>> operation exception. It is deleted.
>> 6. A lot of code in ThreadUtilities.m was used only in CocoaComponent
>> compatibility mode. We do not support this mode any more, so the code
>> could be deleted. It is safe, because all the removed code was used
>> only if the sCocoaComponentCompatibility flag was set to YES. However
>> it is set to NO in the beginning of the file and it is an only place
>> where this flag is used in openjdk.
>>
>> With best regards. Petr.
>>
>>
>
>