<AWT Dev> [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode

[Sergey Bylokhov]

 From the AWT point of view the fix looks fine.

On 9/23/17 00:03, Prasanta Sadhukhan wrote:
> Hi Sergey,
> 
> Please find modified webrev catering to DefaultKeyboardFocusManager also
> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.05/
> 
> Regards
> Prasanta
> On 9/23/2017 7:52 AM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>>
>> On 9/19/17 22:26, Prasanta Sadhukhan wrote:
>>>> Hi, Prasanta.
>>>>  - In this version it is unclear what is a purpose of the 
>>>> "fxCheckSequenceThread.start()". This code will start the thread and 
>>>> will continue execution, it will not wait when the thread will stop.
>>>>  - The DefaultKeyboardFocusManager also should check for 
>>>> "javafx.embed.singleThread"
>>>>
>>> Please find modified webrev catering to both comments
>>> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.04/
>>
>> The new code in DefaultKeyboardFocusManager also will not wait when 
>> the thread will stop.
>>
>>>
>>> Regards
>>> Prasanta
>>>>
>>>> On 9/13/17 03:11, Prasanta Sadhukhan wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> I have modified the fix to not use SecondaryLoop and not to create 
>>>>> one thread per dispatch
>>>>> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 8/30/2017 11:41 AM, Sergey Bylokhov wrote:
>>>>>> Hi, Prasanta.
>>>>>> Can you please provide some description on how the SecondaryLoop 
>>>>>> will work when it will run on Appkit thread? Is it possible to get 
>>>>>> a deadlock here, since appkit will be blocked?
>>>>>>
>>>>>>> sequence, ie if the event is not first in sequence, then it will 
>>>>>>> made
>>>>>>> to
>>>>>>> wait till it is the first event or till it is disposed.
>>>>>> Note that the new code (unlike lines 139-150) also waits 1 second, 
>>>>>> so we can get a situation when only one event will be dispatched 
>>>>>> per second, which is not we want to do.
>>>>>> I am not sure how often we create SequencedEvent but creating one 
>>>>>> thread per dispatch look inefficient.
>>>>>>
>>>>>>
>>>>>>> Modified webrev
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote:
>>>>>>>> Hi, Prasanta.
>>>>>>>>
>>>>>>>> On 16.08.2017 3:33, Prasanta Sadhukhan wrote:
>>>>>>>>> Now, since here FX App thread itself is the dispatch thread, we 
>>>>>>>>> can
>>>>>>>>> be sure the events are dispatched in sequence and dispose is
>>>>>>> checked
>>>>>>>>> below after EDT.
>>>>>>>> Why we can sure about this? If the SequencedEvents were created in
>>>>>>> one
>>>>>>>> order but dispatch() for each were called in other order then the
>>>>>>>> sequenced will not be preserved?
>>>>>>>>
>>>>>>>>> I have tested with couple of singleThread testcase without any
>>>>>>> issue.
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:
>>>>>>>>>> Hi, Prasanta, Kevin.
>>>>>>>>>>
>>>>>>>>>> I have two notes.
>>>>>>>>>>    - Does this option is really supported? If it is supported we
>>>>>>>>>> should evaluate all usage of EventDispatchThread because in this
>>>>>>>>>> mode the dispatch thread is not EDT. For example I am not sure
>>>>>>> that
>>>>>>>>>> we can skip the code which expects EventDispatchThread.
>>>>>>>>>>    - We have the similar pattern: 
>>>>>>>>>> "EventQueue.isDispatchThread() ->
>>>>>>>>>> cast(EventDispatchThread)" in some other places like in
>>>>>>>>>> DefaultKeyboardFocusManager.
>>>>>>>>>>
>>>>>>>>>> -----prasanta.sadhukhan at oracle.com  wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Please review this fix
>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
>>>>>>>>>>> for an fx issue
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088132
>>>>>>>>>>>
>>>>>>>>>>> More info in JBS.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.