Re: [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.sadhuk...@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.

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

[Semyon Sadetsky]

Hi Alexander,

On the Windows platform you've only modified the dialog native peer 
while on other platforms all window types are modified to use FX window 
as a parent. Shouldn't the frame native peer  be modified too on the 
Windows platform?


--Semyon


On 09/21/2017 10:56 PM, Alexander Zvegintsev wrote:


Hi Phil,

Please review the updated fix with reflection incorporated
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/

New issue created JDK-8187803 
 as JDK counterpart 
of this issue.


Thanks,
Alexander.
On 21/09/2017 22:25, Phil Race wrote:

Some procedural comments :
Since 90% of this is in AWT code, I'd have thought awt-dev should be 
included here.

I've added that list.

And apart from needing separate bug ids, I don't see why the bug 
below is confidential.



I agree with what Kevin pointed out off-line that as in the dialog 
case, the FX side
of the code can use reflection and simply be a harmless 
non-functional no-op

if the SwingAccessor does not provide the new method.

BTW
264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
should be "dd" not "d".

-phil.

On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8185634

Gradle test fail; DLLS are missing (Windows 10)

[David Bimamisa]

Hi all,

I'm trying to build OpenJFX-8u on a Windows 10 machine and I stuck in the
test task of the fxpackager module. I'm getting the following exception:

com.oracle.tools.packager.APITest > testRuntimes FAILED
java.lang.RuntimeException: Not found MSVC dlls  at
com.oracle.tools.packager.windows.WinAppBundler.copyMSVCDLLs(WinAppBundler.java:320)
at
com.oracle.tools.packager.windows.WinAppBundler.doBundle(WinAppBundler.java:277)
at
com.oracle.tools.packager.windows.WinAppBundler.execute(WinAppBundler.java:586)
at com.oracle.tools.packager.APITest.testRuntimes(APITest.java:135)

It seems that some DLLs (e.g.
file:/[..]/modules/fxpackager/build/classes/test/com/oracle/tools/packager/windows//vcruntime100.dll)
are missing.

Can you give some hints on how to solve this problem?

Best regards
David

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

[Alexander Zvegintsev]

Hi Sergey,

Thanks for catching this, this is an issue which should be addressed.

Thanks,
Alexander.

On 23/09/2017 08:01, Sergey Bylokhov wrote:

Hi, Alexander.
How can we be sure that the parent frame will not be disposed while we 
use a pointer?


long ownerWindowPtr = peer.getOverridenWindowHandle();
< Dispose the peer
if (ownerWindowPtr != 0) {
    //Place window above JavaFX stage
    CWrapper.NSWindow.addChildWindow(
    ownerWindowPtr, ptr, CWrapper.NSWindow.NSWindowAbove);
< Boom
}


On 9/21/17 22:56, Alexander Zvegintsev wrote:

Hi Phil,

Please review the updated fix with reflection incorporated
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/

New issue created JDK-8187803 
 as JDK counterpart 
of this issue.


Thanks,
Alexander.

On 21/09/2017 22:25, Phil Race wrote:

Some procedural comments :
Since 90% of this is in AWT code, I'd have thought awt-dev should be 
included here.

I've added that list.

And apart from needing separate bug ids, I don't see why the bug 
below is confidential.



I agree with what Kevin pointed out off-line that as in the dialog 
case, the FX side
of the code can use reflection and simply be a harmless 
non-functional no-op

if the SwingAccessor does not provide the new method.

BTW
264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
should be "dd" not "d".

-phil.

On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8185634

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

[Alexander Zvegintsev]

Hi Dmitry,

From my understanding JavaFX stage can't be easily integrated in JDK to 
support orderWindow() approach,


addChildWindow() is a native(and the simplest) way to maintain one 
window above other one, should be called only once.


IIUC the main concert of JDK-8080729 that child windows jumping to 
parent's display upon focus receiving, this is not an issue with current 
fix,


because addChildWindow() will be called only upon dialog creation in 
case of JavaFX-Swing interop.


Jump may happen if user want to create a child swing dialog on display 
other than JavaFX stage's one,


but such rare scenario can be easily workarounded on a user side by 
calling setLocation() right after setVisible() call.


So I would prefer to use addChildWindow() to make this fix as simple as 
possible.



Thanks,
Alexander.

On 23/09/2017 21:21, Dmitry Markov wrote:

Hi Alexander,

In CPlatformWindow class you call CWrapper.NSWindow.addChildWindow() to place a 
window above JavaFX stage. The usage of addChilWindow() or/and 
removeChildWindow() may cause ‘jumping window issue’ in multi-monitor 
environment, see JDK-8080729 for more details.

To avoid possible problems in multi monitor set-up I suggest that you should 
replace addChildWindow() with orderWindow() or use some another approach to 
locate the window above the stage.

Thanks,
Dmitry

On 22 Sep 2017, at 06:56, Alexander Zvegintsev 
 wrote:

Hi Phil,

Please review the updated fix with reflection incorporated
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/

New issue created JDK-8187803 
 as JDK counterpart of this 
issue.

Thanks,
Alexander.

On 21/09/2017 22:25, Phil Race wrote:

Some procedural comments :
Since 90% of this is in AWT code, I'd have thought awt-dev should be included 
here.
I've added that list.

And apart from needing separate bug ids, I don't see why the bug below is 
confidential.


I agree with what Kevin pointed out off-line that as in the dialog case, the FX 
side
of the code can use reflection and simply be a harmless non-functional no-op
if the SwingAccessor does not provide the new method.

BTW
264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
should be "dd" not "d".

-phil.

On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8185634