Re: AWT Dev [8] Review request for 7192887 java/awt/Window/Grab/GrabTest.java still failed (fix failed for CR 7149068)
Looks fine to me. Thanks, Anton. On 8/27/12 7:22 PM, Denis S. Fokin wrote: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7192887 webrev: http://http://cr.openjdk.java.net/~denis/7192887/webrev UngrabEvent is not sent on some platforms (XToolkit) on window disposal. I have added the code in XWindowPeer.dispose() method. We do the similar posts on EDT in XWindowPeer but I do not think that extraction the code in a method is needed here. Thank you, Denis.
Re: AWT Dev [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.05/ The comments are below: - NSTrackingCursorUpdate option is removed from the rolloverTrackingArea On 8/24/2012 7:00 PM, Anthony Petrov wrote: src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java 66 public static native CPlatformWindow nativeGetTopmostPlatformWindowUnderMouse(); This method must probably be private. Fixed. Still, I don't see why getTopmostPlatformWindowUnderMouse() must return null when it's invoked on an embedded frame, and why the implementation should even be different at all. The mouse is a global system entity. There's either some window under the mouse, or there's not. I would still think of LWToolkit.getPlatformWindowUnderMouse(), and its implementation in LWCToolkit. Dmitry, who is a responsible person for the CPlatformEmbeddedFrame, said that the implementation of the getPlatformWindowUnderMouse() method could be different for applets. So the getPlatformWindowUnderMouse() method implementation will be filled as a separated issue and fixed by Dmitry. Also, the logic in LWWindowPeer lines 722-743 seems to be overly complicated (as well as the whole dispatchMouseEvent() method). E.g., if the LWWindowPeer manages an embedded frame, we get topmostWindowPeer == this at line 730, and thus always go through the 'true' branch of if() at line 733, even though actually the mouse pointer can be located over some other window at the moment (e.g. over a popup window opened by an applet). I updated the topmostWindowPeer variable creation so it now can have only the topmost window under mouse value or null and added a comment that the (topmostWindowPeer == null ) condition should be removed after the getPlatformWindowUnderMouse() method implementation in the CPlatformEmbeddedFrame class. For now the (topmostWindowPeer == null ) condition allows to track the mouse enter/exit components events as it was before the fix. Overall, it's really difficult to understand what is going on there. I've spent half an hour reading the code and am still not sure if I get it right. Why does LWWindowPeer even care about the EXITED/ENTERED events for components? Shouldn't this code belong to LWComponentPeer? Or even the shared code? How do Swing components in regular Swing apps get the ENTERED/EXITED events then? Why can't we use the same approach for LWAWT? Swing controls have Container in a parent class hierarchy. The Container class has the LightweightDispatcher dispatcher which allows to track mouse moving from one component to another and generate necessary mouse enter/exit events. AWT controls have Component class as a parent and do not have the dispatcher. So moving/dragging a mouse from one AWT control to another does not generate necessary mouse events. The aim of the fix is not redesigning current architecture. It just adds checking a case where a mouse is dragged from one window to another and so the first window which gets the mouse drag events is not the real window for which component enter/exit events should be generated. Thanks, Alexandr. -- best regards, Anthony On 8/24/2012 5:53 PM, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ The comments are below: On 8/23/2012 4:51 PM, Anthony Petrov wrote: Hi Alexandr, 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate through app's windows only once and send both Exited and Entered events where needed? Now, when we do not care about the order of the mouse enter/exit events generation it is possible to do. I have updated the code. 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no longer requires a window pointer as an argument. Fixed. 3. Here's a major concern: the LWWindowPeer (and other LW* classes) should never import C* classes. Instead you should've added a new method to the PlatformWindow interface, and used it from LWWindowPeer. The CPlatformWindow should've implemented this method, and called an appropriate native method from there. In this case, however, you actually need a static method, so it'd better be part of the LWToolkit interface, and implemented in the LWCToolkit class instead. I see. It seems that the getTopmostWindowUnderMouse method implementation is different for the CPlatformWindow and for the CPlatformEmbeddedFrame. So I added the getTopmostPlatformWindowUnderMouse method to the PlatformWindow interface. Thanks, Alexandr. -- best regards, Anthony On 08/23/12 15:40, Alexander Scherbatiy wrote: Could someone review the fix? Thanks, Alexandr. On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ The comments are below: On 8/7/2012 6:47 PM, Mike Swingler wrote: I noticed that,
AWT Dev Objective-C and jcheck
Hi Everybody. Looks like on the server we still use jcheck without fix for Objective-C files? Does anybody know how to apply the fix to jdk8? (see attachment) [jdk] pulling from http://hg.openjdk.java.net/jdk8/awt/jdk searching for changes adding changesets adding manifests adding file changes added 1 changesets with 10 changes to 10 files [jcheck 25e85a608db1 2011-07-08 09:19 -0700] Changeset: 5305:0fad89bd606b Author:alexsch Date: 2012-05-02 17:54 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left side Reviewed-by: anthony, leonidr src/macosx/native/sun/awt/AWTView.m:84: Trailing whitespace src/macosx/native/sun/awt/AWTWindow.m:173: Trailing whitespace transaction abort! rollback completed skipped: pretxnchangegroup.jcheck hook failed 02.05.2012 17:53, alexandr.scherba...@oracle.com wrote Changeset: 0fad89bd606b Author:alexsch Date: 2012-05-02 17:54 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0fad89bd606b 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left side Reviewed-by: anthony, leonidr ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTView.h ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java + test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java + test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java ! test/java/awt/regtesthelpers/Util.java ---BeginMessage--- Folks, The 'official' copy of jcheck is not scanning .m or .mm files for whitespace violations. I use a local copy of the latest jcheck so I don't have to be on VPN all the time, and I modified the script to look at .m files as well. Two change sets just arrived with trailing whitespace. From what I have been told about mercurial and the way jcheck works, fixing this is going to be more than a simple script change because jcheck looks at each changeset as they are applied to your local workspace. I think I can work around this by relaxing the pretxnchangegroup.jcheck but we really should investigate this soon. The jcheck script fix is very easy. Change line 142 to: normext_re = re.compile(.*\.(java|c|h|cpp|hpp|m|mm)$) -- Scott K. Scott Kovatch scott.kova...@oracle.com Santa Clara/Pleasanton, CA ---End Message---
AWT Dev hg: jdk8/awt/jdk: 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression)
Changeset: f54660c18774 Author:serb Date: 2012-08-28 16:04 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f54660c18774 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) Reviewed-by: leonidr ! src/macosx/classes/com/apple/laf/ScreenMenuItem.java ! src/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java
Re: AWT Dev [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test
Hi Konstantin,
I think you should modify the copyright headers in each file. The files
are no longer proprietary/confidential. .sh and makefiles should also
include a copyright header. Please use existing source files in the open
repository as a template for the header.
test/java/awt/JAWT/MyCanvas.java
52 f.show();
Please replace this with f.setVisible(true);
53 robot.delay(1);
I think 10 seconds is kind of too long. It might have been relevant for
Java 1.4, but now I think 5 seconds should be pretty much enough for
every modern system.
test/java/awt/JAWT/JAWT.sh
137 case $OS in
138 Windows* | CYGWIN* )
139 cp ${TESTJAVA}${FS}jre${FS}bin${FS}jawt.dll .
140 ;;
141 esac
Why is this necessary? This must be a bug in JDK if the library still
needs to be copied to the current directory on Windows. Could you verify
if the test still works w/o copying the dll? It must, actually.
--
best regards,
Anthony
On 8/27/2012 8:29 PM, Konstantin Shefov wrote:
Hello,
Please review a fix for the issue:
7190587 Open source and jtreg'ify JAWT regression test
Test was modified in to be run with jtreg.
The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/
Thanks,
Konstantin
Re: AWT Dev [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
Hi Alexander, Thanks for the clarifications. The code now looks clearer. I'm fine with the fix. -- best regards, Anthony On 8/28/2012 3:17 PM, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.05/ The comments are below: - NSTrackingCursorUpdate option is removed from the rolloverTrackingArea On 8/24/2012 7:00 PM, Anthony Petrov wrote: src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java 66 public static native CPlatformWindow nativeGetTopmostPlatformWindowUnderMouse(); This method must probably be private. Fixed. Still, I don't see why getTopmostPlatformWindowUnderMouse() must return null when it's invoked on an embedded frame, and why the implementation should even be different at all. The mouse is a global system entity. There's either some window under the mouse, or there's not. I would still think of LWToolkit.getPlatformWindowUnderMouse(), and its implementation in LWCToolkit. Dmitry, who is a responsible person for the CPlatformEmbeddedFrame, said that the implementation of the getPlatformWindowUnderMouse() method could be different for applets. So the getPlatformWindowUnderMouse() method implementation will be filled as a separated issue and fixed by Dmitry. Also, the logic in LWWindowPeer lines 722-743 seems to be overly complicated (as well as the whole dispatchMouseEvent() method). E.g., if the LWWindowPeer manages an embedded frame, we get topmostWindowPeer == this at line 730, and thus always go through the 'true' branch of if() at line 733, even though actually the mouse pointer can be located over some other window at the moment (e.g. over a popup window opened by an applet). I updated the topmostWindowPeer variable creation so it now can have only the topmost window under mouse value or null and added a comment that the (topmostWindowPeer == null ) condition should be removed after the getPlatformWindowUnderMouse() method implementation in the CPlatformEmbeddedFrame class. For now the (topmostWindowPeer == null ) condition allows to track the mouse enter/exit components events as it was before the fix. Overall, it's really difficult to understand what is going on there. I've spent half an hour reading the code and am still not sure if I get it right. Why does LWWindowPeer even care about the EXITED/ENTERED events for components? Shouldn't this code belong to LWComponentPeer? Or even the shared code? How do Swing components in regular Swing apps get the ENTERED/EXITED events then? Why can't we use the same approach for LWAWT? Swing controls have Container in a parent class hierarchy. The Container class has the LightweightDispatcher dispatcher which allows to track mouse moving from one component to another and generate necessary mouse enter/exit events. AWT controls have Component class as a parent and do not have the dispatcher. So moving/dragging a mouse from one AWT control to another does not generate necessary mouse events. The aim of the fix is not redesigning current architecture. It just adds checking a case where a mouse is dragged from one window to another and so the first window which gets the mouse drag events is not the real window for which component enter/exit events should be generated. Thanks, Alexandr. -- best regards, Anthony On 8/24/2012 5:53 PM, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ The comments are below: On 8/23/2012 4:51 PM, Anthony Petrov wrote: Hi Alexandr, 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate through app's windows only once and send both Exited and Entered events where needed? Now, when we do not care about the order of the mouse enter/exit events generation it is possible to do. I have updated the code. 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no longer requires a window pointer as an argument. Fixed. 3. Here's a major concern: the LWWindowPeer (and other LW* classes) should never import C* classes. Instead you should've added a new method to the PlatformWindow interface, and used it from LWWindowPeer. The CPlatformWindow should've implemented this method, and called an appropriate native method from there. In this case, however, you actually need a static method, so it'd better be part of the LWToolkit interface, and implemented in the LWCToolkit class instead. I see. It seems that the getTopmostWindowUnderMouse method implementation is different for the CPlatformWindow and for the CPlatformEmbeddedFrame. So I added the getTopmostPlatformWindowUnderMouse method to the PlatformWindow interface. Thanks, Alexandr. -- best regards, Anthony On 08/23/12 15:40, Alexander Scherbatiy wrote: Could someone review the fix? Thanks, Alexandr. On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote:
Re: AWT Dev [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test
Hi, Anthony
See my comments inline
On 28.08.2012 16:42, Anthony Petrov wrote:
Hi Konstantin,
I think you should modify the copyright headers in each file. The
files are no longer proprietary/confidential. .sh and makefiles should
also include a copyright header. Please use existing source files in
the open repository as a template for the header.
test/java/awt/JAWT/MyCanvas.java
52 f.show();
Please replace this with f.setVisible(true);
53 robot.delay(1);
I think 10 seconds is kind of too long. It might have been relevant
for Java 1.4, but now I think 5 seconds should be pretty much enough
for every modern system.
test/java/awt/JAWT/JAWT.sh
137 case $OS in
138 Windows* | CYGWIN* )
139 cp ${TESTJAVA}${FS}jre${FS}bin${FS}jawt.dll .
140 ;;
141 esac
Why is this necessary? This must be a bug in JDK if the library still
needs to be copied to the current directory on Windows. Could you
verify if the test still works w/o copying the dll? It must, actually.
I cannot verify it on JDK 8 (Windows only issue, Solaris and Linux work
fine) because on Windows this test compiles only with JDK 1.4.2 fcs b28!
Even if I use JDK 1.4.2 u39 b02, I have the following compiler error:
link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib
C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib
Creating library mylib.lib and object mylib.exp
myfile.obj : error LNK2019: unresolved external symbol
__imp__JAWT_GetAWT@8 referenced in function _Java_MyCanvas_paint@12
mylib.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'C:\\Program Files (x86)\\Microsoft Visual
Studio 11.0\\VC\\BIN\\link.EXE' : return code '0x460'
It seems there is no __imp__JAWT_GetAWT@8 in jawt.lib since 1.4.2 fcs...
--
best regards,
Anthony
On 8/27/2012 8:29 PM, Konstantin Shefov wrote:
Hello,
Please review a fix for the issue:
7190587 Open source and jtreg'ify JAWT regression test
Test was modified in to be run with jtreg.
The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/
Thanks,
Konstantin
Re: AWT Dev [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
Hi Alexander. Fix looks good. 28.08.2012 15:17, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.05/ The comments are below: - NSTrackingCursorUpdate option is removed from the rolloverTrackingArea On 8/24/2012 7:00 PM, Anthony Petrov wrote: src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java 66 public static native CPlatformWindow nativeGetTopmostPlatformWindowUnderMouse(); This method must probably be private. Fixed. Still, I don't see why getTopmostPlatformWindowUnderMouse() must return null when it's invoked on an embedded frame, and why the implementation should even be different at all. The mouse is a global system entity. There's either some window under the mouse, or there's not. I would still think of LWToolkit.getPlatformWindowUnderMouse(), and its implementation in LWCToolkit. Dmitry, who is a responsible person for the CPlatformEmbeddedFrame, said that the implementation of the getPlatformWindowUnderMouse() method could be different for applets. So the getPlatformWindowUnderMouse() method implementation will be filled as a separated issue and fixed by Dmitry. Also, the logic in LWWindowPeer lines 722-743 seems to be overly complicated (as well as the whole dispatchMouseEvent() method). E.g., if the LWWindowPeer manages an embedded frame, we get topmostWindowPeer == this at line 730, and thus always go through the 'true' branch of if() at line 733, even though actually the mouse pointer can be located over some other window at the moment (e.g. over a popup window opened by an applet). I updated the topmostWindowPeer variable creation so it now can have only the topmost window under mouse value or null and added a comment that the (topmostWindowPeer == null ) condition should be removed after the getPlatformWindowUnderMouse() method implementation in the CPlatformEmbeddedFrame class. For now the (topmostWindowPeer == null ) condition allows to track the mouse enter/exit components events as it was before the fix. Overall, it's really difficult to understand what is going on there. I've spent half an hour reading the code and am still not sure if I get it right. Why does LWWindowPeer even care about the EXITED/ENTERED events for components? Shouldn't this code belong to LWComponentPeer? Or even the shared code? How do Swing components in regular Swing apps get the ENTERED/EXITED events then? Why can't we use the same approach for LWAWT? Swing controls have Container in a parent class hierarchy. The Container class has the LightweightDispatcher dispatcher which allows to track mouse moving from one component to another and generate necessary mouse enter/exit events. AWT controls have Component class as a parent and do not have the dispatcher. So moving/dragging a mouse from one AWT control to another does not generate necessary mouse events. The aim of the fix is not redesigning current architecture. It just adds checking a case where a mouse is dragged from one window to another and so the first window which gets the mouse drag events is not the real window for which component enter/exit events should be generated. Thanks, Alexandr. -- best regards, Anthony On 8/24/2012 5:53 PM, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ The comments are below: On 8/23/2012 4:51 PM, Anthony Petrov wrote: Hi Alexandr, 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate through app's windows only once and send both Exited and Entered events where needed? Now, when we do not care about the order of the mouse enter/exit events generation it is possible to do. I have updated the code. 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no longer requires a window pointer as an argument. Fixed. 3. Here's a major concern: the LWWindowPeer (and other LW* classes) should never import C* classes. Instead you should've added a new method to the PlatformWindow interface, and used it from LWWindowPeer. The CPlatformWindow should've implemented this method, and called an appropriate native method from there. In this case, however, you actually need a static method, so it'd better be part of the LWToolkit interface, and implemented in the LWCToolkit class instead. I see. It seems that the getTopmostWindowUnderMouse method implementation is different for the CPlatformWindow and for the CPlatformEmbeddedFrame. So I added the getTopmostPlatformWindowUnderMouse method to the PlatformWindow interface. Thanks, Alexandr. -- best regards, Anthony On 08/23/12 15:40, Alexander Scherbatiy wrote: Could someone review the fix? Thanks, Alexandr. On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ The
Re: AWT Dev [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test
No, it is not the case. I checked it before already. As I have said test compiles successfully with JDK 1.4.2b28, so path is OK. I even tried to do as you have said right now (no jtreg, no MKS), and nothing changed as expected. Test passes against jdk 1.4.2b28 and fails against jdk 1.4.2_39b02 and jdk 8b53. LOG 1.4.2 u39 (dll is NOT produced): C:\JTwork\scratchnmake -f Makefile.win Microsoft (R) Program Maintenance Utility Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. cl -nologo -IC:\jdk\j2sdk1.4.2_39b02\include\win32 -IC:\jdk\j2sdk1.4.2_39b02\include -c myfile.cpp myfile.cpp link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib -LIBPATH:C:\jdk\j2sdk1.4.2_39b02\lib jawt.lib Creating library mylib.lib and object mylib.exp myfile.obj : error LNK2019: unresolved external symbol __imp__JAWT_GetAWT@8 referenced in function _Java_MyCanvas_paint@12 mylib.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\link.EXE' : return code '0x460' Stop. LOG 1.4.2 fcs (no errors, dll is produced): C:\JTwork\scratchnmake -f Makefile.win Microsoft (R) Program Maintenance Utility Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. cl -nologo -IC:\jdk\j2sdk1.4.2b28\include\win32 -IC:\jdk\j2sdk1.4.2b28\include -c myfile.cpp myfile.cpp link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib -LIBPATH:C:\jdk\j2sdk1.4.2b28\lib jawt.lib Creating library mylib.lib and object mylib.exp LOG 8 b51 (dll is NOT produced): C:\JTwork\scratchnmake -f Makefile.win Microsoft (R) Program Maintenance Utility Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. cl -nologo -IC:\jdk\jdk1.8.0b51\include\win32 -IC:\jdk\jdk1.8.0b51\include -c myfile.cpp myfile.cpp link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib -LIBPATH:C:\jdk\jdk1.8.0b51\lib jawt.lib Creating library mylib.lib and object mylib.exp myfile.obj : error LNK2019: unresolved external symbol __imp__JAWT_GetAWT@8 referenced in function _Java_MyCanvas_paint@12 mylib.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\link.EXE' : return code '0x460' Stop. On 28.08.2012 17:46, Anthony Petrov wrote: On 8/28/2012 5:13 PM, Konstantin Shefov wrote: Why is this necessary? This must be a bug in JDK if the library still needs to be copied to the current directory on Windows. Could you verify if the test still works w/o copying the dll? It must, actually. I cannot verify it on JDK 8 (Windows only issue, Solaris and Linux work fine) because on Windows this test compiles only with JDK 1.4.2 fcs b28! Even if I use JDK 1.4.2 u39 b02, I have the following compiler error: link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib I believe this line causes the error. The linker simply doesn't see the jawt.lib module. Please try using the following name for the module: C:\jdk\j2sdk1.4.2_39b02\lib\jawt.lib instead of the current one: C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib (note the changes in slashes). I think make and/or cygwin/MKS can mangle the file name. There must be a way to make them return a proper full path name for the file so that the linker could see the module. Actually, I suggest to pass the following option to the linker: -LC:\jdk\j2sdk1.4.2_39b02\lib and list the jawt.lib simply by name together with other .lib's you're linking against. Please try this and see if it works for you. -- best regards, Anthony Creating library mylib.lib and object mylib.exp myfile.obj : error LNK2019: unresolved external symbol __imp__JAWT_GetAWT@8 referenced in function _Java_MyCanvas_paint@12 mylib.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\VC\\BIN\\link.EXE' : return code '0x460' It seems there is no __imp__JAWT_GetAWT@8 in jawt.lib since 1.4.2 fcs... -- best regards, Anthony On 8/27/2012 8:29 PM, Konstantin Shefov wrote: Hello, Please review a fix for the issue: 7190587 Open source and jtreg'ify JAWT regression test Test was modified in to be run with jtreg. The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/ Thanks, Konstantin
Re: AWT Dev [8] Review request for 7186109: Simplify lock machinery for PostEventQueue EventQueue
Hi Artem, Anthony, thank you for your proposals! We with Artem also had off-line discussion, so as a result I prepared improved version of fix: http://cr.openjdk.java.net/~bagiras/8/7186109.3/ What was done: 1. EventQueue.detachDispatchThread(): moved SunToolkit.flushPnedingEvents() above the comments and added a separate comment to it. 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to SunToolkit. Deleted SunToolkitSubclass. 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - isThreadLocalFlushing and made it ThreadLocal. 4. Left PostEventQueue.flush() unsynchronized and created wait()-notifyAll() synchronization mechanism to avoid blocking of PostEventQueue.postEvent(). Looking forward to your comments! Thanks, Oleg 20.08.2012 20:20, Artem Ananiev wrote: Hi, Oleg, here are a few comments: 1. What is the reason of keeping isFlushingPendingEvents in SunToolkit, given that PEQ.flush() is synchronized (and therefore serialized) anyway? 2. flushPendingEvents(AppContext) may be moved directly to SunToolkit, so we don't need a separate sun-class for that. 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced by another one. Thanks, Artem On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: Hi! Please review the fix for CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 Webrev: http://cr.openjdk.java.net/~bagiras/8/7186109.1/ The following changes were made: 1. Removed flushLock from SunToolkit.flushPendingEvent() 2. Returned method PostEventQueue.flush() as 'synchronized' back 3. Added call of SunToolkit.flushPendingEvents() to EventQueue.detachDispatchThread(), right before pushPopLock.lock() 4. Removed !SunToolkit.isPostEventQueueEmpty() check from EventQueue.detachDispatchThread() 5. Removed SunToolkit.isPostEventQueueEmpty() PostEventQueue.noEvents(); Thanks, Oleg http://cr.openjdk.java.net/%7Ebagiras/8/7186109.1/
Re: AWT Dev [7u8] Review request for 7193219: JComboBox serialization fails in JDK 1.7
Hello Anthony, Thank you for the review and additional information concerning the process of handling GraphicsConfiguration in AWT package. But I decided to fix this issue from side of Swing package. A corresponding review request was sent to swing-...@openjdk.java.net e-mail alias. Thank you, Anton On 27.08.2012 18:53, Anton Litvinov wrote: Hello Anthony, Thank you for the review. I would like to clarify that this issue is an escalation. After working on this bug I came to a conclusion that a reason of this bug is the fact that updateGraphicsData() method of not completely deserialized container is called during deserialization process. In this case the situation is the following: 1. readObject() method of JPanel is called. 1.1. readObject() method of JFrame is called during deserialization of JPanel's subcomponents, since they depend on JFrame through PropertyChangeSupport field. 1.2. initDeserializedWindow of JFrame as java.awt.Window is called and leads to subsequent calls to updateGraphicsData() of all subcomponents including that JPanel in step 1, which was not executed completely yet. Deferring of updateGraphicsData() method could be a solution, but how can this be done technically? Also is there a guarantee that no logic, which executes after updateGraphicsData() and before the end of deserialization, relies on the results of updateGraphicsData() method? This issue is reproducible on JDK 8 too, but since it was originally escalated on JDK 7 it should be fixed on JDK 7 first and then fixed in JDK 8. Concerning a name of a directory containing the test, I am a new employee and I do not know the exact naming conventions. But before doing this I searched for existing tests and found many directories created in 2012 whose names contain bug numbers. I am ready to apply what ever name is better. I do not think that the test case can be written without Swing package, because it is related to certain escalation and I do not have right to change the original test case provided with escalation significantly. Thank you, Anton On 27.08.2012 16:56, Anthony Petrov wrote: Also, I suggest to name the test directory/filename with a human-readable name (just like all the other tests in AWT area do). BTW, since this is an AWT test, do we actually have to use Swing there? Can we make it an AWT-only test? -- best regards, Anthony On 08/27/12 16:49, Anthony Petrov wrote: Hi Anton, After deserialization completes, the components in the 'component' collection must all share the same graphics configuration as its parent container (which is being deserialized). While your fix resolves the NPE, it doesn't yet sets up the child components with the correct graphics configuration after the 'component' collection has been populated which children during deserialization. I think we should probably add a deferred call to updateGraphicsData() somewhere at the readObject() method. Also, should this issue be fixed for JDK 8 first, and then ported back to JDK 7u? -- best regards, Anthony On 08/24/12 21:36, Anton Litvinov wrote: Hello, Please review the following fix for a bug. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219 Webrev: http://cr.openjdk.java.net/~alexp/7193219/webrev.00 For details on this bug please look at Evaluation field on a web page of this bug. The provided webrev contains both a fix and a corresponding unit-test. Also before publishing this webrev all unit-test from the java.awt and javax.swing swing related to serialization and usage of GraphicsConfiguration class were run and no negative changes were observed comparing the results of tests' runs on JDK with and without patch represented by this webrev. Thank you, Anton
Re: AWT Dev [7u8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.
Hi Alexander, 1. Does the closed/javax/swing/plaf/basic/BasicToolBarUI/4331392/bug4331392.java test (mentioned in 7154048) pass with this fix? 2. What is the plan for DragWindowTest.java? We should either remove it with this fix, or file a CR and remove '@' from the '@run' jtreg tag so that it wouldn't fail for the time being. -- best regards, Anthony On 8/28/2012 4:57 PM, Alexander Scherbatiy wrote: Hello, Please review the fix for the JDK 7u8: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev7.00/ This is a regression after the fix 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In the case where a toolbar is created under a mouse and it is dragged over the initial window the mouse enter/exit events should not be generated for the components which are under the toolbar. The disabling component mouse enter/exit events generation during drag leads that it does not work in the case where a mouse is dragged over the current window. The full fix that checks that a current window is a topmost window under mouse requires some changes (using tracking area instead of tracking rectangle and so on) is a quite complicated and it seems that it is risky to include it to the JDK 7u8. Current fix just changes the condition for the component mouse enter/exit events generation to the initial state how it was before the 7154048 fix. This allows to generate components mouse enter/exit events, but the following test will fail: java/awt/Mouse/EnterExitEvents/DragWindowTest.java However this test did not work before the 7154048 fix so it is not a regression. Thanks, Alexandr.
Re: AWT Dev [7u8] Review request for 7193219: JComboBox serialization fails in JDK 1.7
Thanks. I've reviewed your new fix already. Note that someone else from Swing team must also take a look at it to make sure it's OK. -- best regards, Anthony On 8/28/2012 8:25 PM, Anton Litvinov wrote: Hello Anthony, Thank you for the review and additional information concerning the process of handling GraphicsConfiguration in AWT package. But I decided to fix this issue from side of Swing package. A corresponding review request was sent to swing-...@openjdk.java.net e-mail alias. Thank you, Anton On 27.08.2012 18:53, Anton Litvinov wrote: Hello Anthony, Thank you for the review. I would like to clarify that this issue is an escalation. After working on this bug I came to a conclusion that a reason of this bug is the fact that updateGraphicsData() method of not completely deserialized container is called during deserialization process. In this case the situation is the following: 1. readObject() method of JPanel is called. 1.1. readObject() method of JFrame is called during deserialization of JPanel's subcomponents, since they depend on JFrame through PropertyChangeSupport field. 1.2. initDeserializedWindow of JFrame as java.awt.Window is called and leads to subsequent calls to updateGraphicsData() of all subcomponents including that JPanel in step 1, which was not executed completely yet. Deferring of updateGraphicsData() method could be a solution, but how can this be done technically? Also is there a guarantee that no logic, which executes after updateGraphicsData() and before the end of deserialization, relies on the results of updateGraphicsData() method? This issue is reproducible on JDK 8 too, but since it was originally escalated on JDK 7 it should be fixed on JDK 7 first and then fixed in JDK 8. Concerning a name of a directory containing the test, I am a new employee and I do not know the exact naming conventions. But before doing this I searched for existing tests and found many directories created in 2012 whose names contain bug numbers. I am ready to apply what ever name is better. I do not think that the test case can be written without Swing package, because it is related to certain escalation and I do not have right to change the original test case provided with escalation significantly. Thank you, Anton On 27.08.2012 16:56, Anthony Petrov wrote: Also, I suggest to name the test directory/filename with a human-readable name (just like all the other tests in AWT area do). BTW, since this is an AWT test, do we actually have to use Swing there? Can we make it an AWT-only test? -- best regards, Anthony On 08/27/12 16:49, Anthony Petrov wrote: Hi Anton, After deserialization completes, the components in the 'component' collection must all share the same graphics configuration as its parent container (which is being deserialized). While your fix resolves the NPE, it doesn't yet sets up the child components with the correct graphics configuration after the 'component' collection has been populated which children during deserialization. I think we should probably add a deferred call to updateGraphicsData() somewhere at the readObject() method. Also, should this issue be fixed for JDK 8 first, and then ported back to JDK 7u? -- best regards, Anthony On 08/24/12 21:36, Anton Litvinov wrote: Hello, Please review the following fix for a bug. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219 Webrev: http://cr.openjdk.java.net/~alexp/7193219/webrev.00 For details on this bug please look at Evaluation field on a web page of this bug. The provided webrev contains both a fix and a corresponding unit-test. Also before publishing this webrev all unit-test from the java.awt and javax.swing swing related to serialization and usage of GraphicsConfiguration class were run and no negative changes were observed comparing the results of tests' runs on JDK with and without patch represented by this webrev. Thank you, Anton
