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

[Prasanta Sadhukhan]

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
>>>>>>>
>>>>
>>>
>>>
>>
>
>