From alexandr.scherbatiy at oracle.com Tue May 5 10:18:25 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 05 May 2015 13:18:25 +0300 Subject: [9] Review Request: JDK-8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in WindowsClassicLookAndFeel In-Reply-To: <554292E6.7080608@oracle.com> References: <554292E6.7080608@oracle.com> Message-ID: <554898F1.3060604@oracle.com> On 4/30/2015 11:39 PM, pooja chopra wrote: > Hello, > Please review a fix for issue: > 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails > in WindowsClassicLookAndFeel > Test bug fix. > https://bugs.openjdk.java.net/browse/JDK-8078855 > The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.00/ Does the fix work on Mac OS X with the Aqua L&F? Thanks, Alexandr. > > Thanks, > Pooja From alexey.ivanov at oracle.com Tue May 5 13:16:22 2015 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 05 May 2015 16:16:22 +0300 Subject: [9] Review Request: JDK-8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in WindowsClassicLookAndFeel In-Reply-To: <554292E6.7080608@oracle.com> References: <554292E6.7080608@oracle.com> Message-ID: <5548C2A6.5070207@oracle.com> Hello Pooja, The modified test case does not reproduce the problem reported in https://bugs.openjdk.java.net/browse/JDK-8032878. So this fix cannot be applied to the regression test. I confirm that the original test fails in WindowsClassicLookAndFeel because the editor selects the text, thus the typed text '123' is not added to existing text but replaces it. It could be a bug in WindowsClassicLookAndFeel or its feature. If it's not a bug, then the test should expect the value of "123" rather than "one123" where WindowsClassicLookAndFeel is used. Regards, Alexey On 30.04.2015 23:39, pooja chopra wrote: > Hello, > Please review a fix for issue: > 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails > in WindowsClassicLookAndFeel > Test bug fix. > https://bugs.openjdk.java.net/browse/JDK-8078855 > The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.00/ > > Thanks, > Pooja From Sergey.Bylokhov at oracle.com Tue May 5 16:24:14 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 05 May 2015 19:24:14 +0300 Subject: 8077409: Drawing deviates when validate() is invoked on java.awt.ScrollPane In-Reply-To: <5542861C.30103@oracle.com> References: <5542861C.30103@oracle.com> Message-ID: <5548EEAE.9030305@oracle.com> Hi, Mikhail. Is it possible to write a test for this issue based on the code in the bug report? On 30.04.15 22:44, mikhail cherkasov wrote: > Hi there, > > Could you please review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8077409 > webrev: http://cr.openjdk.java.net/~mcherkas/8077409v9/webrev.00/ > > In ScrollPane, move() is called without considering the quota of > Insets when invoking ScrollPane$PeerFixer.adjustmentValueChanged(). When > validate() is called, drawing deviates to coordinate with Insets > interanlly. > > Thanks, > Mikhail. > > -- Best regards, Sergey. From shobhit.s.gupta at oracle.com Wed May 6 10:37:28 2015 From: shobhit.s.gupta at oracle.com (shobhit gupta) Date: Wed, 06 May 2015 16:07:28 +0530 Subject: [9-dev] Review request for bug 8079440 : [TESTBUG] @run is missing in java/awt/TrayIcon/8072769/bug8072769.java Message-ID: <5549EEE8.9040806@oracle.com> |Hi,| |Please review a fix ||for| |the issue:| JDK-8079440 : [TESTBUG] @run is missing in java/awt/TrayIcon/8072769/bug8072769.java| | https://bugs.openjdk.java.net/browse/JDK-8079440 |Webrev is : http://cr.openjdk.java.net/~sgupta/8079440/webrev.00/ Thanks and Regards, Shobhit Gupta | -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu May 7 00:39:13 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 07 May 2015 03:39:13 +0300 Subject: [9] Review Request: 8071306 GUI perfomance are very slow compared java 1.6.0_45 Message-ID: <554AB431.1040707@oracle.com> Hello. Please review the fix for a jdk9. I plan to backport it to jdk8u60. Description. An UIworks really slowly, when an application has a lot of components in one container, and these components should be disabled one by one. The reason is the next sequence of methods calls: Component.setEnabled->updateCursorImmediately()-> some cursor related staff->GlobalCursorManager._updateCursor->Container.findComponentAt()-iteration over all components in the container.....-> twice.... You can imagine how it works in case of 10000 components in the container. Note that in the bug report described difference jdk6 vs jdk8 -> 1sec vs 6 sec. This was caused by the two fixes, one of which adds checkTreeLock() and in another one a simple array of components was replaced by the ArrayList. Since code was added to the really hot method we got so big slowdown. To fix the problem I suggest two different approaches: - Container.java: Fix a general case, by eliminating a second iteration in the hot loop. - Component.java: Totally eliminates cursor machinery, if component cannot affect current cursor. Some speedup measurements on my local system: - Simple removing of checkTreeLock() will partly solve a regression reported by the user(12 sec -> 5 sec). - Changes in the loop will speedup the code in the worse case(5->2 sec) - The changes in the Component.java will change the performance from 2 sec to 100< ms Test case which was added was improved from 10 seconds to 80 ms. JMH test: http://cr.openjdk.java.net/~serb/8071306/SetEnabledPerformanceTest.java Fixedversion: Benchmark Mode Cnt Score Error Units SetEnabledPerformanceTest.testContains thrpt 5 301300,813 ? 17338,045 ops/ms SetEnabledPerformanceTest.testFindComponentAt thrpt 5 20,521 ? 0,269 ops/ms SetEnabledPerformanceTest.testGetComponentAt thrpt 5 22,297 ? 1,264 ops/ms SetEnabledPerformanceTest.testSetEnabled thrpt 5 711,120 ? 19,837 ops/ms Base version: Benchmark Mode Cnt Score Error Units SetEnabledPerformanceTest.testContains thrpt 5 299145,642 ? 2120,183 ops/ms SetEnabledPerformanceTest.testFindComponentAt thrpt 5 1,101 ? 0,012 ops/ms SetEnabledPerformanceTest.testGetComponentAt thrpt 5 6,792 ? 0,097 ops/ms SetEnabledPerformanceTest.testSetEnabled thrpt 5 0,464 ? 0,020 ops/ms Bug: https://bugs.openjdk.java.net/browse/JDK-8071306 Webrev can be found at: http://cr.openjdk.java.net/~serb/8071306/webrev.03 -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu May 7 08:14:28 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 07 May 2015 11:14:28 +0300 Subject: [9] Review request for 8003399: JFileChooser gives wrong path to selected file when saving to Libraries folder on Windows 7 Message-ID: <554B1EE4.1080001@oracle.com> Hello, Please review fix for JDK9. webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8003399 ***THE ROOT CAUSE JDK uses legacy WINAPI special folders calls while MS introduced a new interfaces IKnownFolder and IShellLibrary to manage special folder locations and the new Libraries functionality in Windows 7 is not backward compatible with old special folders CSIDL. ***SOLUTION Since it is too expensive to migrate AWT shell to the new interfaces and still they are not supported in java.io the solution is to map virtual folder PIDL to the Known Folder GUID and replace libraries links with the default library save location. Thus the File save dialog will be able to work with any Libraries registered in the system (Windows Libraries concept assumes that Libraries can be added arbitrary). The resulting code should be compatible with older Windows versions because the new COM interfaces are called only if they are available and a Libraries link has been actually requested. ***TESTING A test scenario is added to check that all available Libraries links are converted into filesystem paths. --Semyon From Sergey.Bylokhov at oracle.com Thu May 7 08:26:45 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 07 May 2015 11:26:45 +0300 Subject: [9] Review request for 8003399: JFileChooser gives wrong path to selected file when saving to Libraries folder on Windows 7 In-Reply-To: <554B1EE4.1080001@oracle.com> References: <554B1EE4.1080001@oracle.com> Message-ID: <554B21C5.9020500@oracle.com> Hi, Semyon. Can you please raise the supportness of this in the java.io on the core-libs alias. Does the open filedialog will work after the fix? On 07.05.15 11:14, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9. > webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8003399 > > ***THE ROOT CAUSE > JDK uses legacy WINAPI special folders calls while MS introduced a new > interfaces IKnownFolder and IShellLibrary to manage special folder > locations and the new Libraries functionality in Windows 7 is not > backward compatible with old special folders CSIDL. > > ***SOLUTION > Since it is too expensive to migrate AWT shell to the new interfaces > and still they are not supported in java.io the solution is to map > virtual folder PIDL to the Known Folder GUID and replace libraries > links with the default library save location. Thus the File save > dialog will be able to work with any Libraries registered in the > system (Windows Libraries concept assumes that Libraries can be added > arbitrary). > The resulting code should be compatible with older Windows versions > because the new COM interfaces are called only if they are available > and a Libraries link has been actually requested. > > ***TESTING > A test scenario is added to check that all available Libraries links > are converted into filesystem paths. > > --Semyon > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu May 7 09:44:54 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 07 May 2015 12:44:54 +0300 Subject: [9] Review request for 8079255 [macosx] Test closed/java/awt/Robot/RobotWheelTest/RobotWheelTest fails for Mac only Message-ID: <554B3416.1070800@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8079255 webrev: http://cr.openjdk.java.net/~alexsch/8079255/webrev.00 The test does not take into account that the MouseWheelEvent.getWheelRotation() has reversed value on Mac OS X. The test is updated and moved to the open repository. Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Thu May 7 10:29:08 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 07 May 2015 13:29:08 +0300 Subject: [9] Review request for 8079255 [macosx] Test closed/java/awt/Robot/RobotWheelTest/RobotWheelTest fails for Mac only In-Reply-To: <554B3416.1070800@oracle.com> References: <554B3416.1070800@oracle.com> Message-ID: <554B3E74.40207@oracle.com> Hi, Alexander. Please dispose the frame at the end of the test. Also please update the first date in the copyright. It is interesting to think about a public api for mouse_wheel rotation direction. On 07.05.15 12:44, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8079255 > webrev: http://cr.openjdk.java.net/~alexsch/8079255/webrev.00 > > The test does not take into account that the > MouseWheelEvent.getWheelRotation() has reversed value on Mac OS X. > The test is updated and moved to the open repository. > > > Thanks, > Alexandr. > -- Best regards, Sergey. From semyon.sadetsky at oracle.com Thu May 7 12:29:21 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 07 May 2015 15:29:21 +0300 Subject: [9] Review request for 8003399: JFileChooser gives wrong path to selected file when saving to Libraries folder on Windows 7 In-Reply-To: <554B21C5.9020500@oracle.com> References: <554B1EE4.1080001@oracle.com> <554B21C5.9020500@oracle.com> Message-ID: <554B5AA1.1080206@oracle.com> Hi Sergey, Yes, after the fix filedialog produces usual filesystem paths for libraries which are readable for java.io. But there are no possibility to reference files in libraries directly using new File(). --Semyon On 5/7/2015 11:26 AM, Sergey Bylokhov wrote: > Hi, Semyon. > Can you please raise the supportness of this in the java.io on the > core-libs alias. > Does the open filedialog will work after the fix? > > On 07.05.15 11:14, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9. >> webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8003399 >> >> ***THE ROOT CAUSE >> JDK uses legacy WINAPI special folders calls while MS introduced a >> new interfaces IKnownFolder and IShellLibrary to manage special >> folder locations and the new Libraries functionality in Windows 7 is >> not backward compatible with old special folders CSIDL. >> >> ***SOLUTION >> Since it is too expensive to migrate AWT shell to the new interfaces >> and still they are not supported in java.io the solution is to map >> virtual folder PIDL to the Known Folder GUID and replace libraries >> links with the default library save location. Thus the File save >> dialog will be able to work with any Libraries registered in the >> system (Windows Libraries concept assumes that Libraries can be added >> arbitrary). >> The resulting code should be compatible with older Windows versions >> because the new COM interfaces are called only if they are available >> and a Libraries link has been actually requested. >> >> ***TESTING >> A test scenario is added to check that all available Libraries links >> are converted into filesystem paths. >> >> --Semyon >> > > From alexander.zvegintsev at oracle.com Thu May 7 13:16:02 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 07 May 2015 16:16:02 +0300 Subject: [9-dev] Review request for bug 8079440 : [TESTBUG] @run is missing in java/awt/TrayIcon/8072769/bug8072769.java In-Reply-To: <5549EEE8.9040806@oracle.com> References: <5549EEE8.9040806@oracle.com> Message-ID: <554B6592.8050403@oracle.com> Hi, the bug8072769.java looks fine to me. Path2DCopyConstructor.java is already fixed by [1]. [1] https://bugs.openjdk.java.net/browse/JDK-8078464 Thanks, Alexander. On 05/06/2015 01:37 PM, shobhit gupta wrote: > |Hi,| > |Please review a fix ||for| |the issue:| > > JDK-8079440 : [TESTBUG] @run is missing in > java/awt/TrayIcon/8072769/bug8072769.java| > | > https://bugs.openjdk.java.net/browse/JDK-8079440 > |Webrev is : http://cr.openjdk.java.net/~sgupta/8079440/webrev.00/ > > Thanks and Regards, > Shobhit Gupta > | -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu May 7 15:29:53 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 07 May 2015 18:29:53 +0300 Subject: [9] Review Request: 8015900 [TEST_BUG] ScrollbarMouseWheelTest failed on ubuntu 12 with unity and unity 2D Message-ID: <554B84F1.9080505@oracle.com> Hello. Please review the fix for jdk9. The test has incorrect assumption that the new window usually opens in the top-left corner of the window, and moves the robot according this assumption. - This assumption was fixed via getLocationOnScreen - Unnecessary stuff were removed - Test was moved to the open, both diffs were provided Bug: https://bugs.openjdk.java.net/browse/JDK-8015900 Webrevs can be found at: http://cr.openjdk.java.net/~serb/8015900/webrev.00 http://cr.openjdk.java.net/~serb/8015900/diff -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Fri May 8 04:02:22 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 08 May 2015 07:02:22 +0300 Subject: [9] Review Request: 8015900 [TEST_BUG] ScrollbarMouseWheelTest failed on ubuntu 12 with unity and unity 2D In-Reply-To: <554B84F1.9080505@oracle.com> References: <554B84F1.9080505@oracle.com> Message-ID: <554C354E.9000904@oracle.com> Hello Sergey, the fix looks good to me. Thanks, Alexander. On 07/05/15 18:29, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > The test has incorrect assumption that the new window usually opens in > the top-left corner of the window, and moves the robot according this > assumption. > - This assumption was fixed via getLocationOnScreen > - Unnecessary stuff were removed > - Test was moved to the open, both diffs were provided > > Bug: https://bugs.openjdk.java.net/browse/JDK-8015900 > Webrevs can be found at: > http://cr.openjdk.java.net/~serb/8015900/webrev.00 > http://cr.openjdk.java.net/~serb/8015900/diff > From yuri.nesterenko at oracle.com Fri May 8 08:19:57 2015 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 08 May 2015 11:19:57 +0300 Subject: [9] Review Request: 8015900 [TEST_BUG] ScrollbarMouseWheelTest failed on ubuntu 12 with unity and unity 2D In-Reply-To: <554B84F1.9080505@oracle.com> References: <554B84F1.9080505@oracle.com> Message-ID: <554C71AD.6050900@oracle.com> Hi Sergey, fine with me. BTW will it work on the multimonitor OS X configuration:-)? -yan On 05/07/2015 06:29 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > The test has incorrect assumption that the new window usually opens in > the top-left corner of the window, and moves the robot according this > assumption. > - This assumption was fixed via getLocationOnScreen > - Unnecessary stuff were removed > - Test was moved to the open, both diffs were provided > > Bug: https://bugs.openjdk.java.net/browse/JDK-8015900 > Webrevs can be found at: > http://cr.openjdk.java.net/~serb/8015900/webrev.00 > http://cr.openjdk.java.net/~serb/8015900/diff > From anton.tarasov at oracle.com Fri May 8 09:23:31 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 08 May 2015 12:23:31 +0300 Subject: [9] Review Request: 8071306 GUI perfomance are very slow compared java 1.6.0_45 In-Reply-To: <554AB431.1040707@oracle.com> References: <554AB431.1040707@oracle.com> Message-ID: <554C8093.50205@oracle.com> Hi Sergey, The perf improvment is great! I have some minor comments only: 1. 1314 /** 1315 * Determines the bounds which will be displayed on the screen. 1316 * 1317 * @return the visible part of bounds in the coordinate space of this comp 1318 */ 1319 private Rectangle getRecursivelyVisibleBounds() { Could you please clarify the comment, it's not quite clear from the first glance. Something like: "the bounds of a visible part of the component relative to..." 2. 100 * The components in this container. 101 * @see #add 102 * @see #getComponents 103 */ 104 private java.util.List component = new ArrayList<>(); May be it's worth to rename the field? The "component" name is odd... Regards, Anton. On 07.05.2015 3:39, Sergey Bylokhov wrote: > Hello. > Please review the fix for a jdk9. I plan to backport it to jdk8u60. > > Description. > An UIworks really slowly, when an application has a lot of components in one container, and these > components should be disabled one by one. > The reason is the next sequence of methods calls: > Component.setEnabled->updateCursorImmediately()-> some cursor related > staff->GlobalCursorManager._updateCursor->Container.findComponentAt()-iteration over all > components in the container.....-> twice.... > > You can imagine how it works in case of 10000 components in the container. > > Note that in the bug report described difference jdk6 vs jdk8 -> 1sec vs 6 sec. This was caused by > the two fixes, one of which adds checkTreeLock() and in another one a simple array of components > was replaced by the ArrayList. Since code was added to the really hot method we got so big slowdown. > > To fix the problem I suggest two different approaches: > - Container.java: Fix a general case, by eliminating a second iteration in the hot loop. > - Component.java: Totally eliminates cursor machinery, if component cannot affect current cursor. > > Some speedup measurements on my local system: > - Simple removing of checkTreeLock() will partly solve a regression reported by the user(12 sec > -> 5 sec). > - Changes in the loop will speedup the code in the worse case(5->2 sec) > - The changes in the Component.java will change the performance from 2 sec to 100< ms > > Test case which was added was improved from 10 seconds to 80 ms. > > JMH test: http://cr.openjdk.java.net/~serb/8071306/SetEnabledPerformanceTest.java > > Fixedversion: > > Benchmark Mode Cnt Score Error Units > SetEnabledPerformanceTest.testContains thrpt 5 301300,813 ? 17338,045 ops/ms > SetEnabledPerformanceTest.testFindComponentAt thrpt 5 20,521 ? 0,269 ops/ms > SetEnabledPerformanceTest.testGetComponentAt thrpt 5 22,297 ? 1,264 ops/ms > SetEnabledPerformanceTest.testSetEnabled thrpt 5 711,120 ? 19,837 ops/ms > > Base version: > > Benchmark Mode Cnt Score Error Units > SetEnabledPerformanceTest.testContains thrpt 5 299145,642 ? 2120,183 ops/ms > SetEnabledPerformanceTest.testFindComponentAt thrpt 5 1,101 ? 0,012 ops/ms > SetEnabledPerformanceTest.testGetComponentAt thrpt 5 6,792 ? 0,097 ops/ms > SetEnabledPerformanceTest.testSetEnabled thrpt 5 0,464 ? 0,020 ops/ms > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8071306 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8071306/webrev.03 > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.tarasov at oracle.com Fri May 8 09:47:00 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 08 May 2015 12:47:00 +0300 Subject: [9] Review request for 8003399: JFileChooser gives wrong path to selected file when saving to Libraries folder on Windows 7 In-Reply-To: <554B1EE4.1080001@oracle.com> References: <554B1EE4.1080001@oracle.com> Message-ID: <554C8614.9090101@oracle.com> Hi Semyon, Some comments: - Please, correct the name to KnownfolderDefinition, or better KnownFolderDefinition: + static class KnownfolderDefenition { - Should JNI exceptions be asserted in Java_sun_awt_shell_Win32ShellFolder2_loadKnownFolders? Regards, Anton. On 07.05.2015 11:14, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9. > webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8003399 > > ***THE ROOT CAUSE > JDK uses legacy WINAPI special folders calls while MS introduced a new interfaces IKnownFolder and > IShellLibrary to manage special folder locations and the new Libraries functionality in Windows 7 > is not backward compatible with old special folders CSIDL. > > ***SOLUTION > Since it is too expensive to migrate AWT shell to the new interfaces and still they are not > supported in java.io the solution is to map virtual folder PIDL to the Known Folder GUID and > replace libraries links with the default library save location. Thus the File save dialog will be > able to work with any Libraries registered in the system (Windows Libraries concept assumes that > Libraries can be added arbitrary). > The resulting code should be compatible with older Windows versions because the new COM interfaces > are called only if they are available and a Libraries link has been actually requested. > > ***TESTING > A test scenario is added to check that all available Libraries links are converted into filesystem > paths. > > --Semyon > From alexandr.scherbatiy at oracle.com Fri May 8 12:28:31 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 08 May 2015 15:28:31 +0300 Subject: [9] Review request for 8065739 [macosx] Frame warps to lower left of screen when displayed In-Reply-To: <554100C2.6050902@oracle.com> References: <5525410A.8080407@oracle.com> <552EC29D.3090706@oracle.com> <554100C2.6050902@oracle.com> Message-ID: <554CABEF.7030502@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8065739/webrev.03 - The -windowWillUseStandardFrame:defaultFrame: method is implemented in AWTWindow to correctly get and check a size of the maximized window. After that the -isZoomed method correctly defines the zoomed state for both visible and not visible window. Thanks, Alexandr. On 4/29/2015 7:03 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8065739/webrev.02 > > - the zoom state is applied after NSWindow creation if Frame has > MAXIMIZED_BOTH state. > > Thanks, > Alexandr. > > On 4/15/2015 10:57 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> As far as I understand the main issue is that we get a native >> notifications during window initialization(after nswindows was >> created and before zoom method will be called)? Probably we can apply >> the zoom state when we create a window in one appkit call? >> >> On 08.04.15 17:54, Alexander Scherbatiy wrote: >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8065739 >>> webrev: http://cr.openjdk.java.net/~alexsch/8065739/webrev.00 >>> >>> Use case: >>> ------------ >>> Frame frame = new Frame(); >>> frame.pack(); >>> frame.setBounds(screenBounds); >>> frame.setVisible(true); >>> ------------ >>> >>> The frame is in the normal state but Mac OS X treats a frame with >>> screen bounds as zoomed. >>> The setVisible() method calls unmaximize() method to return the >>> zoomed window to the normal state. >>> The native zoom() method sets the initial sizes for the window >>> which are zero because of the pack() call. >>> >>> >>> There is already checkZoom() method which synchronizes native >>> window zoom state and and the frame extended state when a frame is >>> resized by mouse. >>> However it can't be always used for the synchronization between >>> native window zoom state and setBounds() call because of the >>> following case: >>> >>> ----------------- >>> Frame frame = new Frame(); >>> frame.setBounds(smallBounds); >>> frame.setExtendedState(Frame.MAXIMIZED_BOTH); >>> frame.setVisible(true); >>> ----------------- >>> >>> This is the valid scenario where the frame should be maximized. >>> >>> The solution synchronizes the zoom and the frame state only when >>> the native window is zoomed. >>> In opposite case we need to return from the zoomed sizes to >>> previous sizes which are the same as for the zoomed window. >>> >>> Thanks, >>> Alexandr. >>> >> >> > From Sergey.Bylokhov at oracle.com Fri May 8 12:42:33 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 08 May 2015 15:42:33 +0300 Subject: [9] Review request for 8065739 [macosx] Frame warps to lower left of screen when displayed In-Reply-To: <554CABEF.7030502@oracle.com> References: <5525410A.8080407@oracle.com> <552EC29D.3090706@oracle.com> <554100C2.6050902@oracle.com> <554CABEF.7030502@oracle.com> Message-ID: <554CAF39.8040409@oracle.com> Hi, Alexander. Does the new tests cover all corner cases which we discussed offline? On 08.05.15 15:28, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8065739/webrev.03 > > - The -windowWillUseStandardFrame:defaultFrame: method is implemented > in AWTWindow to correctly get and check a size of the maximized window. > After that the -isZoomed method correctly defines the zoomed state > for both visible and not visible window. > > Thanks, > Alexandr. > > On 4/29/2015 7:03 PM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8065739/webrev.02 >> >> - the zoom state is applied after NSWindow creation if Frame has >> MAXIMIZED_BOTH state. >> >> Thanks, >> Alexandr. >> >> On 4/15/2015 10:57 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> As far as I understand the main issue is that we get a native >>> notifications during window initialization(after nswindows was >>> created and before zoom method will be called)? Probably we can >>> apply the zoom state when we create a window in one appkit call? >>> >>> On 08.04.15 17:54, Alexander Scherbatiy wrote: >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8065739 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8065739/webrev.00 >>>> >>>> Use case: >>>> ------------ >>>> Frame frame = new Frame(); >>>> frame.pack(); >>>> frame.setBounds(screenBounds); >>>> frame.setVisible(true); >>>> ------------ >>>> >>>> The frame is in the normal state but Mac OS X treats a frame with >>>> screen bounds as zoomed. >>>> The setVisible() method calls unmaximize() method to return the >>>> zoomed window to the normal state. >>>> The native zoom() method sets the initial sizes for the window >>>> which are zero because of the pack() call. >>>> >>>> >>>> There is already checkZoom() method which synchronizes native >>>> window zoom state and and the frame extended state when a frame is >>>> resized by mouse. >>>> However it can't be always used for the synchronization between >>>> native window zoom state and setBounds() call because of the >>>> following case: >>>> >>>> ----------------- >>>> Frame frame = new Frame(); >>>> frame.setBounds(smallBounds); >>>> frame.setExtendedState(Frame.MAXIMIZED_BOTH); >>>> frame.setVisible(true); >>>> ----------------- >>>> >>>> This is the valid scenario where the frame should be maximized. >>>> >>>> The solution synchronizes the zoom and the frame state only when >>>> the native window is zoomed. >>>> In opposite case we need to return from the zoomed sizes to >>>> previous sizes which are the same as for the zoomed window. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >>> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri May 8 12:45:04 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 08 May 2015 15:45:04 +0300 Subject: [9] Review request for 8003399: JFileChooser gives wrong path to selected file when saving to Libraries folder on Windows 7 In-Reply-To: <554B5AA1.1080206@oracle.com> References: <554B1EE4.1080001@oracle.com> <554B21C5.9020500@oracle.com> <554B5AA1.1080206@oracle.com> Message-ID: <554CAFD0.9030305@oracle.com> On 07.05.15 15:29, Semyon Sadetsky wrote: > Hi Sergey, > > Yes, after the fix filedialog produces usual filesystem paths for > libraries which are readable for java.io. Just to clarify: after the fix, both Open and Save dialog works? > But there are no possibility to reference files in libraries directly > using new File(). > > --Semyon > > On 5/7/2015 11:26 AM, Sergey Bylokhov wrote: >> Hi, Semyon. >> Can you please raise the supportness of this in the java.io on the >> core-libs alias. >> Does the open filedialog will work after the fix? >> >> On 07.05.15 11:14, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9. >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8003399 >>> >>> ***THE ROOT CAUSE >>> JDK uses legacy WINAPI special folders calls while MS introduced a >>> new interfaces IKnownFolder and IShellLibrary to manage special >>> folder locations and the new Libraries functionality in Windows 7 is >>> not backward compatible with old special folders CSIDL. >>> >>> ***SOLUTION >>> Since it is too expensive to migrate AWT shell to the new interfaces >>> and still they are not supported in java.io the solution is to map >>> virtual folder PIDL to the Known Folder GUID and replace libraries >>> links with the default library save location. Thus the File save >>> dialog will be able to work with any Libraries registered in the >>> system (Windows Libraries concept assumes that Libraries can be >>> added arbitrary). >>> The resulting code should be compatible with older Windows versions >>> because the new COM interfaces are called only if they are available >>> and a Libraries link has been actually requested. >>> >>> ***TESTING >>> A test scenario is added to check that all available Libraries links >>> are converted into filesystem paths. >>> >>> --Semyon >>> >> >> > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri May 8 13:44:05 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 08 May 2015 16:44:05 +0300 Subject: [9] Review request for 8079255 [macosx] Test closed/java/awt/Robot/RobotWheelTest/RobotWheelTest fails for Mac only In-Reply-To: <554B3E74.40207@oracle.com> References: <554B3416.1070800@oracle.com> <554B3E74.40207@oracle.com> Message-ID: <554CBDA5.50000@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8079255/webrev.01/ - the first date is added to the copyright - the frame is disposed Thanks, Alexandr. On 5/7/2015 1:29 PM, Sergey Bylokhov wrote: > Hi, Alexander. > Please dispose the frame at the end of the test. Also please update > the first date in the copyright. > It is interesting to think about a public api for mouse_wheel rotation > direction. > > On 07.05.15 12:44, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8079255 >> webrev: http://cr.openjdk.java.net/~alexsch/8079255/webrev.00 >> >> The test does not take into account that the >> MouseWheelEvent.getWheelRotation() has reversed value on Mac OS X. >> The test is updated and moved to the open repository. >> >> >> Thanks, >> Alexandr. >> > > From semyon.sadetsky at oracle.com Fri May 8 14:01:08 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 08 May 2015 17:01:08 +0300 Subject: [9] Review request for 8003399: JFileChooser gives wrong path to selected file when saving to Libraries folder on Windows 7 In-Reply-To: <554CAFD0.9030305@oracle.com> References: <554B1EE4.1080001@oracle.com> <554B21C5.9020500@oracle.com> <554B5AA1.1080206@oracle.com> <554CAFD0.9030305@oracle.com> Message-ID: <554CC1A4.90107@oracle.com> On 5/8/2015 3:45 PM, Sergey Bylokhov wrote: > On 07.05.15 15:29, Semyon Sadetsky wrote: >> Hi Sergey, >> >> Yes, after the fix filedialog produces usual filesystem paths for >> libraries which are readable for java.io. > Just to clarify: after the fix, both Open and Save dialog works? Open file in library was not a problem, because an exicting file has real FS path already. >> But there are no possibility to reference files in libraries directly >> using new File(). >> >> --Semyon >> >> On 5/7/2015 11:26 AM, Sergey Bylokhov wrote: >>> Hi, Semyon. >>> Can you please raise the supportness of this in the java.io on the >>> core-libs alias. >>> Does the open filedialog will work after the fix? >>> >>> On 07.05.15 11:14, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Please review fix for JDK9. >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8003399 >>>> >>>> ***THE ROOT CAUSE >>>> JDK uses legacy WINAPI special folders calls while MS introduced a >>>> new interfaces IKnownFolder and IShellLibrary to manage special >>>> folder locations and the new Libraries functionality in Windows 7 >>>> is not backward compatible with old special folders CSIDL. >>>> >>>> ***SOLUTION >>>> Since it is too expensive to migrate AWT shell to the new >>>> interfaces and still they are not supported in java.io the solution >>>> is to map virtual folder PIDL to the Known Folder GUID and replace >>>> libraries links with the default library save location. Thus the >>>> File save dialog will be able to work with any Libraries registered >>>> in the system (Windows Libraries concept assumes that Libraries can >>>> be added arbitrary). >>>> The resulting code should be compatible with older Windows versions >>>> because the new COM interfaces are called only if they are >>>> available and a Libraries link has been actually requested. >>>> >>>> ***TESTING >>>> A test scenario is added to check that all available Libraries >>>> links are converted into filesystem paths. >>>> >>>> --Semyon >>>> >>> >>> >> > > From anton.nashatyrev at oracle.com Fri May 8 16:08:45 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Fri, 08 May 2015 19:08:45 +0300 Subject: [9] Review request for 8078606: Deadlock in awt clipboard Message-ID: <554CDF8D.6010008@oracle.com> Hello, could you please review the following fix: fix: http://cr.openjdk.java.net/~anashaty/8078606/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8078606 Problem: XClipboard sometimes deadlocked Reason: XClipboard.registerClipboardViewerChecked acquires XCliboard lock first, then tries to acquire AWTLock (within the XWindow.getXAWTRootWindow() call) Fix: reverse the order of acquiring locks. Additionally eliminate AWTLock when accessing XRootWindow singleton. Thanks! Anton. From Sergey.Bylokhov at oracle.com Fri May 8 16:38:04 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 08 May 2015 19:38:04 +0300 Subject: [9] Review request for 8079255 [macosx] Test closed/java/awt/Robot/RobotWheelTest/RobotWheelTest fails for Mac only In-Reply-To: <554CBDA5.50000@oracle.com> References: <554B3416.1070800@oracle.com> <554B3E74.40207@oracle.com> <554CBDA5.50000@oracle.com> Message-ID: <554CE66C.60903@oracle.com> Hi, Alexander. Looks fine to me. On 08.05.15 16:44, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8079255/webrev.01/ > - the first date is added to the copyright > - the frame is disposed > > Thanks, > Alexandr. > > On 5/7/2015 1:29 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Please dispose the frame at the end of the test. Also please update >> the first date in the copyright. >> It is interesting to think about a public api for mouse_wheel >> rotation direction. >> >> On 07.05.15 12:44, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8079255 >>> webrev: http://cr.openjdk.java.net/~alexsch/8079255/webrev.00 >>> >>> The test does not take into account that the >>> MouseWheelEvent.getWheelRotation() has reversed value on Mac OS X. >>> The test is updated and moved to the open repository. >>> >>> >>> Thanks, >>> Alexandr. >>> >> >> > -- Best regards, Sergey. From anton.nashatyrev at oracle.com Fri May 8 16:52:13 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Fri, 08 May 2015 19:52:13 +0300 Subject: [9] Review request for 8068886: IDEA IntelliJ crashes in objc_msgSend when an accessibility tool is enabled Message-ID: <554CE9BD.9040001@oracle.com> Hello, could you please review the following fix: fix: http://cr.openjdk.java.net/~anashaty/8068886/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8068886 Problem: the native window pointer is disposed in the inner AppKit loop, while it is still referenced on the stack in the native Cocoa method which caused the mentioned inner loop. When the inner loop is exited Cocoa crashes while dereferencing this window pointer Fix: dispose resources in the main AppKit loop only. For this a 'dispose message' posted which is processed only on the main loop. Thanks! Anton. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri May 8 19:25:19 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 08 May 2015 22:25:19 +0300 Subject: [9] Review Request: 6587235 Incorrect javadoc: "no parameter" in 2d source code Message-ID: <554D0D9F.9010207@oracle.com> Hello. Please review the fix for a typos in jdk9. This CR was filed by me long time ago and I doubt that someone will take a look at it. I fixed all clients files in sun.** subpackages. Bug: https://bugs.openjdk.java.net/browse/JDK-6587235 Webrev can be found at: http://cr.openjdk.java.net/~serb/6587235/webrev.00 -- Best regards, Sergey. From peter.brunet at oracle.com Fri May 8 19:52:07 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 08 May 2015 14:52:07 -0500 Subject: RfR JDK-8078408, Java version applet hangs with Voice over turned on In-Reply-To: <554D0A4C.5080700@oracle.com> References: <554D0A4C.5080700@oracle.com> Message-ID: <554D13E7.2030606@oracle.com> Resending to correct list... On 5/8/15 2:11 PM, Pete Brunet wrote: > Please review the fix for JDK-8078408 "Java version applet hangs with > Voice over turned on". > > The failure is an NPE. There is a variable that is OK to be null at the > point of failure and the fix adds a check for it being null. > > http://cr.openjdk.java.net/~ptbrunet/JDK-8078408/webrev.00/ > > Thanks, Pete From philip.race at oracle.com Fri May 8 19:52:11 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 08 May 2015 12:52:11 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 6587235 Incorrect javadoc: "no parameter" in 2d source code In-Reply-To: <554D0D9F.9010207@oracle.com> References: <554D0D9F.9010207@oracle.com> Message-ID: <554D13EB.1070504@oracle.com> 273 * RuntimePermission("accessClassInPackage."+pkg) 274 * permission. 275 * 276 * @param pkgname the package name. perhaps line 273 should match ? 7 * @param srcArg The first source tile for the compositing operation. 88 * @param dstIn The second source tile for the compositing operation. 89 * @param dstOut The tile where the result of the operation is stored. 90 */ 91 public void compose(Raster srcArg, Raster dstIn, WritableRaster dstOut) { it might be better to rename the actual arguments to match the doc. 47 /** 48 * Construct a new dialog type selection enumeration value with the 49 * given integer value. 50 * 51 * @param frame Integer value. 52 */ 53 public DialogOwner(Frame frame) { Huh ? The entire doc seems to be nonsense .. changing the name of the param just makes it worse. The text seems to have been copied from javax.attribute.standard.DialogTypeSelection.java -phil. On 05/08/2015 12:25 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for a typos in jdk9. This CR was filed by me > long time ago and I doubt that someone will take a look at it. > I fixed all clients files in sun.** subpackages. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6587235 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/6587235/webrev.00 > From Sergey.Bylokhov at oracle.com Fri May 8 22:34:01 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 09 May 2015 01:34:01 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 6587235 Incorrect javadoc: "no parameter" in 2d source code In-Reply-To: <554D13EB.1070504@oracle.com> References: <554D0D9F.9010207@oracle.com> <554D13EB.1070504@oracle.com> Message-ID: <554D39D9.4040301@oracle.com> Hi, Phil. Thanks for a review! The new version: http://cr.openjdk.java.net/~serb/6587235/webrev.01 On 08.05.15 22:52, Phil Race wrote: > 273 * RuntimePermission("accessClassInPackage."+pkg) > 274 * permission. > 275 * > 276 * @param pkgname the package name. > > > perhaps line 273 should match ? > > 7 * @param srcArg The first source tile for the compositing > operation. > 88 * @param dstIn The second source tile for the compositing > operation. > 89 * @param dstOut The tile where the result of the operation > is stored. > 90 */ > 91 public void compose(Raster srcArg, Raster dstIn, > WritableRaster dstOut) { > > it might be better to rename the actual arguments to match the doc. > > > 47 /** > 48 * Construct a new dialog type selection enumeration value > with the > 49 * given integer value. > 50 * > 51 * @param frame Integer value. > 52 */ > 53 public DialogOwner(Frame frame) { > > Huh ? The entire doc seems to be nonsense .. changing the name of the > param > just makes it worse. The text seems to have been copied from > javax.attribute.standard.DialogTypeSelection.java > > > -phil. > > On 05/08/2015 12:25 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for a typos in jdk9. This CR was filed by me >> long time ago and I doubt that someone will take a look at it. >> I fixed all clients files in sun.** subpackages. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6587235 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/6587235/webrev.00 >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat May 9 00:41:10 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 09 May 2015 03:41:10 +0300 Subject: [9] Review Request: 8071306 GUI perfomance are very slow compared java 1.6.0_45 In-Reply-To: <554C8093.50205@oracle.com> References: <554AB431.1040707@oracle.com> <554C8093.50205@oracle.com> Message-ID: <554D57A6.40202@oracle.com> Hi, Anton. On 08.05.15 12:23, Anton V. Tarasov wrote: > > 1314 /** > 1315 * Determines the bounds which will be displayed on the screen. > 1316 * > 1317 * @return the visible part of bounds in the coordinate space > of this comp > 1318 */ > 1319 private Rectangle getRecursivelyVisibleBounds() { > > Could you please clarify the comment, it's not quite clear from the > first glance. Something like: > > "the bounds of a visible part of the component relative to..." The patch updated: http://cr.openjdk.java.net/~serb/8071306/webrev.04 > > 2. > > 100 * The components in this container. > 101 * @see #add > 102 * @see #getComponents > 103 */ > 104 private java.util.List component = new ArrayList<>(); > > May be it's worth to rename the field? The "component" name is odd... I suppose it wasn't changed, because this name is used in the serialization for a long time. Plus there are a bunch of the similar vars like: tmpComponent etc. I can do it later for jdk9 only. > > Regards, > Anton. > > On 07.05.2015 3:39, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for a jdk9. I plan to backport it to jdk8u60. >> >> Description. >> An UIworks really slowly, when an application has a lot of components >> in one container, and these components should be disabled one by one. >> The reason is the next sequence of methods calls: >> Component.setEnabled->updateCursorImmediately()-> some cursor related >> staff->GlobalCursorManager._updateCursor->Container.findComponentAt()-iteration >> over all components in the container.....-> twice.... >> >> You can imagine how it works in case of 10000 components in the >> container. >> >> Note that in the bug report described difference jdk6 vs jdk8 -> 1sec >> vs 6 sec. This was caused by the two fixes, one of which adds >> checkTreeLock() and in another one a simple array of components was >> replaced by the ArrayList. Since code was added to the really hot >> method we got so big slowdown. >> >> To fix the problem I suggest two different approaches: >> - Container.java: Fix a general case, by eliminating a second >> iteration in the hot loop. >> - Component.java: Totally eliminates cursor machinery, if component >> cannot affect current cursor. >> >> Some speedup measurements on my local system: >> - Simple removing of checkTreeLock() will partly solve a regression >> reported by the user(12 sec -> 5 sec). >> - Changes in the loop will speedup the code in the worse case(5->2 sec) >> - The changes in the Component.java will change the performance from >> 2 sec to 100< ms >> >> Test case which was added was improved from 10 seconds to 80 ms. >> >> JMH test: >> http://cr.openjdk.java.net/~serb/8071306/SetEnabledPerformanceTest.java >> >> Fixedversion: >> >> Benchmark Mode Cnt >> Score Error Units >> SetEnabledPerformanceTest.testContains thrpt 5 301300,813 >> ? 17338,045 ops/ms >> SetEnabledPerformanceTest.testFindComponentAt thrpt 5 20,521 >> ? 0,269 ops/ms >> SetEnabledPerformanceTest.testGetComponentAt thrpt 5 22,297 >> ? 1,264 ops/ms >> SetEnabledPerformanceTest.testSetEnabled thrpt 5 711,120 >> ? 19,837 ops/ms >> >> Base version: >> >> Benchmark Mode Cnt >> Score Error Units >> SetEnabledPerformanceTest.testContains thrpt 5 299145,642 >> ? 2120,183 ops/ms >> SetEnabledPerformanceTest.testFindComponentAt thrpt 5 1,101 >> ? 0,012 ops/ms >> SetEnabledPerformanceTest.testGetComponentAt thrpt 5 6,792 >> ? 0,097 ops/ms >> SetEnabledPerformanceTest.testSetEnabled thrpt 5 0,464 >> ? 0,020 ops/ms >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8071306 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8071306/webrev.03 >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sat May 9 01:24:29 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 08 May 2015 18:24:29 -0700 Subject: [OpenJDK 2D-Dev] [9] Review Request: 6587235 Incorrect javadoc: "no parameter" in 2d source code In-Reply-To: <554D39D9.4040301@oracle.com> References: <554D0D9F.9010207@oracle.com> <554D13EB.1070504@oracle.com> <554D39D9.4040301@oracle.com> Message-ID: <554D61CD.8000901@oracle.com> I did not slog through all the webrev again but the changed parts look good, so "+1". -phil. On 5/8/15 3:34 PM, Sergey Bylokhov wrote: > Hi, Phil. > Thanks for a review! The new version: > http://cr.openjdk.java.net/~serb/6587235/webrev.01 > > On 08.05.15 22:52, Phil Race wrote: >> 273 * RuntimePermission("accessClassInPackage."+pkg) >> 274 * permission. >> 275 * >> 276 * @param pkgname the package name. >> >> >> perhaps line 273 should match ? >> >> 7 * @param srcArg The first source tile for the compositing >> operation. >> 88 * @param dstIn The second source tile for the compositing >> operation. >> 89 * @param dstOut The tile where the result of the operation >> is stored. >> 90 */ >> 91 public void compose(Raster srcArg, Raster dstIn, >> WritableRaster dstOut) { >> >> it might be better to rename the actual arguments to match the doc. >> >> >> 47 /** >> 48 * Construct a new dialog type selection enumeration value >> with the >> 49 * given integer value. >> 50 * >> 51 * @param frame Integer value. >> 52 */ >> 53 public DialogOwner(Frame frame) { >> >> Huh ? The entire doc seems to be nonsense .. changing the name of the >> param >> just makes it worse. The text seems to have been copied from >> javax.attribute.standard.DialogTypeSelection.java >> >> >> -phil. >> >> On 05/08/2015 12:25 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for a typos in jdk9. This CR was filed by me >>> long time ago and I doubt that someone will take a look at it. >>> I fixed all clients files in sun.** subpackages. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6587235 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/6587235/webrev.00 >>> >> > > From anton.tarasov at oracle.com Tue May 12 11:51:24 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 12 May 2015 14:51:24 +0300 Subject: [9] Review Request: 8071306 GUI perfomance are very slow compared java 1.6.0_45 In-Reply-To: <554D57A6.40202@oracle.com> References: <554AB431.1040707@oracle.com> <554C8093.50205@oracle.com> <554D57A6.40202@oracle.com> Message-ID: <5551E93C.2010807@oracle.com> Hi Sergey, On 09.05.2015 3:41, Sergey Bylokhov wrote: > Hi, Anton. > On 08.05.15 12:23, Anton V. Tarasov wrote: >> >> 1314 /** >> 1315 * Determines the bounds which will be displayed on the screen. >> 1316 * >> 1317 * @return the visible part of bounds in the coordinate space of this comp >> 1318 */ >> 1319 private Rectangle getRecursivelyVisibleBounds() { >> >> Could you please clarify the comment, it's not quite clear from the first glance. Something like: >> >> "the bounds of a visible part of the component relative to..." > The patch updated: > http://cr.openjdk.java.net/~serb/8071306/webrev.04 + * Determines the bounds of a visible part of the component relative to its + * parents. Did you mean "to its parent"? (If so, I don't mind fixing it in a commit changeset only). >> >> 2. >> >> 100 * The components in this container. >> 101 * @see #add >> 102 * @see #getComponents >> 103 */ >> 104 private java.util.List component = new ArrayList<>(); >> >> May be it's worth to rename the field? The "component" name is odd... > I suppose it wasn't changed, because this name is used in the serialization for a long time. Plus > there are a bunch of the similar vars like: tmpComponent etc. I can do it later for jdk9 only. Ok, thanks. It's up to you. Regards, Anton. >> >> Regards, >> Anton. >> >> On 07.05.2015 3:39, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for a jdk9. I plan to backport it to jdk8u60. >>> >>> Description. >>> An UIworks really slowly, when an application has a lot of components in one container, and >>> these components should be disabled one by one. >>> The reason is the next sequence of methods calls: >>> Component.setEnabled->updateCursorImmediately()-> some cursor related >>> staff->GlobalCursorManager._updateCursor->Container.findComponentAt()-iteration over all >>> components in the container.....-> twice.... >>> >>> You can imagine how it works in case of 10000 components in the container. >>> >>> Note that in the bug report described difference jdk6 vs jdk8 -> 1sec vs 6 sec. This was caused >>> by the two fixes, one of which adds checkTreeLock() and in another one a simple array of >>> components was replaced by the ArrayList. Since code was added to the really hot method we got >>> so big slowdown. >>> >>> To fix the problem I suggest two different approaches: >>> - Container.java: Fix a general case, by eliminating a second iteration in the hot loop. >>> - Component.java: Totally eliminates cursor machinery, if component cannot affect current cursor. >>> >>> Some speedup measurements on my local system: >>> - Simple removing of checkTreeLock() will partly solve a regression reported by the user(12 sec >>> -> 5 sec). >>> - Changes in the loop will speedup the code in the worse case(5->2 sec) >>> - The changes in the Component.java will change the performance from 2 sec to 100< ms >>> >>> Test case which was added was improved from 10 seconds to 80 ms. >>> >>> JMH test: http://cr.openjdk.java.net/~serb/8071306/SetEnabledPerformanceTest.java >>> >>> Fixedversion: >>> >>> Benchmark Mode Cnt Score Error Units >>> SetEnabledPerformanceTest.testContains thrpt 5 301300,813 ? 17338,045 ops/ms >>> SetEnabledPerformanceTest.testFindComponentAt thrpt 5 20,521 ? 0,269 ops/ms >>> SetEnabledPerformanceTest.testGetComponentAt thrpt 5 22,297 ? 1,264 ops/ms >>> SetEnabledPerformanceTest.testSetEnabled thrpt 5 711,120 ? 19,837 ops/ms >>> >>> Base version: >>> >>> Benchmark Mode Cnt Score Error Units >>> SetEnabledPerformanceTest.testContains thrpt 5 299145,642 ? 2120,183 ops/ms >>> SetEnabledPerformanceTest.testFindComponentAt thrpt 5 1,101 ? 0,012 ops/ms >>> SetEnabledPerformanceTest.testGetComponentAt thrpt 5 6,792 ? 0,097 ops/ms >>> SetEnabledPerformanceTest.testSetEnabled thrpt 5 0,464 ? 0,020 ops/ms >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071306 >>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8071306/webrev.03 >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue May 12 13:44:28 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 12 May 2015 16:44:28 +0300 Subject: [9] Review request for 8065739 [macosx] Frame warps to lower left of screen when displayed In-Reply-To: <554CAF39.8040409@oracle.com> References: <5525410A.8080407@oracle.com> <552EC29D.3090706@oracle.com> <554100C2.6050902@oracle.com> <554CABEF.7030502@oracle.com> <554CAF39.8040409@oracle.com> Message-ID: <555203BC.2090604@oracle.com> Could you review the updated fix: - maximized bounds are updated after switching to new screen if they are not set by a user - the test for the maximized window moved from one screen to another is added Thanks, Alexandr. On 5/8/2015 3:42 PM, Sergey Bylokhov wrote: > Hi, Alexander. > Does the new tests cover all corner cases which we discussed offline? > > On 08.05.15 15:28, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8065739/webrev.03 >> >> - The -windowWillUseStandardFrame:defaultFrame: method is >> implemented in AWTWindow to correctly get and check a size of the >> maximized window. >> After that the -isZoomed method correctly defines the zoomed state >> for both visible and not visible window. >> >> Thanks, >> Alexandr. >> >> On 4/29/2015 7:03 PM, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.02 >>> >>> - the zoom state is applied after NSWindow creation if Frame has >>> MAXIMIZED_BOTH state. >>> >>> Thanks, >>> Alexandr. >>> >>> On 4/15/2015 10:57 PM, Sergey Bylokhov wrote: >>>> Hi, Alexander. >>>> As far as I understand the main issue is that we get a native >>>> notifications during window initialization(after nswindows was >>>> created and before zoom method will be called)? Probably we can >>>> apply the zoom state when we create a window in one appkit call? >>>> >>>> On 08.04.15 17:54, Alexander Scherbatiy wrote: >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8065739 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8065739/webrev.00 >>>>> >>>>> Use case: >>>>> ------------ >>>>> Frame frame = new Frame(); >>>>> frame.pack(); >>>>> frame.setBounds(screenBounds); >>>>> frame.setVisible(true); >>>>> ------------ >>>>> >>>>> The frame is in the normal state but Mac OS X treats a frame >>>>> with screen bounds as zoomed. >>>>> The setVisible() method calls unmaximize() method to return the >>>>> zoomed window to the normal state. >>>>> The native zoom() method sets the initial sizes for the window >>>>> which are zero because of the pack() call. >>>>> >>>>> >>>>> There is already checkZoom() method which synchronizes native >>>>> window zoom state and and the frame extended state when a frame is >>>>> resized by mouse. >>>>> However it can't be always used for the synchronization between >>>>> native window zoom state and setBounds() call because of the >>>>> following case: >>>>> >>>>> ----------------- >>>>> Frame frame = new Frame(); >>>>> frame.setBounds(smallBounds); >>>>> frame.setExtendedState(Frame.MAXIMIZED_BOTH); >>>>> frame.setVisible(true); >>>>> ----------------- >>>>> >>>>> This is the valid scenario where the frame should be maximized. >>>>> >>>>> The solution synchronizes the zoom and the frame state only when >>>>> the native window is zoomed. >>>>> In opposite case we need to return from the zoomed sizes to >>>>> previous sizes which are the same as for the zoomed window. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>>> >>> >> > > From philip.race at oracle.com Tue May 12 18:22:39 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 May 2015 11:22:39 -0700 Subject: RfR JDK-8078408, Java version applet hangs with Voice over turned on In-Reply-To: <554D13E7.2030606@oracle.com> References: <554D0A4C.5080700@oracle.com> <554D13E7.2030606@oracle.com> Message-ID: <555244EF.80301@oracle.com> +1 -Phil. On 5/8/15 12:52 PM, Pete Brunet wrote: > Resending to correct list... > > On 5/8/15 2:11 PM, Pete Brunet wrote: >> Please review the fix for JDK-8078408 "Java version applet hangs with >> Voice over turned on". >> >> The failure is an NPE. There is a variable that is OK to be null at the >> point of failure and the fix adds a check for it being null. >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8078408/webrev.00/ >> >> Thanks, Pete From Sergey.Bylokhov at oracle.com Tue May 12 18:25:16 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 12 May 2015 21:25:16 +0300 Subject: RfR JDK-8078408, Java version applet hangs with Voice over turned on In-Reply-To: <554D13E7.2030606@oracle.com> References: <554D0A4C.5080700@oracle.com> <554D13E7.2030606@oracle.com> Message-ID: <5552458C.9030703@oracle.com> Hi, Pete. The fix looks fine. On 08.05.15 22:52, Pete Brunet wrote: > Resending to correct list... > > On 5/8/15 2:11 PM, Pete Brunet wrote: >> Please review the fix for JDK-8078408 "Java version applet hangs with >> Voice over turned on". >> >> The failure is an NPE. There is a variable that is OK to be null at the >> point of failure and the fix adds a check for it being null. >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8078408/webrev.00/ >> >> Thanks, Pete -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue May 12 18:32:29 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 12 May 2015 21:32:29 +0300 Subject: [9] Review request for 8068886: IDEA IntelliJ crashes in objc_msgSend when an accessibility tool is enabled In-Reply-To: <554CE9BD.9040001@oracle.com> References: <554CE9BD.9040001@oracle.com> Message-ID: <5552473D.4040902@oracle.com> Hi, Anton. The fix looks fine, but I suggest to document the new resources deallocation policy. I suppose documentation of loops, CFRetainedResource, etc should be updated. Also please confirm that all our code follow this rule. On 08.05.15 19:52, Anton Nashatyrev wrote: > Hello, > could you please review the following fix: > > fix: http://cr.openjdk.java.net/~anashaty/8068886/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8068886 > > Problem: the native window pointer is disposed in the inner AppKit > loop, while it is still referenced on the stack in the native Cocoa > method which caused the mentioned inner loop. When the inner loop is > exited Cocoa crashes while dereferencing this window pointer > > Fix: dispose resources in the main AppKit loop only. For this a > 'dispose message' posted which is processed only on the main loop. > > Thanks! > Anton. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.kulyakhtin at oracle.com Wed May 13 14:52:20 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 13 May 2015 07:52:20 -0700 (PDT) Subject: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository Message-ID: <1b2aa136-3d8b-4c3c-ab80-405346898578@default> Hi, Could you please, review the following tests-only changes to the hs-rt/jdk and hs-rt/test repositories. These changes are a part of the changes for "JDK-8075327: Merge jdk and hotspot test libraries" The changes are as follows: http://cr.openjdk.java.net/~akulyakh/8075327/jdk_patch/webrev/ http://cr.openjdk.java.net/~akulyakh/8075327/test_patch/webrev/ 1) Renaming jdk.testlibrary package to jdk.test.lib in the hs-rt/jdk repo, so it has the same name as the jdk.test.lib package in the hotspot repo. 2) Several files from the jdk/testlibrary have duplicates in the hotspot/testlibrary. We are moving those files from jdk/testlibrary to the upper-level hs-rt/test so they can be shared by jdk and hotspot (also updating @library directives to reflect that). If these proposed changes are acceptable then we'll merge the duplicates between the hs-rt/hotspot and hs-rt/test/lib files into hs-rt/test/lib and prepare a full review. Thank you very much for the review. Best regards, Alexander From chris.hegarty at oracle.com Wed May 13 15:17:32 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 May 2015 16:17:32 +0100 Subject: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository In-Reply-To: <1b2aa136-3d8b-4c3c-ab80-405346898578@default> References: <1b2aa136-3d8b-4c3c-ab80-405346898578@default> Message-ID: <55536B0C.1070604@oracle.com> Hi Alexander, On 13/05/15 15:52, Alexander Kulyakhtin wrote: > Hi, > > Could you please, review the following tests-only changes to the hs-rt/jdk and hs-rt/test repositories. These changes are a part of the changes for "JDK-8075327: Merge jdk and hotspot test libraries" I suspect that these changes are best going directly into jdk9/dev, as opposed to a a downstream forest. > The changes are as follows: > > http://cr.openjdk.java.net/~akulyakh/8075327/jdk_patch/webrev/ In may places '@library /lib/testlibrary ...' remains. Is this redundant, in many tests? If so, it be removed. > http://cr.openjdk.java.net/~akulyakh/8075327/test_patch/webrev/ > > 1) Renaming jdk.testlibrary package to jdk.test.lib in the hs-rt/jdk repo, so it has the same name as the jdk.test.lib package in the hotspot repo. > > 2) Several files from the jdk/testlibrary have duplicates in the hotspot/testlibrary. We are moving those files from jdk/testlibrary to the upper-level hs-rt/test The changes are to the 'test' directory in the "top" repo? You are not proposing to add a new repo, right? test/lib/testlibrary/jdk/testlibrary/RandomFactory.java was updated recently in jdk9/dev. The version in your webrev is a little out of date. Is there any special update needed to jtreg to support this? > so they can be shared by jdk and hotspot (also updating @library directives to reflect that). > > If these proposed changes are acceptable then we'll merge the duplicates between the hs-rt/hotspot and hs-rt/test/lib files into hs-rt/test/lib and prepare a full review. > > Thank you very much for the review. > > Best regards, > Alexander -Chris. From alexander.kulyakhtin at oracle.com Wed May 13 15:46:04 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 13 May 2015 08:46:04 -0700 (PDT) Subject: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository Message-ID: <5e28a49a-4ff3-43b4-8e02-7bfe73f0bfd6@default> Hi Chris, > I suspect that these changes are best going directly into jdk9/dev, as > opposed to a a downstream forest. Yes, they are going directly to jdk9/dev, I forgot to add the group, adding now. > In may places '@library /lib/testlibrary ...' remains. Is this > redundant, in many tests? If so, it be removed. No, this is mostly not redundant, as the jdk/testlibrary comntains many files specific for jdk only. Only a relatively small number of files are duplicated between hotspot and jdk. >The changes are to the 'test' directory in the "top" repo? You are not >proposing to add a new repo, right? No, we are not proposing a new repo. The changes are in the 'top' repo. >test/lib/testlibrary/jdk/testlibrary/RandomFactory.java was updated >recently in jdk9/dev. The version in your webrev is a little out of date. We are going to upmerge the changes then >Is there any special update needed to jtreg to support this? For thse changes no jtreg update is required. However, there are plans for the jtreg to prohibit referencing any @libraries above the repo root unless such libraries are directly specified in TEST.properties If jtreg thus prohibits our using /../../test/lib (because it's above the root) we will have to additionally make a change to jdk and hotspot TEST.properties Best regards, Alexander From alexander.kulyakhtin at oracle.com Wed May 13 15:48:48 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 13 May 2015 08:48:48 -0700 (PDT) Subject: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository Message-ID: <15629659-f6ca-4ad4-8458-9174f8ce473f@default> Adding jdk9-dev mailing list ----- Original Message ----- From: alexander.kulyakhtin at oracle.com To: core-libs-dev at openjdk.java.net, awt-dev at openjdk.java.net, hotspot-dev at openjdk.java.net Cc: stefan.sarne at oracle.com, yekaterina.kantserova at oracle.com, alan.bateman at oracle.com Sent: Wednesday, May 13, 2015 5:52:20 PM GMT +03:00 Iraq Subject: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository Hi, Could you please, review the following tests-only changes to the hs-rt/jdk and hs-rt/test repositories. These changes are a part of the changes for "JDK-8075327: Merge jdk and hotspot test libraries" The changes are as follows: http://cr.openjdk.java.net/~akulyakh/8075327/jdk_patch/webrev/ http://cr.openjdk.java.net/~akulyakh/8075327/test_patch/webrev/ 1) Renaming jdk.testlibrary package to jdk.test.lib in the hs-rt/jdk repo, so it has the same name as the jdk.test.lib package in the hotspot repo. 2) Several files from the jdk/testlibrary have duplicates in the hotspot/testlibrary. We are moving those files from jdk/testlibrary to the upper-level hs-rt/test so they can be shared by jdk and hotspot (also updating @library directives to reflect that). If these proposed changes are acceptable then we'll merge the duplicates between the hs-rt/hotspot and hs-rt/test/lib files into hs-rt/test/lib and prepare a full review. Thank you very much for the review. Best regards, Alexander From chris.hegarty at oracle.com Wed May 13 16:48:02 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 May 2015 17:48:02 +0100 Subject: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository In-Reply-To: <5e28a49a-4ff3-43b4-8e02-7bfe73f0bfd6@default> References: <5e28a49a-4ff3-43b4-8e02-7bfe73f0bfd6@default> Message-ID: <34348D14-9BBC-40E6-A1DB-923D88AFCD90@oracle.com> Alexander, > On 13 May 2015, at 16:46, Alexander Kulyakhtin wrote: > > Hi Chris, > > >> I suspect that these changes are best going directly into jdk9/dev, as >> opposed to a a downstream forest. > Yes, they are going directly to jdk9/dev, I forgot to add the group, adding now. > >> In may places '@library /lib/testlibrary ...' remains. Is this >> redundant, in many tests? If so, it be removed. > No, this is mostly not redundant, as the jdk/testlibrary comntains many files specific for jdk only. Only a relatively small number of files are duplicated between hotspot and jdk. Right, but mostly is not all. For example test/com/sun/net/httpserver/Test1.java should no longer include @library /lib/testlibrary. It depends only on SimpleSSLContext which is being moved. It is easy to see this by looking at the imports. Whatever script you have for updating these tests should also remove redundant values in the @library tag. I suspect there are a significant number of these ( a lot of tests just use one library class ). Just on that, is it for a library class to indicate that it depends on a class from another library? I believe this is the case for some library utilities. How can a test know this. It needs to be a library class that indicates this dependency.I see nothing in the webrev for this ( or maybe I missed it ). -Chris. > >> The changes are to the 'test' directory in the "top" repo? You are not >> proposing to add a new repo, right? > No, we are not proposing a new repo. The changes are in the 'top' repo. > >> test/lib/testlibrary/jdk/testlibrary/RandomFactory.java was updated >> recently in jdk9/dev. The version in your webrev is a little out of date. > We are going to upmerge the changes then > >> Is there any special update needed to jtreg to support this? > For thse changes no jtreg update is required. > However, there are plans for the jtreg to prohibit referencing any @libraries above the repo root unless such libraries are directly specified in TEST.properties > If jtreg thus prohibits our using /../../test/lib (because it's above the root) we will have to additionally make a change to jdk and hotspot TEST.properties > > Best regards, > Alexander From alexander.kulyakhtin at oracle.com Wed May 13 17:08:29 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 13 May 2015 10:08:29 -0700 (PDT) Subject: Changes for JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository Message-ID: Chris, Following the feedback from Jon Gibbons, we have changed our current plan to the following: 1) We are waiting till the new jtreg is promoted. The new jtreg allows for specifying in the repository's TEST.properties file one or more paths to search for libraries 2) After the jtreg is out we are adding both path to jdk/testlibrary and path to toplevel/test/lib/share library to the jdk and hotspot TEST.properties files Under those testlibrary roots we are rearranging the directories to have the same jdk/test/lib structure (to provide for the jdk.test.lib package) 3) Same as with the current changes we are changing import package jdk.testlib.* to import package jdk.test.lib.* in the jdk and hotspot tests. This way, if the jtreg does not find a required class from the jdk.test.lib in the jdk/testlibrary it will look for it in the toplevel/test/lib/share test library. The same will be done for the hotspot tests. Best regards, Alexander ----- Original Message ----- From: chris.hegarty at oracle.com To: alexander.kulyakhtin at oracle.com Cc: core-libs-dev at openjdk.java.net, awt-dev at openjdk.java.net, stefan.sarne at oracle.com, yekaterina.kantserova at oracle.com, hotspot-dev at openjdk.java.net, jdk9-dev at openjdk.java.net Sent: Wednesday, May 13, 2015 7:48:06 PM GMT +03:00 Iraq Subject: Re: Changes fro JDK-8075327: moving jdk testlibraty files duplicated in hotspot to the common test repository Alexander, > On 13 May 2015, at 16:46, Alexander Kulyakhtin wrote: > > Hi Chris, > > >> I suspect that these changes are best going directly into jdk9/dev, as >> opposed to a a downstream forest. > Yes, they are going directly to jdk9/dev, I forgot to add the group, adding now. > >> In may places '@library /lib/testlibrary ...' remains. Is this >> redundant, in many tests? If so, it be removed. > No, this is mostly not redundant, as the jdk/testlibrary comntains many files specific for jdk only. Only a relatively small number of files are duplicated between hotspot and jdk. Right, but mostly is not all. For example test/com/sun/net/httpserver/Test1.java should no longer include @library /lib/testlibrary. It depends only on SimpleSSLContext which is being moved. It is easy to see this by looking at the imports. Whatever script you have for updating these tests should also remove redundant values in the @library tag. I suspect there are a significant number of these ( a lot of tests just use one library class ). Just on that, is it for a library class to indicate that it depends on a class from another library? I believe this is the case for some library utilities. How can a test know this. It needs to be a library class that indicates this dependency.I see nothing in the webrev for this ( or maybe I missed it ). -Chris. > >> The changes are to the 'test' directory in the "top" repo? You are not >> proposing to add a new repo, right? > No, we are not proposing a new repo. The changes are in the 'top' repo. > >> test/lib/testlibrary/jdk/testlibrary/RandomFactory.java was updated >> recently in jdk9/dev. The version in your webrev is a little out of date. > We are going to upmerge the changes then > >> Is there any special update needed to jtreg to support this? > For thse changes no jtreg update is required. > However, there are plans for the jtreg to prohibit referencing any @libraries above the repo root unless such libraries are directly specified in TEST.properties > If jtreg thus prohibits our using /../../test/lib (because it's above the root) we will have to additionally make a change to jdk and hotspot TEST.properties > > Best regards, > Alexander From javalists at cbfiddle.com Wed May 13 17:40:17 2015 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 13 May 2015 10:40:17 -0700 Subject: internal API usage: sun.awt.CausedFocusEvent Message-ID: <85B3FFA2-8F80-4397-9189-DF2927FA2C4E@cbfiddle.com> I have been using sun.awt.CausedFocusEvent to implement special behavior in response to an explicit user-initiated focus traversal to a component. The main point is that I want to inhibit this behavior for all other kinds of focus gained events. Will there be some way of doing this in JDK9? From philip.race at oracle.com Wed May 13 20:45:51 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 13 May 2015 13:45:51 -0700 Subject: RFR: 8080317: Disable warning treated as error for signed/unsigned comparison in building splashscreen Message-ID: <5553B7FF.8030103@oracle.com> Warnings are now treated as errors by default. I need a quick review on this from anyone who is available so I can fix our build for integration... -phil. https://bugs.openjdk.java.net/browse/JDK-8080317 $ hg diff make/lib/Awt2dLibraries.gmk diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk +++ b/make/lib/Awt2dLibraries.gmk @@ -885,10 +885,10 @@ OPTIMIZATION := LOW, \ CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) $(CFLAGS_JDKLIB) \ $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS), \ - DISABLED_WARNINGS_gcc := type-limits unused-result maybe-uninitialized, \ + DISABLED_WARNINGS_gcc := sign-compare type-limits unused-result maybe-uninitialized, \ DISABLED_WARNINGS_clang := incompatible-pointer-types, \ DISABLED_WARNINGS_solstudio := E_NEWLINE_NOT_LAST E_DECLARATION_IN_CODE, \ - DISABLED_WARNINGS_microsoft := 4244 4267, \ + DISABLED_WARNINGS_microsoft := 4018 4244 4267, \ MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsplashscreen/mapfile-vers, \ LDFLAGS := $(LDFLAGS_JDKLIB) \ $(call SET_SHARED_LIBRARY_ORIGIN), \ From david.dehaven at oracle.com Wed May 13 20:51:35 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 13 May 2015 13:51:35 -0700 Subject: RFR: 8080317: Disable warning treated as error for signed/unsigned comparison in building splashscreen In-Reply-To: <5553B7FF.8030103@oracle.com> References: <5553B7FF.8030103@oracle.com> Message-ID: <377F5495-4341-4A32-80BE-BB2AB276F0CB@oracle.com> Adding Magnus -DrD- > On May 13, 2015, at 1:45 PM, Phil Race wrote: > > Warnings are now treated as errors by default. > I need a quick review on this from anyone who is available so I can fix our build for integration... > > -phil. > > https://bugs.openjdk.java.net/browse/JDK-8080317 > > $ hg diff make/lib/Awt2dLibraries.gmk > diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk > +++ b/make/lib/Awt2dLibraries.gmk > @@ -885,10 +885,10 @@ > OPTIMIZATION := LOW, \ > CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) $(CFLAGS_JDKLIB) \ > $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS), \ > - DISABLED_WARNINGS_gcc := type-limits unused-result maybe-uninitialized, \ > + DISABLED_WARNINGS_gcc := sign-compare type-limits unused-result maybe-uninitialized, \ > DISABLED_WARNINGS_clang := incompatible-pointer-types, \ > DISABLED_WARNINGS_solstudio := E_NEWLINE_NOT_LAST E_DECLARATION_IN_CODE, \ > - DISABLED_WARNINGS_microsoft := 4244 4267, \ > + DISABLED_WARNINGS_microsoft := 4018 4244 4267, \ > MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsplashscreen/mapfile-vers, \ > LDFLAGS := $(LDFLAGS_JDKLIB) \ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > From david.dehaven at oracle.com Wed May 13 20:57:23 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 13 May 2015 13:57:23 -0700 Subject: RFR: 8080317: Disable warning treated as error for signed/unsigned comparison in building splashscreen In-Reply-To: <5553B7FF.8030103@oracle.com> References: <5553B7FF.8030103@oracle.com> Message-ID: <4EC0FD54-F7CD-451D-B3BA-6C5357136B37@oracle.com> The changes look ok to me. -DrD- > On May 13, 2015, at 1:45 PM, Phil Race wrote: > > Warnings are now treated as errors by default. > I need a quick review on this from anyone who is available so I can fix our build for integration... > > -phil. > > https://bugs.openjdk.java.net/browse/JDK-8080317 > > $ hg diff make/lib/Awt2dLibraries.gmk > diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk > +++ b/make/lib/Awt2dLibraries.gmk > @@ -885,10 +885,10 @@ > OPTIMIZATION := LOW, \ > CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) $(CFLAGS_JDKLIB) \ > $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS), \ > - DISABLED_WARNINGS_gcc := type-limits unused-result maybe-uninitialized, \ > + DISABLED_WARNINGS_gcc := sign-compare type-limits unused-result maybe-uninitialized, \ > DISABLED_WARNINGS_clang := incompatible-pointer-types, \ > DISABLED_WARNINGS_solstudio := E_NEWLINE_NOT_LAST E_DECLARATION_IN_CODE, \ > - DISABLED_WARNINGS_microsoft := 4244 4267, \ > + DISABLED_WARNINGS_microsoft := 4018 4244 4267, \ > MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsplashscreen/mapfile-vers, \ > LDFLAGS := $(LDFLAGS_JDKLIB) \ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > From alexandr.scherbatiy at oracle.com Thu May 14 09:40:25 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 14 May 2015 12:40:25 +0300 Subject: [9] Review request for 8065739 [macosx] Frame warps to lower left of screen when displayed In-Reply-To: <555203BC.2090604@oracle.com> References: <5525410A.8080407@oracle.com> <552EC29D.3090706@oracle.com> <554100C2.6050902@oracle.com> <554CABEF.7030502@oracle.com> <554CAF39.8040409@oracle.com> <555203BC.2090604@oracle.com> Message-ID: <55546D89.7080704@oracle.com> On 5/12/2015 4:44 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > - maximized bounds are updated after switching to new screen if they > are not set by a user > - the test for the maximized window moved from one screen to another > is added Sorry. Just forgot to add the webrev link: http://cr.openjdk.java.net/~alexsch/8065739/webrev.04/ Thanks, Alexandr. > > > Thanks, > Alexandr. > > On 5/8/2015 3:42 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Does the new tests cover all corner cases which we discussed offline? >> >> On 08.05.15 15:28, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.03 >>> >>> - The -windowWillUseStandardFrame:defaultFrame: method is >>> implemented in AWTWindow to correctly get and check a size of the >>> maximized window. >>> After that the -isZoomed method correctly defines the zoomed >>> state for both visible and not visible window. >>> >>> Thanks, >>> Alexandr. >>> >>> On 4/29/2015 7:03 PM, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.02 >>>> >>>> - the zoom state is applied after NSWindow creation if Frame has >>>> MAXIMIZED_BOTH state. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 4/15/2015 10:57 PM, Sergey Bylokhov wrote: >>>>> Hi, Alexander. >>>>> As far as I understand the main issue is that we get a native >>>>> notifications during window initialization(after nswindows was >>>>> created and before zoom method will be called)? Probably we can >>>>> apply the zoom state when we create a window in one appkit call? >>>>> >>>>> On 08.04.15 17:54, Alexander Scherbatiy wrote: >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8065739 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8065739/webrev.00 >>>>>> >>>>>> Use case: >>>>>> ------------ >>>>>> Frame frame = new Frame(); >>>>>> frame.pack(); >>>>>> frame.setBounds(screenBounds); >>>>>> frame.setVisible(true); >>>>>> ------------ >>>>>> >>>>>> The frame is in the normal state but Mac OS X treats a frame >>>>>> with screen bounds as zoomed. >>>>>> The setVisible() method calls unmaximize() method to return the >>>>>> zoomed window to the normal state. >>>>>> The native zoom() method sets the initial sizes for the window >>>>>> which are zero because of the pack() call. >>>>>> >>>>>> >>>>>> There is already checkZoom() method which synchronizes native >>>>>> window zoom state and and the frame extended state when a frame >>>>>> is resized by mouse. >>>>>> However it can't be always used for the synchronization between >>>>>> native window zoom state and setBounds() call because of the >>>>>> following case: >>>>>> >>>>>> ----------------- >>>>>> Frame frame = new Frame(); >>>>>> frame.setBounds(smallBounds); >>>>>> frame.setExtendedState(Frame.MAXIMIZED_BOTH); >>>>>> frame.setVisible(true); >>>>>> ----------------- >>>>>> >>>>>> This is the valid scenario where the frame should be maximized. >>>>>> >>>>>> The solution synchronizes the zoom and the frame state only >>>>>> when the native window is zoomed. >>>>>> In opposite case we need to return from the zoomed sizes to >>>>>> previous sizes which are the same as for the zoomed window. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>> >>>>> >>>> >>> >> >> > From alexandr.scherbatiy at oracle.com Thu May 14 11:23:19 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 14 May 2015 14:23:19 +0300 Subject: RfR JDK-8078408, Java version applet hangs with Voice over turned on In-Reply-To: <554D13E7.2030606@oracle.com> References: <554D0A4C.5080700@oracle.com> <554D13E7.2030606@oracle.com> Message-ID: <555485A7.6000409@oracle.com> The fix looks good to me. Thanks, Alexandr. On 5/8/2015 10:52 PM, Pete Brunet wrote: > Resending to correct list... > > On 5/8/15 2:11 PM, Pete Brunet wrote: >> Please review the fix for JDK-8078408 "Java version applet hangs with >> Voice over turned on". >> >> The failure is an NPE. There is a variable that is OK to be null at the >> point of failure and the fix adds a check for it being null. >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8078408/webrev.00/ >> >> Thanks, Pete From david.dehaven at oracle.com Thu May 14 16:14:50 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 14 May 2015 09:14:50 -0700 Subject: RFR: 8080343: Incorrect GPL header... Message-ID: <8DABDC9C-9FAC-493E-92F0-82AE5E321846@oracle.com> Please review a trivial correction to these two copyright headers. I just added a comma after the second date. diff --git a/src/macosx/javavm/export/jawt_md.h b/src/macosx/javavm/export/jawt_md.h --- a/src/macosx/javavm/export/jawt_md.h +++ b/src/macosx/javavm/export/jawt_md.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2013 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it diff --git a/src/solaris/native/sun/awt/utility/rect.h b/src/solaris/native/sun/awt/utility/rect.h --- a/src/solaris/native/sun/awt/utility/rect.h +++ b/src/solaris/native/sun/awt/utility/rect.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2007, 2014 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2007, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it -DrD- From david.dehaven at oracle.com Thu May 14 16:18:54 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 14 May 2015 09:18:54 -0700 Subject: RFR: 8080343: Incorrect GPL header... In-Reply-To: <8DABDC9C-9FAC-493E-92F0-82AE5E321846@oracle.com> References: <8DABDC9C-9FAC-493E-92F0-82AE5E321846@oracle.com> Message-ID: (oops) This is intended for jdk8u/dev, will forward port to 9 too. -DrD- > Please review a trivial correction to these two copyright headers. I just added a comma after the second date. > > diff --git a/src/macosx/javavm/export/jawt_md.h b/src/macosx/javavm/export/jawt_md.h > --- a/src/macosx/javavm/export/jawt_md.h > +++ b/src/macosx/javavm/export/jawt_md.h > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1999, 2013 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > diff --git a/src/solaris/native/sun/awt/utility/rect.h b/src/solaris/native/sun/awt/utility/rect.h > --- a/src/solaris/native/sun/awt/utility/rect.h > +++ b/src/solaris/native/sun/awt/utility/rect.h > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2007, 2014 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2007, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > > -DrD- > From philip.race at oracle.com Thu May 14 19:21:15 2015 From: philip.race at oracle.com (Phil Race) Date: Thu, 14 May 2015 12:21:15 -0700 Subject: RFR: 8080343: Incorrect GPL header... In-Reply-To: References: <8DABDC9C-9FAC-493E-92F0-82AE5E321846@oracle.com> Message-ID: <5554F5AB.1000304@oracle.com> Looks OK .. although now you've changed it shouldn't the copyright be 2015 ;-) Seriously .. no it would not be, but you can bet good money on a RE script updating it sometime early next year. -phil. On 05/14/2015 09:18 AM, David DeHaven wrote: > (oops) > > This is intended for jdk8u/dev, will forward port to 9 too. > > -DrD- > >> Please review a trivial correction to these two copyright headers. I just added a comma after the second date. >> >> diff --git a/src/macosx/javavm/export/jawt_md.h b/src/macosx/javavm/export/jawt_md.h >> --- a/src/macosx/javavm/export/jawt_md.h >> +++ b/src/macosx/javavm/export/jawt_md.h >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1999, 2013 Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> diff --git a/src/solaris/native/sun/awt/utility/rect.h b/src/solaris/native/sun/awt/utility/rect.h >> --- a/src/solaris/native/sun/awt/utility/rect.h >> +++ b/src/solaris/native/sun/awt/utility/rect.h >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2007, 2014 Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2007, 2014, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> >> -DrD- >> From Sergey.Bylokhov at oracle.com Thu May 14 21:34:20 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 15 May 2015 00:34:20 +0300 Subject: RFR: 8080343: Incorrect GPL header... In-Reply-To: <5554F5AB.1000304@oracle.com> References: <8DABDC9C-9FAC-493E-92F0-82AE5E321846@oracle.com> <5554F5AB.1000304@oracle.com> Message-ID: <555514DC.4040306@oracle.com> +1 On 14.05.15 22:21, Phil Race wrote: > Looks OK .. although now you've changed it shouldn't the copyright be > 2015 ;-) > > Seriously .. no it would not be, but you can bet good money on a RE > script > updating it sometime early next year. > > -phil. > > On 05/14/2015 09:18 AM, David DeHaven wrote: >> (oops) >> >> This is intended for jdk8u/dev, will forward port to 9 too. >> >> -DrD- >> >>> Please review a trivial correction to these two copyright headers. I >>> just added a comma after the second date. >>> >>> diff --git a/src/macosx/javavm/export/jawt_md.h >>> b/src/macosx/javavm/export/jawt_md.h >>> --- a/src/macosx/javavm/export/jawt_md.h >>> +++ b/src/macosx/javavm/export/jawt_md.h >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 1999, 2013 Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 1999, 2013, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or >>> modify it >>> diff --git a/src/solaris/native/sun/awt/utility/rect.h >>> b/src/solaris/native/sun/awt/utility/rect.h >>> --- a/src/solaris/native/sun/awt/utility/rect.h >>> +++ b/src/solaris/native/sun/awt/utility/rect.h >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2007, 2014 Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2007, 2014, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or >>> modify it >>> >>> -DrD- >>> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu May 14 22:57:42 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 15 May 2015 01:57:42 +0300 Subject: [9] Review Request: 8071306 GUI perfomance are very slow compared java 1.6.0_45 In-Reply-To: <5551E93C.2010807@oracle.com> References: <554AB431.1040707@oracle.com> <554C8093.50205@oracle.com> <554D57A6.40202@oracle.com> <5551E93C.2010807@oracle.com> Message-ID: <55552866.1070407@oracle.com> Hi, Anton. > + * Determines the bounds of a visible part of the component relative to its > + * parents. > Did you mean "to its parent"? Yep, new version: http://cr.openjdk.java.net/~serb/8071306/webrev.05/ > >>> >>> 2. >>> >>> 100 * The components in this container. >>> 101 * @see #add >>> 102 * @see #getComponents >>> 103 */ >>> 104 private java.util.List component = new >>> ArrayList<>(); >>> >>> May be it's worth to rename the field? The "component" name is odd... >> I suppose it wasn't changed, because this name is used in the >> serialization for a long time. Plus there are a bunch of the similar >> vars like: tmpComponent etc. I can do it later for jdk9 only. > > Ok, thanks. It's up to you. > > Regards, > Anton. > >>> >>> Regards, >>> Anton. >>> >>> On 07.05.2015 3:39, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review the fix for a jdk9. I plan to backport it to jdk8u60. >>>> >>>> Description. >>>> An UIworks really slowly, when an application has a lot of >>>> components in one container, and these components should be >>>> disabled one by one. >>>> The reason is the next sequence of methods calls: >>>> Component.setEnabled->updateCursorImmediately()-> some cursor >>>> related >>>> staff->GlobalCursorManager._updateCursor->Container.findComponentAt()-iteration >>>> over all components in the container.....-> twice.... >>>> >>>> You can imagine how it works in case of 10000 components in the >>>> container. >>>> >>>> Note that in the bug report described difference jdk6 vs jdk8 -> >>>> 1sec vs 6 sec. This was caused by the two fixes, one of which adds >>>> checkTreeLock() and in another one a simple array of components was >>>> replaced by the ArrayList. Since code was added to the really hot >>>> method we got so big slowdown. >>>> >>>> To fix the problem I suggest two different approaches: >>>> - Container.java: Fix a general case, by eliminating a second >>>> iteration in the hot loop. >>>> - Component.java: Totally eliminates cursor machinery, if >>>> component cannot affect current cursor. >>>> >>>> Some speedup measurements on my local system: >>>> - Simple removing of checkTreeLock() will partly solve a >>>> regression reported by the user(12 sec -> 5 sec). >>>> - Changes in the loop will speedup the code in the worse case(5->2 >>>> sec) >>>> - The changes in the Component.java will change the performance >>>> from 2 sec to 100< ms >>>> >>>> Test case which was added was improved from 10 seconds to 80 ms. >>>> >>>> JMH test: >>>> http://cr.openjdk.java.net/~serb/8071306/SetEnabledPerformanceTest.java >>>> >>>> Fixedversion: >>>> >>>> Benchmark Mode Cnt >>>> Score Error Units >>>> SetEnabledPerformanceTest.testContains thrpt 5 301300,813 >>>> ? 17338,045 ops/ms >>>> SetEnabledPerformanceTest.testFindComponentAt thrpt 5 20,521 >>>> ? 0,269 ops/ms >>>> SetEnabledPerformanceTest.testGetComponentAt thrpt 5 22,297 >>>> ? 1,264 ops/ms >>>> SetEnabledPerformanceTest.testSetEnabled thrpt 5 711,120 >>>> ? 19,837 ops/ms >>>> >>>> Base version: >>>> >>>> Benchmark Mode Cnt >>>> Score Error Units >>>> SetEnabledPerformanceTest.testContains thrpt 5 299145,642 >>>> ? 2120,183 ops/ms >>>> SetEnabledPerformanceTest.testFindComponentAt thrpt 5 1,101 >>>> ? 0,012 ops/ms >>>> SetEnabledPerformanceTest.testGetComponentAt thrpt 5 6,792 >>>> ? 0,097 ops/ms >>>> SetEnabledPerformanceTest.testSetEnabled thrpt 5 0,464 >>>> ? 0,020 ops/ms >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071306 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/8071306/webrev.03 >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri May 15 11:30:57 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 15 May 2015 14:30:57 +0300 Subject: [9] Review request for 8065739 [macosx] Frame warps to lower left of screen when displayed In-Reply-To: <55546D89.7080704@oracle.com> References: <5525410A.8080407@oracle.com> <552EC29D.3090706@oracle.com> <554100C2.6050902@oracle.com> <554CABEF.7030502@oracle.com> <554CAF39.8040409@oracle.com> <555203BC.2090604@oracle.com> <55546D89.7080704@oracle.com> Message-ID: <5555D8F1.9000101@oracle.com> Hi, Alexander. A few notes: - _peer.setMaximizedBounds(_peer.getMaximizedBounds()); this line looks odd, probably we can call updateMaximizedBounds in LWWindowPeer. initializeImpl()? - Do we need to call maximize(); in the initialize() or we can leave it in the setVisible()? It seems that after we set NSWindowStandardFrame isZoomed should work properly in the callback? - Why we cannot return DefaultMaximizedBounds from the getMaximizedBounds if it was not set? Then it will not be necessary to check it to null everywhere. - Can we call updateMaximizedBounds(); in LWWindowPeer.displayChanged() only in case of new device? On 14.05.15 12:40, Alexander Scherbatiy wrote: > On 5/12/2015 4:44 PM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> - maximized bounds are updated after switching to new screen if they >> are not set by a user >> - the test for the maximized window moved from one screen to another >> is added > Sorry. Just forgot to add the webrev link: > http://cr.openjdk.java.net/~alexsch/8065739/webrev.04/ > > Thanks, > Alexandr. > >> >> >> Thanks, >> Alexandr. >> >> On 5/8/2015 3:42 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> Does the new tests cover all corner cases which we discussed offline? >>> >>> On 08.05.15 15:28, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.03 >>>> >>>> - The -windowWillUseStandardFrame:defaultFrame: method is >>>> implemented in AWTWindow to correctly get and check a size of the >>>> maximized window. >>>> After that the -isZoomed method correctly defines the zoomed >>>> state for both visible and not visible window. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 4/29/2015 7:03 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.02 >>>>> >>>>> - the zoom state is applied after NSWindow creation if Frame has >>>>> MAXIMIZED_BOTH state. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 4/15/2015 10:57 PM, Sergey Bylokhov wrote: >>>>>> Hi, Alexander. >>>>>> As far as I understand the main issue is that we get a native >>>>>> notifications during window initialization(after nswindows was >>>>>> created and before zoom method will be called)? Probably we can >>>>>> apply the zoom state when we create a window in one appkit call? >>>>>> >>>>>> On 08.04.15 17:54, Alexander Scherbatiy wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the fix: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8065739 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8065739/webrev.00 >>>>>>> >>>>>>> Use case: >>>>>>> ------------ >>>>>>> Frame frame = new Frame(); >>>>>>> frame.pack(); >>>>>>> frame.setBounds(screenBounds); >>>>>>> frame.setVisible(true); >>>>>>> ------------ >>>>>>> >>>>>>> The frame is in the normal state but Mac OS X treats a frame >>>>>>> with screen bounds as zoomed. >>>>>>> The setVisible() method calls unmaximize() method to return >>>>>>> the zoomed window to the normal state. >>>>>>> The native zoom() method sets the initial sizes for the window >>>>>>> which are zero because of the pack() call. >>>>>>> >>>>>>> >>>>>>> There is already checkZoom() method which synchronizes native >>>>>>> window zoom state and and the frame extended state when a frame >>>>>>> is resized by mouse. >>>>>>> However it can't be always used for the synchronization >>>>>>> between native window zoom state and setBounds() call because of >>>>>>> the following case: >>>>>>> >>>>>>> ----------------- >>>>>>> Frame frame = new Frame(); >>>>>>> frame.setBounds(smallBounds); >>>>>>> frame.setExtendedState(Frame.MAXIMIZED_BOTH); >>>>>>> frame.setVisible(true); >>>>>>> ----------------- >>>>>>> >>>>>>> This is the valid scenario where the frame should be maximized. >>>>>>> >>>>>>> The solution synchronizes the zoom and the frame state only >>>>>>> when the native window is zoomed. >>>>>>> In opposite case we need to return from the zoomed sizes to >>>>>>> previous sizes which are the same as for the zoomed window. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.tarasov at oracle.com Fri May 15 14:13:58 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 15 May 2015 17:13:58 +0300 Subject: internal API usage: sun.awt.CausedFocusEvent In-Reply-To: <85B3FFA2-8F80-4397-9189-DF2927FA2C4E@cbfiddle.com> References: <85B3FFA2-8F80-4397-9189-DF2927FA2C4E@cbfiddle.com> Message-ID: <5555FF26.1060107@oracle.com> Hi Alan, Appropriate RFE is targeted to jdk9: https://bugs.openjdk.java.net/browse/JDK-8080395 Regards, Anton. On 13.05.2015 20:40, Alan Snyder wrote: > I have been using sun.awt.CausedFocusEvent to implement special behavior in response to an explicit user-initiated focus traversal to a component. The main point is that I want to inhibit this behavior for all other kinds of focus gained events. > > Will there be some way of doing this in JDK9? > From anton.nashatyrev at oracle.com Fri May 15 14:20:20 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Fri, 15 May 2015 17:20:20 +0300 Subject: [9] Review request for 8068886: IDEA IntelliJ crashes in objc_msgSend when an accessibility tool is enabled In-Reply-To: <5552473D.4040902@oracle.com> References: <554CE9BD.9040001@oracle.com> <5552473D.4040902@oracle.com> Message-ID: <555600A4.1030506@oracle.com> Hi Sergey, thanks for review (and for the fix idea itself)! I've added some comments, you may take a look here: http://cr.openjdk.java.net/~anashaty/8068886/webrev.01/ > Also please confirm that all our code follow this rule. I've sent you two suspects, but if this needs to fixed as well I suggest to make it under another bug. Thanks! Anton. On 12.05.2015 21:32, Sergey Bylokhov wrote: > Hi, Anton. > The fix looks fine, but I suggest to document the new resources > deallocation policy. I suppose documentation of loops, > CFRetainedResource, etc should be updated. > Also please confirm that all our code follow this rule. > > On 08.05.15 19:52, Anton Nashatyrev wrote: >> Hello, >> could you please review the following fix: >> >> fix: http://cr.openjdk.java.net/~anashaty/8068886/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8068886 >> >> Problem: the native window pointer is disposed in the inner >> AppKit loop, while it is still referenced on the stack in the native >> Cocoa method which caused the mentioned inner loop. When the inner >> loop is exited Cocoa crashes while dereferencing this window pointer >> >> Fix: dispose resources in the main AppKit loop only. For this a >> 'dispose message' posted which is processed only on the main loop. >> >> Thanks! >> Anton. > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From javalists at cbfiddle.com Fri May 15 14:24:18 2015 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 15 May 2015 07:24:18 -0700 Subject: internal API usage: sun.awt.CausedFocusEvent In-Reply-To: <5555FF26.1060107@oracle.com> References: <85B3FFA2-8F80-4397-9189-DF2927FA2C4E@cbfiddle.com> <5555FF26.1060107@oracle.com> Message-ID: Thank you. Alan > On May 15, 2015, at 7:13 AM, Anton V. Tarasov wrote: > > Hi Alan, > > Appropriate RFE is targeted to jdk9: > > https://bugs.openjdk.java.net/browse/JDK-8080395 > > Regards, > Anton. > > On 13.05.2015 20:40, Alan Snyder wrote: >> I have been using sun.awt.CausedFocusEvent to implement special behavior in response to an explicit user-initiated focus traversal to a component. The main point is that I want to inhibit this behavior for all other kinds of focus gained events. >> >> Will there be some way of doing this in JDK9? >> > From Sergey.Bylokhov at oracle.com Fri May 15 18:27:47 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 15 May 2015 21:27:47 +0300 Subject: [9] Review request for 8068886: IDEA IntelliJ crashes in objc_msgSend when an accessibility tool is enabled In-Reply-To: <555600A4.1030506@oracle.com> References: <554CE9BD.9040001@oracle.com> <5552473D.4040902@oracle.com> <555600A4.1030506@oracle.com> Message-ID: <55563AA3.5040409@oracle.com> Hi, Anton. Thanks, the fix looks fine. > I've sent you two suspects, but if this needs to fixed as well I > suggest to make it under another bug. ok, I'll take look at it. > > Thanks! > Anton. > > On 12.05.2015 21:32, Sergey Bylokhov wrote: >> Hi, Anton. >> The fix looks fine, but I suggest to document the new resources >> deallocation policy. I suppose documentation of loops, >> CFRetainedResource, etc should be updated. >> Also please confirm that all our code follow this rule. >> >> On 08.05.15 19:52, Anton Nashatyrev wrote: >>> Hello, >>> could you please review the following fix: >>> >>> fix: http://cr.openjdk.java.net/~anashaty/8068886/webrev.00/ >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8068886 >>> >>> Problem: the native window pointer is disposed in the inner >>> AppKit loop, while it is still referenced on the stack in the native >>> Cocoa method which caused the mentioned inner loop. When the inner >>> loop is exited Cocoa crashes while dereferencing this window pointer >>> >>> Fix: dispose resources in the main AppKit loop only. For this a >>> 'dispose message' posted which is processed only on the main loop. >>> >>> Thanks! >>> Anton. >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.tarasov at oracle.com Mon May 18 09:03:07 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 18 May 2015 12:03:07 +0300 Subject: [9] Review Request: 8071306 GUI perfomance are very slow compared java 1.6.0_45 In-Reply-To: <55552866.1070407@oracle.com> References: <554AB431.1040707@oracle.com> <554C8093.50205@oracle.com> <554D57A6.40202@oracle.com> <5551E93C.2010807@oracle.com> <55552866.1070407@oracle.com> Message-ID: <5559AACB.4020701@oracle.com> On 15.05.2015 1:57, Sergey Bylokhov wrote: > Hi, Anton. >> + * Determines the bounds of a visible part of the component relative to its >> + * parents. >> Did you mean "to its parent"? > Yep, new version: > http://cr.openjdk.java.net/~serb/8071306/webrev.05/ Looks good to me. Regards, Anton. >> >>>> >>>> 2. >>>> >>>> 100 * The components in this container. >>>> 101 * @see #add >>>> 102 * @see #getComponents >>>> 103 */ >>>> 104 private java.util.List component = new ArrayList<>(); >>>> >>>> May be it's worth to rename the field? The "component" name is odd... >>> I suppose it wasn't changed, because this name is used in the serialization for a long time. >>> Plus there are a bunch of the similar vars like: tmpComponent etc. I can do it later for jdk9 only. >> >> Ok, thanks. It's up to you. >> >> Regards, >> Anton. >> >>>> >>>> Regards, >>>> Anton. >>>> >>>> On 07.05.2015 3:39, Sergey Bylokhov wrote: >>>>> Hello. >>>>> Please review the fix for a jdk9. I plan to backport it to jdk8u60. >>>>> >>>>> Description. >>>>> An UIworks really slowly, when an application has a lot of components in one container, and >>>>> these components should be disabled one by one. >>>>> The reason is the next sequence of methods calls: >>>>> Component.setEnabled->updateCursorImmediately()-> some cursor related >>>>> staff->GlobalCursorManager._updateCursor->Container.findComponentAt()-iteration over all >>>>> components in the container.....-> twice.... >>>>> >>>>> You can imagine how it works in case of 10000 components in the container. >>>>> >>>>> Note that in the bug report described difference jdk6 vs jdk8 -> 1sec vs 6 sec. This was >>>>> caused by the two fixes, one of which adds checkTreeLock() and in another one a simple array >>>>> of components was replaced by the ArrayList. Since code was added to the really hot method we >>>>> got so big slowdown. >>>>> >>>>> To fix the problem I suggest two different approaches: >>>>> - Container.java: Fix a general case, by eliminating a second iteration in the hot loop. >>>>> - Component.java: Totally eliminates cursor machinery, if component cannot affect current >>>>> cursor. >>>>> >>>>> Some speedup measurements on my local system: >>>>> - Simple removing of checkTreeLock() will partly solve a regression reported by the user(12 >>>>> sec -> 5 sec). >>>>> - Changes in the loop will speedup the code in the worse case(5->2 sec) >>>>> - The changes in the Component.java will change the performance from 2 sec to 100< ms >>>>> >>>>> Test case which was added was improved from 10 seconds to 80 ms. >>>>> >>>>> JMH test: http://cr.openjdk.java.net/~serb/8071306/SetEnabledPerformanceTest.java >>>>> >>>>> Fixedversion: >>>>> >>>>> Benchmark Mode Cnt Score Error Units >>>>> SetEnabledPerformanceTest.testContains thrpt 5 301300,813 ? 17338,045 ops/ms >>>>> SetEnabledPerformanceTest.testFindComponentAt thrpt 5 20,521 ? 0,269 ops/ms >>>>> SetEnabledPerformanceTest.testGetComponentAt thrpt 5 22,297 ? 1,264 ops/ms >>>>> SetEnabledPerformanceTest.testSetEnabled thrpt 5 711,120 ? 19,837 ops/ms >>>>> >>>>> Base version: >>>>> >>>>> Benchmark Mode Cnt Score Error Units >>>>> SetEnabledPerformanceTest.testContains thrpt 5 299145,642 ? 2120,183 ops/ms >>>>> SetEnabledPerformanceTest.testFindComponentAt thrpt 5 1,101 ? 0,012 ops/ms >>>>> SetEnabledPerformanceTest.testGetComponentAt thrpt 5 6,792 ? 0,097 ops/ms >>>>> SetEnabledPerformanceTest.testSetEnabled thrpt 5 0,464 ? 0,020 ops/ms >>>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071306 >>>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8071306/webrev.03 >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue May 19 10:10:26 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 19 May 2015 13:10:26 +0300 Subject: [9] Review request for 8080137 Dragged events for extra mouse buttons (4, 5, 6) are not generated on JSplitPane Message-ID: <555B0C12.8060706@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8080137 webrev: http://cr.openjdk.java.net/~alexsch/8080137/webrev.00 The LightweightDispatcher.isMouseGrab(MouseEvent) method does not take into account the extended modifiers for additional buttons. Thanks, Alexandr. From peter.levart at gmail.com Tue May 19 10:50:28 2015 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 19 May 2015 12:50:28 +0200 Subject: splashscreen_png.c compile error with gcc 4.9.2 Message-ID: <555B1574.7000302@gmail.com> Hi, I hope this is the right thread to post the observation. Building recent OpenJDK 9 from sources on Fedora 21 fails with this: /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c: In function 'SplashDecodePng': /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c:51:16: error: variable 'row_pointers' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] png_bytepp row_pointers = NULL; ^ /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c:52:15: error: variable 'image_data' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered] png_bytep image_data = NULL; ^ cc1: all warnings being treated as errors gmake[3]: *** [/home/peter/work/hg/jdk9-dev/build/linux-x86_64-normal-server-release/support/native/java.desktop/libsplashscreen/splashscreen_png.o] Error 1 gmake[3]: *** Waiting for unfinished jobs.... Awt2dLibraries.gmk:879: recipe for target '/home/peter/work/hg/jdk9-dev/build/linux-x86_64-normal-server-release/support/native/java.desktop/libsplashscreen/splashscreen_png.o' failed gmake[2]: *** [java.desktop-libs] Error 1 make/Main.gmk:168: recipe for target 'java.desktop-libs' failed I found that making the following change eliminates the compiler error: http://cr.openjdk.java.net/~plevart/jdk9-dev/splashscreen_png/webrev.01/ Is this the right way to fix it? Regards, Peter From alexander.zvegintsev at oracle.com Tue May 19 13:59:55 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 19 May 2015 16:59:55 +0300 Subject: splashscreen_png.c compile error with gcc 4.9.2 In-Reply-To: <555B1574.7000302@gmail.com> References: <555B1574.7000302@gmail.com> Message-ID: <555B41DB.8040103@oracle.com> Hi Peter, I think that your solution can be simplified to: diff -r 729dffc8afa0 src/java.desktop/share/native/libsplashscreen/splashscreen_png.c --- a/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c +++ b/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c @@ -77,6 +77,8 @@ SplashDecodePng(Splash * splash, png_rw_ #else if (setjmp(png_jmpbuf(png_ptr))) { #endif + row_pointers = NULL; + image_data = NULL; goto done; } As another solution you can declare row_pointers and image_data as volatile. BTW, Could you please file an issue? Thanks, Alexander. On 05/19/2015 01:50 PM, Peter Levart wrote: > Hi, > > I hope this is the right thread to post the observation. > > Building recent OpenJDK 9 from sources on Fedora 21 fails with this: > > /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c: > In function 'SplashDecodePng': > /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c:51:16: > error: variable 'row_pointers' might be clobbered by 'longjmp' or > 'vfork' [-Werror=clobbered] > png_bytepp row_pointers = NULL; > ^ > /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c:52:15: > error: variable 'image_data' might be clobbered by 'longjmp' or > 'vfork' [-Werror=clobbered] > png_bytep image_data = NULL; > ^ > cc1: all warnings being treated as errors > gmake[3]: *** > [/home/peter/work/hg/jdk9-dev/build/linux-x86_64-normal-server-release/support/native/java.desktop/libsplashscreen/splashscreen_png.o] > Error 1 > gmake[3]: *** Waiting for unfinished jobs.... > Awt2dLibraries.gmk:879: recipe for target > '/home/peter/work/hg/jdk9-dev/build/linux-x86_64-normal-server-release/support/native/java.desktop/libsplashscreen/splashscreen_png.o' > failed > gmake[2]: *** [java.desktop-libs] Error 1 > make/Main.gmk:168: recipe for target 'java.desktop-libs' failed > > > I found that making the following change eliminates the compiler error: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/splashscreen_png/webrev.01/ > > Is this the right way to fix it? > > Regards, Peter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue May 19 14:06:05 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 19 May 2015 17:06:05 +0300 Subject: [9] Review request for 8080137 Dragged events for extra mouse buttons (4, 5, 6) are not generated on JSplitPane In-Reply-To: <555B0C12.8060706@oracle.com> References: <555B0C12.8060706@oracle.com> Message-ID: <555B434D.3080501@oracle.com> The test fails on Linux because Xsystem does not set state for motion events when extra button is pressed. I have filled the issue on it: JDK-8080676 Mouse drag does not work for extra buttons on Linux https://bugs.openjdk.java.net/browse/JDK-8080676 Thanks, Alexandr. On 5/19/2015 1:10 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8080137 > webrev: http://cr.openjdk.java.net/~alexsch/8080137/webrev.00 > > The LightweightDispatcher.isMouseGrab(MouseEvent) method does not > take into account the extended modifiers for additional buttons. > > > Thanks, > Alexandr. > From alexander.zvegintsev at oracle.com Tue May 19 14:09:47 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 19 May 2015 17:09:47 +0300 Subject: [9] Review request for 8080137 Dragged events for extra mouse buttons (4, 5, 6) are not generated on JSplitPane In-Reply-To: <555B434D.3080501@oracle.com> References: <555B0C12.8060706@oracle.com> <555B434D.3080501@oracle.com> Message-ID: <555B442B.3010402@oracle.com> Hello Alexandr, the fix looks fine to me. Thanks, Alexander. On 05/19/2015 05:06 PM, Alexander Scherbatiy wrote: > > The test fails on Linux because Xsystem does not set state for > motion events when extra button is pressed. > > I have filled the issue on it: JDK-8080676 Mouse drag does not work > for extra buttons on Linux > https://bugs.openjdk.java.net/browse/JDK-8080676 > > Thanks, > Alexandr. > > On 5/19/2015 1:10 PM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8080137 >> webrev: http://cr.openjdk.java.net/~alexsch/8080137/webrev.00 >> >> The LightweightDispatcher.isMouseGrab(MouseEvent) method does not >> take into account the extended modifiers for additional buttons. >> >> >> Thanks, >> Alexandr. >> > From semyon.sadetsky at oracle.com Tue May 19 15:45:35 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 19 May 2015 18:45:35 +0300 Subject: [9] Review request for 8003399: JFileChooser gives wrong path to selected file when saving to Libraries folder on Windows 7 In-Reply-To: <554CC1A4.90107@oracle.com> References: <554B1EE4.1080001@oracle.com> <554B21C5.9020500@oracle.com> <554B5AA1.1080206@oracle.com> <554CAFD0.9030305@oracle.com> <554CC1A4.90107@oracle.com> Message-ID: <555B5A9F.3090207@oracle.com> Hi Anton, here is an updated version: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.01/ --Semyon On 5/8/2015 5:01 PM, Semyon Sadetsky wrote: > > On 5/8/2015 3:45 PM, Sergey Bylokhov wrote: >> On 07.05.15 15:29, Semyon Sadetsky wrote: >>> Hi Sergey, >>> >>> Yes, after the fix filedialog produces usual filesystem paths for >>> libraries which are readable for java.io. >> Just to clarify: after the fix, both Open and Save dialog works? > Open file in library was not a problem, because an exicting file has > real FS path already. > >>> But there are no possibility to reference files in libraries >>> directly using new File(). >>> >>> --Semyon >>> >>> On 5/7/2015 11:26 AM, Sergey Bylokhov wrote: >>>> Hi, Semyon. >>>> Can you please raise the supportness of this in the java.io on the >>>> core-libs alias. >>>> Does the open filedialog will work after the fix? >>>> >>>> On 07.05.15 11:14, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Please review fix for JDK9. >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8003399 >>>>> >>>>> ***THE ROOT CAUSE >>>>> JDK uses legacy WINAPI special folders calls while MS introduced a >>>>> new interfaces IKnownFolder and IShellLibrary to manage special >>>>> folder locations and the new Libraries functionality in Windows 7 >>>>> is not backward compatible with old special folders CSIDL. >>>>> >>>>> ***SOLUTION >>>>> Since it is too expensive to migrate AWT shell to the new >>>>> interfaces and still they are not supported in java.io the >>>>> solution is to map virtual folder PIDL to the Known Folder GUID >>>>> and replace libraries links with the default library save >>>>> location. Thus the File save dialog will be able to work with any >>>>> Libraries registered in the system (Windows Libraries concept >>>>> assumes that Libraries can be added arbitrary). >>>>> The resulting code should be compatible with older Windows >>>>> versions because the new COM interfaces are called only if they >>>>> are available and a Libraries link has been actually requested. >>>>> >>>>> ***TESTING >>>>> A test scenario is added to check that all available Libraries >>>>> links are converted into filesystem paths. >>>>> >>>>> --Semyon >>>>> >>>> >>>> >>> >> >> > From peter.levart at gmail.com Wed May 20 08:00:03 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 20 May 2015 10:00:03 +0200 Subject: [9] Review Request: 8080695: splashscreen_png.c compile error with gcc 4.9.2 In-Reply-To: <555B41DB.8040103@oracle.com> References: <555B1574.7000302@gmail.com> <555B41DB.8040103@oracle.com> Message-ID: <555C3F03.4030004@gmail.com> Hi Alexander, I filed the issue as: https://bugs.openjdk.java.net/browse/JDK-8080695 The proposed patch is this, which also fixes compile time error: http://cr.openjdk.java.net/~plevart/jdk9-dev/splashscreen_png/webrev.02/ If this is OK, I can push it if the change can go via jdk9-dev repository where I can commit. Is there a special repository for client libs? Do I need a sponsor? Regards, Peter On 05/19/2015 03:59 PM, Alexander Zvegintsev wrote: > Hi Peter, > > I think that your solution can be simplified to: > > diff -r 729dffc8afa0 > src/java.desktop/share/native/libsplashscreen/splashscreen_png.c > --- a/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c > +++ b/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c > @@ -77,6 +77,8 @@ SplashDecodePng(Splash * splash, png_rw_ > #else > if (setjmp(png_jmpbuf(png_ptr))) { > #endif > + row_pointers = NULL; > + image_data = NULL; > goto done; > } > > As another solution you can declare row_pointers and image_data as > volatile. > > BTW, Could you please file an issue? > > Thanks, > > Alexander. > On 05/19/2015 01:50 PM, Peter Levart wrote: >> Hi, >> >> I hope this is the right thread to post the observation. >> >> Building recent OpenJDK 9 from sources on Fedora 21 fails with this: >> >> /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c: >> In function 'SplashDecodePng': >> /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c:51:16: >> error: variable 'row_pointers' might be clobbered by 'longjmp' or >> 'vfork' [-Werror=clobbered] >> png_bytepp row_pointers = NULL; >> ^ >> /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c:52:15: >> error: variable 'image_data' might be clobbered by 'longjmp' or >> 'vfork' [-Werror=clobbered] >> png_bytep image_data = NULL; >> ^ >> cc1: all warnings being treated as errors >> gmake[3]: *** >> [/home/peter/work/hg/jdk9-dev/build/linux-x86_64-normal-server-release/support/native/java.desktop/libsplashscreen/splashscreen_png.o] >> Error 1 >> gmake[3]: *** Waiting for unfinished jobs.... >> Awt2dLibraries.gmk:879: recipe for target >> '/home/peter/work/hg/jdk9-dev/build/linux-x86_64-normal-server-release/support/native/java.desktop/libsplashscreen/splashscreen_png.o' >> failed >> gmake[2]: *** [java.desktop-libs] Error 1 >> make/Main.gmk:168: recipe for target 'java.desktop-libs' failed >> >> >> I found that making the following change eliminates the compiler error: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/splashscreen_png/webrev.01/ >> >> Is this the right way to fix it? >> >> Regards, Peter >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Wed May 20 12:05:34 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 20 May 2015 15:05:34 +0300 Subject: [9] Review Request: 8080695: splashscreen_png.c compile error with gcc 4.9.2 In-Reply-To: <555C3F03.4030004@gmail.com> References: <555B1574.7000302@gmail.com> <555B41DB.8040103@oracle.com> <555C3F03.4030004@gmail.com> Message-ID: <555C788E.8040203@oracle.com> Hi Peter, the fix looks good to me. You are right, client-libs related changes goes to client-libs repository[1] first. You don't need any sponsor since you are already a jdk9 committer. Thank you for filing and fixing this issue! [1] http://hg.openjdk.java.net/jdk9/client/jdk/ -- Thanks, Alexander. On 20.05.2015 11:00, Peter Levart wrote: > Hi Alexander, > > I filed the issue as: > > https://bugs.openjdk.java.net/browse/JDK-8080695 > > The proposed patch is this, which also fixes compile time error: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/splashscreen_png/webrev.02/ > > If this is OK, I can push it if the change can go via jdk9-dev > repository where I can commit. Is there a special repository for > client libs? Do I need a sponsor? > > Regards, Peter > > On 05/19/2015 03:59 PM, Alexander Zvegintsev wrote: >> Hi Peter, >> >> I think that your solution can be simplified to: >> >> diff -r 729dffc8afa0 >> src/java.desktop/share/native/libsplashscreen/splashscreen_png.c >> --- a/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c >> +++ b/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c >> @@ -77,6 +77,8 @@ SplashDecodePng(Splash * splash, png_rw_ >> #else >> if (setjmp(png_jmpbuf(png_ptr))) { >> #endif >> + row_pointers = NULL; >> + image_data = NULL; >> goto done; >> } >> >> As another solution you can declare row_pointers and image_data as >> volatile. >> >> BTW, Could you please file an issue? >> >> Thanks, >> >> Alexander. >> On 05/19/2015 01:50 PM, Peter Levart wrote: >>> Hi, >>> >>> I hope this is the right thread to post the observation. >>> >>> Building recent OpenJDK 9 from sources on Fedora 21 fails with this: >>> >>> /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c: >>> In function 'SplashDecodePng': >>> /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c:51:16: >>> error: variable 'row_pointers' might be clobbered by 'longjmp' or >>> 'vfork' [-Werror=clobbered] >>> png_bytepp row_pointers = NULL; >>> ^ >>> /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c:52:15: >>> error: variable 'image_data' might be clobbered by 'longjmp' or >>> 'vfork' [-Werror=clobbered] >>> png_bytep image_data = NULL; >>> ^ >>> cc1: all warnings being treated as errors >>> gmake[3]: *** >>> [/home/peter/work/hg/jdk9-dev/build/linux-x86_64-normal-server-release/support/native/java.desktop/libsplashscreen/splashscreen_png.o] >>> Error 1 >>> gmake[3]: *** Waiting for unfinished jobs.... >>> Awt2dLibraries.gmk:879: recipe for target >>> '/home/peter/work/hg/jdk9-dev/build/linux-x86_64-normal-server-release/support/native/java.desktop/libsplashscreen/splashscreen_png.o' >>> failed >>> gmake[2]: *** [java.desktop-libs] Error 1 >>> make/Main.gmk:168: recipe for target 'java.desktop-libs' failed >>> >>> >>> I found that making the following change eliminates the compiler error: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/splashscreen_png/webrev.01/ >>> >>> >>> Is this the right way to fix it? >>> >>> Regards, Peter >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.tarasov at oracle.com Wed May 20 12:34:40 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 20 May 2015 15:34:40 +0300 Subject: [9] Review request for 8003399: JFileChooser gives wrong path to selected file when saving to Libraries folder on Windows 7 In-Reply-To: <555B5A9F.3090207@oracle.com> References: <554B1EE4.1080001@oracle.com> <554B21C5.9020500@oracle.com> <554B5AA1.1080206@oracle.com> <554CAFD0.9030305@oracle.com> <554CC1A4.90107@oracle.com> <555B5A9F.3090207@oracle.com> Message-ID: <555C7F60.5040407@oracle.com> Hi Semyon, I'm fine with it, but don't you want to define a simple macro for this: + jfieldID field_guid = env->GetFieldID(cl, "guid", "Ljava/lang/String;"); + DASSERT(field_guid != NULL); + CHECK_NULL_RETURN(field_guid, NULL); To call it like: DEFINE_FIELD_ID(field_guid, cl, "guid", "Ljava/lang/String;"); You would reduce the code a lot and make it more readable. Regards, Anton. On 19.05.2015 18:45, Semyon Sadetsky wrote: > Hi Anton, > > here is an updated version: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.01/ > > --Semyon > > On 5/8/2015 5:01 PM, Semyon Sadetsky wrote: >> >> On 5/8/2015 3:45 PM, Sergey Bylokhov wrote: >>> On 07.05.15 15:29, Semyon Sadetsky wrote: >>>> Hi Sergey, >>>> >>>> Yes, after the fix filedialog produces usual filesystem paths for libraries which are readable >>>> for java.io. >>> Just to clarify: after the fix, both Open and Save dialog works? >> Open file in library was not a problem, because an exicting file has real FS path already. >> >>>> But there are no possibility to reference files in libraries directly using new File(>>> link>). >>>> >>>> --Semyon >>>> >>>> On 5/7/2015 11:26 AM, Sergey Bylokhov wrote: >>>>> Hi, Semyon. >>>>> Can you please raise the supportness of this in the java.io on the core-libs alias. >>>>> Does the open filedialog will work after the fix? >>>>> >>>>> On 07.05.15 11:14, Semyon Sadetsky wrote: >>>>>> Hello, >>>>>> >>>>>> Please review fix for JDK9. >>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8003399 >>>>>> >>>>>> ***THE ROOT CAUSE >>>>>> JDK uses legacy WINAPI special folders calls while MS introduced a new interfaces >>>>>> IKnownFolder and IShellLibrary to manage special folder locations and the new Libraries >>>>>> functionality in Windows 7 is not backward compatible with old special folders CSIDL. >>>>>> >>>>>> ***SOLUTION >>>>>> Since it is too expensive to migrate AWT shell to the new interfaces and still they are not >>>>>> supported in java.io the solution is to map virtual folder PIDL to the Known Folder GUID and >>>>>> replace libraries links with the default library save location. Thus the File save dialog >>>>>> will be able to work with any Libraries registered in the system (Windows Libraries concept >>>>>> assumes that Libraries can be added arbitrary). >>>>>> The resulting code should be compatible with older Windows versions because the new COM >>>>>> interfaces are called only if they are available and a Libraries link has been actually >>>>>> requested. >>>>>> >>>>>> ***TESTING >>>>>> A test scenario is added to check that all available Libraries links are converted into >>>>>> filesystem paths. >>>>>> >>>>>> --Semyon >>>>>> >>>>> >>>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Wed May 20 14:12:09 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 20 May 2015 17:12:09 +0300 Subject: [9] Review request for 8003399: JFileChooser gives wrong path to selected file when saving to Libraries folder on Windows 7 In-Reply-To: <555C7F60.5040407@oracle.com> References: <554B1EE4.1080001@oracle.com> <554B21C5.9020500@oracle.com> <554B5AA1.1080206@oracle.com> <554CAFD0.9030305@oracle.com> <554CC1A4.90107@oracle.com> <555B5A9F.3090207@oracle.com> <555C7F60.5040407@oracle.com> Message-ID: <555C9639.1080305@oracle.com> Hi Anton, http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.02/ I have added the macro you requested. --Semyon On 5/20/2015 3:34 PM, Anton V. Tarasov wrote: > Hi Semyon, > > I'm fine with it, but don't you want to define a simple macro for this: > > + jfieldID field_guid = env->GetFieldID(cl, "guid", "Ljava/lang/String;"); > + DASSERT(field_guid != NULL); > + CHECK_NULL_RETURN(field_guid, NULL); > > To call it like: > > DEFINE_FIELD_ID(field_guid, cl, "guid", "Ljava/lang/String;"); > > You would reduce the code a lot and make it more readable. > > Regards, > Anton. > > On 19.05.2015 18:45, Semyon Sadetsky wrote: >> Hi Anton, >> >> here is an updated version: >> http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.01/ >> >> --Semyon >> >> On 5/8/2015 5:01 PM, Semyon Sadetsky wrote: >>> >>> On 5/8/2015 3:45 PM, Sergey Bylokhov wrote: >>>> On 07.05.15 15:29, Semyon Sadetsky wrote: >>>>> Hi Sergey, >>>>> >>>>> Yes, after the fix filedialog produces usual filesystem paths for >>>>> libraries which are readable for java.io. >>>> Just to clarify: after the fix, both Open and Save dialog works? >>> Open file in library was not a problem, because an exicting file has >>> real FS path already. >>> >>>>> But there are no possibility to reference files in libraries >>>>> directly using new File(). >>>>> >>>>> --Semyon >>>>> >>>>> On 5/7/2015 11:26 AM, Sergey Bylokhov wrote: >>>>>> Hi, Semyon. >>>>>> Can you please raise the supportness of this in the java.io on >>>>>> the core-libs alias. >>>>>> Does the open filedialog will work after the fix? >>>>>> >>>>>> On 07.05.15 11:14, Semyon Sadetsky wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review fix for JDK9. >>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/ >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8003399 >>>>>>> >>>>>>> ***THE ROOT CAUSE >>>>>>> JDK uses legacy WINAPI special folders calls while MS introduced >>>>>>> a new interfaces IKnownFolder and IShellLibrary to manage >>>>>>> special folder locations and the new Libraries functionality in >>>>>>> Windows 7 is not backward compatible with old special folders >>>>>>> CSIDL. >>>>>>> >>>>>>> ***SOLUTION >>>>>>> Since it is too expensive to migrate AWT shell to the new >>>>>>> interfaces and still they are not supported in java.io the >>>>>>> solution is to map virtual folder PIDL to the Known Folder GUID >>>>>>> and replace libraries links with the default library save >>>>>>> location. Thus the File save dialog will be able to work with >>>>>>> any Libraries registered in the system (Windows Libraries >>>>>>> concept assumes that Libraries can be added arbitrary). >>>>>>> The resulting code should be compatible with older Windows >>>>>>> versions because the new COM interfaces are called only if they >>>>>>> are available and a Libraries link has been actually requested. >>>>>>> >>>>>>> ***TESTING >>>>>>> A test scenario is added to check that all available Libraries >>>>>>> links are converted into filesystem paths. >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Wed May 20 15:59:31 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 20 May 2015 18:59:31 +0300 Subject: [9] Review request for 8065739 [macosx] Frame warps to lower left of screen when displayed In-Reply-To: <5555D8F1.9000101@oracle.com> References: <5525410A.8080407@oracle.com> <552EC29D.3090706@oracle.com> <554100C2.6050902@oracle.com> <554CABEF.7030502@oracle.com> <554CAF39.8040409@oracle.com> <555203BC.2090604@oracle.com> <55546D89.7080704@oracle.com> <5555D8F1.9000101@oracle.com> Message-ID: <555CAF63.4090409@oracle.com> On 5/15/2015 2:30 PM, Sergey Bylokhov wrote: > Hi, Alexander. > A few notes: > - _peer.setMaximizedBounds(_peer.getMaximizedBounds()); this line > looks odd, probably we can call updateMaximizedBounds in LWWindowPeer. > initializeImpl()? > - Do we need to call maximize(); in the initialize() or we can leave > it in the setVisible()? It seems that after we set > NSWindowStandardFrame isZoomed should work properly in the callback? > - Why we cannot return DefaultMaximizedBounds from the > getMaximizedBounds if it was not set? Then it will not be necessary to > check it to null everywhere. > - Can we call updateMaximizedBounds(); in > LWWindowPeer.displayChanged() only in case of new device? > Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8065739/webrev.05 The fix has been updated according to the comments. Thanks, Alexandr. > On 14.05.15 12:40, Alexander Scherbatiy wrote: >> On 5/12/2015 4:44 PM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> - maximized bounds are updated after switching to new screen if they >>> are not set by a user >>> - the test for the maximized window moved from one screen to another >>> is added >> Sorry. Just forgot to add the webrev link: >> http://cr.openjdk.java.net/~alexsch/8065739/webrev.04/ >> >> Thanks, >> Alexandr. >> >>> >>> >>> Thanks, >>> Alexandr. >>> >>> On 5/8/2015 3:42 PM, Sergey Bylokhov wrote: >>>> Hi, Alexander. >>>> Does the new tests cover all corner cases which we discussed offline? >>>> >>>> On 08.05.15 15:28, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.03 >>>>> >>>>> - The -windowWillUseStandardFrame:defaultFrame: method is >>>>> implemented in AWTWindow to correctly get and check a size of the >>>>> maximized window. >>>>> After that the -isZoomed method correctly defines the zoomed >>>>> state for both visible and not visible window. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 4/29/2015 7:03 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.02 >>>>>> >>>>>> - the zoom state is applied after NSWindow creation if Frame >>>>>> has MAXIMIZED_BOTH state. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 4/15/2015 10:57 PM, Sergey Bylokhov wrote: >>>>>>> Hi, Alexander. >>>>>>> As far as I understand the main issue is that we get a native >>>>>>> notifications during window initialization(after nswindows was >>>>>>> created and before zoom method will be called)? Probably we can >>>>>>> apply the zoom state when we create a window in one appkit call? >>>>>>> >>>>>>> On 08.04.15 17:54, Alexander Scherbatiy wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the fix: >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8065739 >>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8065739/webrev.00 >>>>>>>> >>>>>>>> Use case: >>>>>>>> ------------ >>>>>>>> Frame frame = new Frame(); >>>>>>>> frame.pack(); >>>>>>>> frame.setBounds(screenBounds); >>>>>>>> frame.setVisible(true); >>>>>>>> ------------ >>>>>>>> >>>>>>>> The frame is in the normal state but Mac OS X treats a frame >>>>>>>> with screen bounds as zoomed. >>>>>>>> The setVisible() method calls unmaximize() method to return >>>>>>>> the zoomed window to the normal state. >>>>>>>> The native zoom() method sets the initial sizes for the >>>>>>>> window which are zero because of the pack() call. >>>>>>>> >>>>>>>> >>>>>>>> There is already checkZoom() method which synchronizes native >>>>>>>> window zoom state and and the frame extended state when a frame >>>>>>>> is resized by mouse. >>>>>>>> However it can't be always used for the synchronization >>>>>>>> between native window zoom state and setBounds() call because >>>>>>>> of the following case: >>>>>>>> >>>>>>>> ----------------- >>>>>>>> Frame frame = new Frame(); >>>>>>>> frame.setBounds(smallBounds); >>>>>>>> frame.setExtendedState(Frame.MAXIMIZED_BOTH); >>>>>>>> frame.setVisible(true); >>>>>>>> ----------------- >>>>>>>> >>>>>>>> This is the valid scenario where the frame should be maximized. >>>>>>>> >>>>>>>> The solution synchronizes the zoom and the frame state only >>>>>>>> when the native window is zoomed. >>>>>>>> In opposite case we need to return from the zoomed sizes to >>>>>>>> previous sizes which are the same as for the zoomed window. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > > > -- > Best regards, Sergey. From pooja.chopra at oracle.com Wed May 20 17:54:13 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Wed, 20 May 2015 23:24:13 +0530 Subject: [9] Review Request: JDK-8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in WindowsClassicLookAndFeel In-Reply-To: <5548C2A6.5070207@oracle.com> References: <554292E6.7080608@oracle.com> <5548C2A6.5070207@oracle.com> Message-ID: <555CCA45.7090202@oracle.com> Hi All, Please review the updated webrev link as per discussion with Alexey as below for the fix :- Please review a fix for issue: 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in WindowsClassicLookAndFeel Test bug fix. https://bugs.openjdk.java.net/browse/JDK-8078855 The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.01 Regards, Pooja On 5/5/2015 6:46 PM, Alexey Ivanov wrote: > Hello Pooja, > > The modified test case does not reproduce the problem reported in > https://bugs.openjdk.java.net/browse/JDK-8032878. So this fix cannot > be applied to the regression test. > > I confirm that the original test fails in WindowsClassicLookAndFeel > because the editor selects the text, thus the typed text '123' is not > added to existing text but replaces it. It could be a bug in > WindowsClassicLookAndFeel or its feature. If it's not a bug, then the > test should expect the value of "123" rather than "one123" where > WindowsClassicLookAndFeel is used. > > Regards, > Alexey > > On 30.04.2015 23:39, pooja chopra wrote: >> Hello, >> Please review a fix for issue: >> 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java >> fails in WindowsClassicLookAndFeel >> Test bug fix. >> https://bugs.openjdk.java.net/browse/JDK-8078855 >> The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.00/ >> >> Thanks, >> Pooja > From peter.brunet at oracle.com Thu May 21 05:33:50 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 21 May 2015 00:33:50 -0500 Subject: RfR JDK-8077296 RE build fails on non-Win builds when attempting to build Win only javadoc Message-ID: <555D6E3E.5030806@oracle.com> Please review the following change for 8u: http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/ Background: - As part of the open sourcing of the JAB and Java Accessibility Utilities (JAU) the JAU Javadoc was setup to be added to the build. - Due to a 8u build issue (it uses source bundles) the Javadoc had to be temporarily disabled: JDK-8076552 - The issue was caused by JAU code being in windows instead of share. - For 9 the JAU code is in jdk.accessibility/share/classes/com/sun/java/accessibility/util (and the JAB code under jdk.accessibility/windows). - For 8u both the JAU and JAB code is in jdk/src/windows. - The problem on 8u is with non-windows builds; the 8 Javadoc build process doesn't find the JAU files because they are in a windows directory. - The fix is to refactor so 8u is like 9 with the JAU files in share; then the javadoc build process will find the source for all build platforms. - Make has been changed so jaccess.jar is built for all platforms - Some obsolete files have been removed as they were causing build problems. They were removed from 9 earlier but not from 8u. These are com/sun/java/accessibility/util/java/awt/ChoiceTranslator.java and all the files in com/sun/java/accessibility/extensions. Thanks, Pete From erik.joelsson at oracle.com Thu May 21 07:11:00 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 May 2015 09:11:00 +0200 Subject: RfR JDK-8077296 RE build fails on non-Win builds when attempting to build Win only javadoc In-Reply-To: <555D6E3E.5030806@oracle.com> References: <555D6E3E.5030806@oracle.com> Message-ID: <555D8504.2030800@oracle.com> Hello Pete, This looks good to me. /Erik On 2015-05-21 07:33, Pete Brunet wrote: > Please review the following change for 8u: > http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/ > > Background: > > - As part of the open sourcing of the JAB and Java Accessibility > Utilities (JAU) the JAU Javadoc was setup to be added to the build. > - Due to a 8u build issue (it uses source bundles) the Javadoc had to be > temporarily disabled: JDK-8076552 > - The issue was caused by JAU code being in windows instead of share. > - For 9 the JAU code is in > jdk.accessibility/share/classes/com/sun/java/accessibility/util (and the > JAB code under jdk.accessibility/windows). > - For 8u both the JAU and JAB code is in jdk/src/windows. > - The problem on 8u is with non-windows builds; the 8 Javadoc build > process doesn't find the JAU files because they are in a windows directory. > - The fix is to refactor so 8u is like 9 with the JAU files in share; > then the javadoc build process will find the source for all build platforms. > - Make has been changed so jaccess.jar is built for all platforms > - Some obsolete files have been removed as they were causing build > problems. They were removed from 9 earlier but not from 8u. These are > com/sun/java/accessibility/util/java/awt/ChoiceTranslator.java and all > the files in com/sun/java/accessibility/extensions. > > Thanks, Pete From alexandr.scherbatiy at oracle.com Thu May 21 09:17:13 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 21 May 2015 12:17:13 +0300 Subject: [9] Review Request: JDK-8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in WindowsClassicLookAndFeel In-Reply-To: <555CCA45.7090202@oracle.com> References: <554292E6.7080608@oracle.com> <5548C2A6.5070207@oracle.com> <555CCA45.7090202@oracle.com> Message-ID: <555DA299.7020503@oracle.com> The fix looks good to me. Thanks, Alexandr. On 5/20/2015 8:54 PM, pooja chopra wrote: > Hi All, > > Please review the updated webrev link as per discussion with Alexey as > below for the fix :- > > Please review a fix for issue: > 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails > in WindowsClassicLookAndFeel > Test bug fix. > https://bugs.openjdk.java.net/browse/JDK-8078855 > The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.01 > > Regards, > Pooja > > On 5/5/2015 6:46 PM, Alexey Ivanov wrote: >> Hello Pooja, >> >> The modified test case does not reproduce the problem reported in >> https://bugs.openjdk.java.net/browse/JDK-8032878. So this fix cannot >> be applied to the regression test. >> >> I confirm that the original test fails in WindowsClassicLookAndFeel >> because the editor selects the text, thus the typed text '123' is not >> added to existing text but replaces it. It could be a bug in >> WindowsClassicLookAndFeel or its feature. If it's not a bug, then the >> test should expect the value of "123" rather than "one123" where >> WindowsClassicLookAndFeel is used. >> >> Regards, >> Alexey >> >> On 30.04.2015 23:39, pooja chopra wrote: >>> Hello, >>> Please review a fix for issue: >>> 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java >>> fails in WindowsClassicLookAndFeel >>> Test bug fix. >>> https://bugs.openjdk.java.net/browse/JDK-8078855 >>> The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.00/ >>> >>> Thanks, >>> Pooja >> > From Sergey.Bylokhov at oracle.com Thu May 21 12:11:46 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 21 May 2015 15:11:46 +0300 Subject: [9] Review Request: 8041654 OutOfMemoryError: RepainManager doesn't clean up cache of volatile images Message-ID: <555DCB82.5070900@oracle.com> Hello. Please review the fix for jdk9. RepainManager adds a listener to the SGE.DisplayChangedListener() and it don't hold a strong reference to this listener. The problem is that SGE holds a listeners in the WeakHashMap so sometimes the listeners can be cleared before they are called. Same issue exists in XToolkit. Bug: https://bugs.openjdk.java.net/browse/JDK-8041654 Webrev can be found at: http://cr.openjdk.java.net/~serb/8041654/webrev.02 -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu May 21 12:18:13 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 21 May 2015 15:18:13 +0300 Subject: [9] Review request for 8065739 [macosx] Frame warps to lower left of screen when displayed In-Reply-To: <555CAF63.4090409@oracle.com> References: <5525410A.8080407@oracle.com> <552EC29D.3090706@oracle.com> <554100C2.6050902@oracle.com> <554CABEF.7030502@oracle.com> <554CAF39.8040409@oracle.com> <555203BC.2090604@oracle.com> <55546D89.7080704@oracle.com> <5555D8F1.9000101@oracle.com> <555CAF63.4090409@oracle.com> Message-ID: <555DCD05.1020005@oracle.com> Hi, Alexander. The fix looks fine. On 20.05.15 18:59, Alexander Scherbatiy wrote: > > On 5/15/2015 2:30 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> A few notes: >> - _peer.setMaximizedBounds(_peer.getMaximizedBounds()); this line >> looks odd, probably we can call updateMaximizedBounds in >> LWWindowPeer. initializeImpl()? >> - Do we need to call maximize(); in the initialize() or we can leave >> it in the setVisible()? It seems that after we set >> NSWindowStandardFrame isZoomed should work properly in the callback? >> - Why we cannot return DefaultMaximizedBounds from the >> getMaximizedBounds if it was not set? Then it will not be necessary >> to check it to null everywhere. >> - Can we call updateMaximizedBounds(); in >> LWWindowPeer.displayChanged() only in case of new device? >> > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8065739/webrev.05 > > The fix has been updated according to the comments. > > Thanks, > Alexandr. >> On 14.05.15 12:40, Alexander Scherbatiy wrote: >>> On 5/12/2015 4:44 PM, Alexander Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> - maximized bounds are updated after switching to new screen if >>>> they are not set by a user >>>> - the test for the maximized window moved from one screen to >>>> another is added >>> Sorry. Just forgot to add the webrev link: >>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.04/ >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 5/8/2015 3:42 PM, Sergey Bylokhov wrote: >>>>> Hi, Alexander. >>>>> Does the new tests cover all corner cases which we discussed offline? >>>>> >>>>> On 08.05.15 15:28, Alexander Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.03 >>>>>> >>>>>> - The -windowWillUseStandardFrame:defaultFrame: method is >>>>>> implemented in AWTWindow to correctly get and check a size of the >>>>>> maximized window. >>>>>> After that the -isZoomed method correctly defines the zoomed >>>>>> state for both visible and not visible window. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 4/29/2015 7:03 PM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the updated fix: >>>>>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.02 >>>>>>> >>>>>>> - the zoom state is applied after NSWindow creation if Frame >>>>>>> has MAXIMIZED_BOTH state. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 4/15/2015 10:57 PM, Sergey Bylokhov wrote: >>>>>>>> Hi, Alexander. >>>>>>>> As far as I understand the main issue is that we get a native >>>>>>>> notifications during window initialization(after nswindows was >>>>>>>> created and before zoom method will be called)? Probably we can >>>>>>>> apply the zoom state when we create a window in one appkit call? >>>>>>>> >>>>>>>> On 08.04.15 17:54, Alexander Scherbatiy wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the fix: >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8065739 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8065739/webrev.00 >>>>>>>>> >>>>>>>>> Use case: >>>>>>>>> ------------ >>>>>>>>> Frame frame = new Frame(); >>>>>>>>> frame.pack(); >>>>>>>>> frame.setBounds(screenBounds); >>>>>>>>> frame.setVisible(true); >>>>>>>>> ------------ >>>>>>>>> >>>>>>>>> The frame is in the normal state but Mac OS X treats a frame >>>>>>>>> with screen bounds as zoomed. >>>>>>>>> The setVisible() method calls unmaximize() method to return >>>>>>>>> the zoomed window to the normal state. >>>>>>>>> The native zoom() method sets the initial sizes for the >>>>>>>>> window which are zero because of the pack() call. >>>>>>>>> >>>>>>>>> >>>>>>>>> There is already checkZoom() method which synchronizes >>>>>>>>> native window zoom state and and the frame extended state when >>>>>>>>> a frame is resized by mouse. >>>>>>>>> However it can't be always used for the synchronization >>>>>>>>> between native window zoom state and setBounds() call because >>>>>>>>> of the following case: >>>>>>>>> >>>>>>>>> ----------------- >>>>>>>>> Frame frame = new Frame(); >>>>>>>>> frame.setBounds(smallBounds); >>>>>>>>> frame.setExtendedState(Frame.MAXIMIZED_BOTH); >>>>>>>>> frame.setVisible(true); >>>>>>>>> ----------------- >>>>>>>>> >>>>>>>>> This is the valid scenario where the frame should be maximized. >>>>>>>>> >>>>>>>>> The solution synchronizes the zoom and the frame state only >>>>>>>>> when the native window is zoomed. >>>>>>>>> In opposite case we need to return from the zoomed sizes to >>>>>>>>> previous sizes which are the same as for the zoomed window. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu May 21 13:29:31 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 21 May 2015 16:29:31 +0300 Subject: [9] Review Request: 8071306 GUI perfomance are very slow compared java 1.6.0_45 In-Reply-To: <5559AACB.4020701@oracle.com> References: <554AB431.1040707@oracle.com> <554C8093.50205@oracle.com> <554D57A6.40202@oracle.com> <5551E93C.2010807@oracle.com> <55552866.1070407@oracle.com> <5559AACB.4020701@oracle.com> Message-ID: <555DDDBB.8040700@oracle.com> Hello, Any volunteers to be a second reviewer? On 18.05.15 12:03, Anton V. Tarasov wrote: > On 15.05.2015 1:57, Sergey Bylokhov wrote: >> Hi, Anton. >>> + * Determines the bounds of a visible part of the component relative to its >>> + * parents. >>> Did you mean "to its parent"? >> Yep, new version: >> http://cr.openjdk.java.net/~serb/8071306/webrev.05/ > > Looks good to me. > > Regards, > Anton. > > >>> >>>>> >>>>> 2. >>>>> >>>>> 100 * The components in this container. >>>>> 101 * @see #add >>>>> 102 * @see #getComponents >>>>> 103 */ >>>>> 104 private java.util.List component = new >>>>> ArrayList<>(); >>>>> >>>>> May be it's worth to rename the field? The "component" name is odd... >>>> I suppose it wasn't changed, because this name is used in the >>>> serialization for a long time. Plus there are a bunch of the >>>> similar vars like: tmpComponent etc. I can do it later for jdk9 only. >>> >>> Ok, thanks. It's up to you. >>> >>> Regards, >>> Anton. >>> >>>>> >>>>> Regards, >>>>> Anton. >>>>> >>>>> On 07.05.2015 3:39, Sergey Bylokhov wrote: >>>>>> Hello. >>>>>> Please review the fix for a jdk9. I plan to backport it to jdk8u60. >>>>>> >>>>>> Description. >>>>>> An UIworks really slowly, when an application has a lot of >>>>>> components in one container, and these components should be >>>>>> disabled one by one. >>>>>> The reason is the next sequence of methods calls: >>>>>> Component.setEnabled->updateCursorImmediately()-> some cursor >>>>>> related >>>>>> staff->GlobalCursorManager._updateCursor->Container.findComponentAt()-iteration >>>>>> over all components in the container.....-> twice.... >>>>>> >>>>>> You can imagine how it works in case of 10000 components in the >>>>>> container. >>>>>> >>>>>> Note that in the bug report described difference jdk6 vs jdk8 -> >>>>>> 1sec vs 6 sec. This was caused by the two fixes, one of which >>>>>> adds checkTreeLock() and in another one a simple array of >>>>>> components was replaced by the ArrayList. Since code was added to >>>>>> the really hot method we got so big slowdown. >>>>>> >>>>>> To fix the problem I suggest two different approaches: >>>>>> - Container.java: Fix a general case, by eliminating a second >>>>>> iteration in the hot loop. >>>>>> - Component.java: Totally eliminates cursor machinery, if >>>>>> component cannot affect current cursor. >>>>>> >>>>>> Some speedup measurements on my local system: >>>>>> - Simple removing of checkTreeLock() will partly solve a >>>>>> regression reported by the user(12 sec -> 5 sec). >>>>>> - Changes in the loop will speedup the code in the worse >>>>>> case(5->2 sec) >>>>>> - The changes in the Component.java will change the performance >>>>>> from 2 sec to 100< ms >>>>>> >>>>>> Test case which was added was improved from 10 seconds to 80 ms. >>>>>> >>>>>> JMH test: >>>>>> http://cr.openjdk.java.net/~serb/8071306/SetEnabledPerformanceTest.java >>>>>> >>>>>> Fixedversion: >>>>>> >>>>>> Benchmark Mode Cnt Score Error Units >>>>>> SetEnabledPerformanceTest.testContains thrpt 5 301300,813 ? >>>>>> 17338,045 ops/ms >>>>>> SetEnabledPerformanceTest.testFindComponentAt thrpt 5 >>>>>> 20,521 ? 0,269 ops/ms >>>>>> SetEnabledPerformanceTest.testGetComponentAt thrpt 5 >>>>>> 22,297 ? 1,264 ops/ms >>>>>> SetEnabledPerformanceTest.testSetEnabled thrpt 5 711,120 >>>>>> ? 19,837 ops/ms >>>>>> >>>>>> Base version: >>>>>> >>>>>> Benchmark Mode Cnt Score Error Units >>>>>> SetEnabledPerformanceTest.testContains thrpt 5 299145,642 ? >>>>>> 2120,183 ops/ms >>>>>> SetEnabledPerformanceTest.testFindComponentAt thrpt 5 >>>>>> 1,101 ? 0,012 ops/ms >>>>>> SetEnabledPerformanceTest.testGetComponentAt thrpt 5 >>>>>> 6,792 ? 0,097 ops/ms >>>>>> SetEnabledPerformanceTest.testSetEnabled thrpt 5 0,464 >>>>>> ? 0,020 ops/ms >>>>>> >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071306 >>>>>> Webrev can be found at: >>>>>> http://cr.openjdk.java.net/~serb/8071306/webrev.03 >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu May 21 13:58:58 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 21 May 2015 16:58:58 +0300 Subject: [9] Review request for 8080137 Dragged events for extra mouse buttons (4, 5, 6) are not generated on JSplitPane In-Reply-To: <555B442B.3010402@oracle.com> References: <555B0C12.8060706@oracle.com> <555B434D.3080501@oracle.com> <555B442B.3010402@oracle.com> Message-ID: <555DE4A2.6090909@oracle.com> Looks fine to me too. On 19.05.15 17:09, Alexander Zvegintsev wrote: > Hello Alexandr, > > the fix looks fine to me. > > Thanks, > > Alexander. > > On 05/19/2015 05:06 PM, Alexander Scherbatiy wrote: >> >> The test fails on Linux because Xsystem does not set state for >> motion events when extra button is pressed. >> >> I have filled the issue on it: JDK-8080676 Mouse drag does not work >> for extra buttons on Linux >> https://bugs.openjdk.java.net/browse/JDK-8080676 >> >> Thanks, >> Alexandr. >> >> On 5/19/2015 1:10 PM, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8080137 >>> webrev: http://cr.openjdk.java.net/~alexsch/8080137/webrev.00 >>> >>> The LightweightDispatcher.isMouseGrab(MouseEvent) method does not >>> take into account the extended modifiers for additional buttons. >>> >>> >>> Thanks, >>> Alexandr. >>> >> > -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Thu May 21 14:13:08 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 21 May 2015 17:13:08 +0300 Subject: [9] Review Request: 8071306 GUI perfomance are very slow compared java 1.6.0_45 In-Reply-To: <555DDDBB.8040700@oracle.com> References: <554AB431.1040707@oracle.com> <554C8093.50205@oracle.com> <554D57A6.40202@oracle.com> <5551E93C.2010807@oracle.com> <55552866.1070407@oracle.com> <5559AACB.4020701@oracle.com> <555DDDBB.8040700@oracle.com> Message-ID: <555DE7F4.5010707@oracle.com> Hi Sergey, the fix looks good to me too. -- Thanks, Alexander. On 05/21/2015 04:29 PM, Sergey Bylokhov wrote: > Hello, > Any volunteers to be a second reviewer? > > On 18.05.15 12:03, Anton V. Tarasov wrote: >> On 15.05.2015 1:57, Sergey Bylokhov wrote: >>> Hi, Anton. >>>> + * Determines the bounds of a visible part of the component relative to its >>>> + * parents. >>>> Did you mean "to its parent"? >>> Yep, new version: >>> http://cr.openjdk.java.net/~serb/8071306/webrev.05/ >> >> Looks good to me. >> >> Regards, >> Anton. >> >> >>>> >>>>>> >>>>>> 2. >>>>>> >>>>>> 100 * The components in this container. >>>>>> 101 * @see #add >>>>>> 102 * @see #getComponents >>>>>> 103 */ >>>>>> 104 private java.util.List component = new >>>>>> ArrayList<>(); >>>>>> >>>>>> May be it's worth to rename the field? The "component" name is odd... >>>>> I suppose it wasn't changed, because this name is used in the >>>>> serialization for a long time. Plus there are a bunch of the >>>>> similar vars like: tmpComponent etc. I can do it later for jdk9 only. >>>> >>>> Ok, thanks. It's up to you. >>>> >>>> Regards, >>>> Anton. >>>> >>>>>> >>>>>> Regards, >>>>>> Anton. >>>>>> >>>>>> On 07.05.2015 3:39, Sergey Bylokhov wrote: >>>>>>> Hello. >>>>>>> Please review the fix for a jdk9. I plan to backport it to jdk8u60. >>>>>>> >>>>>>> Description. >>>>>>> An UIworks really slowly, when an application has a lot of >>>>>>> components in one container, and these components should be >>>>>>> disabled one by one. >>>>>>> The reason is the next sequence of methods calls: >>>>>>> Component.setEnabled->updateCursorImmediately()-> some cursor >>>>>>> related >>>>>>> staff->GlobalCursorManager._updateCursor->Container.findComponentAt()-iteration >>>>>>> over all components in the container.....-> twice.... >>>>>>> >>>>>>> You can imagine how it works in case of 10000 components in the >>>>>>> container. >>>>>>> >>>>>>> Note that in the bug report described difference jdk6 vs jdk8 -> >>>>>>> 1sec vs 6 sec. This was caused by the two fixes, one of which >>>>>>> adds checkTreeLock() and in another one a simple array of >>>>>>> components was replaced by the ArrayList. Since code was added >>>>>>> to the really hot method we got so big slowdown. >>>>>>> >>>>>>> To fix the problem I suggest two different approaches: >>>>>>> - Container.java: Fix a general case, by eliminating a second >>>>>>> iteration in the hot loop. >>>>>>> - Component.java: Totally eliminates cursor machinery, if >>>>>>> component cannot affect current cursor. >>>>>>> >>>>>>> Some speedup measurements on my local system: >>>>>>> - Simple removing of checkTreeLock() will partly solve a >>>>>>> regression reported by the user(12 sec -> 5 sec). >>>>>>> - Changes in the loop will speedup the code in the worse >>>>>>> case(5->2 sec) >>>>>>> - The changes in the Component.java will change the performance >>>>>>> from 2 sec to 100< ms >>>>>>> >>>>>>> Test case which was added was improved from 10 seconds to 80 ms. >>>>>>> >>>>>>> JMH test: >>>>>>> http://cr.openjdk.java.net/~serb/8071306/SetEnabledPerformanceTest.java >>>>>>> >>>>>>> Fixedversion: >>>>>>> >>>>>>> Benchmark Mode Cnt Score Error Units >>>>>>> SetEnabledPerformanceTest.testContains thrpt 5 301300,813 ? >>>>>>> 17338,045 ops/ms >>>>>>> SetEnabledPerformanceTest.testFindComponentAt thrpt 5 >>>>>>> 20,521 ? 0,269 ops/ms >>>>>>> SetEnabledPerformanceTest.testGetComponentAt thrpt 5 >>>>>>> 22,297 ? 1,264 ops/ms >>>>>>> SetEnabledPerformanceTest.testSetEnabled thrpt 5 711,120 >>>>>>> ? 19,837 ops/ms >>>>>>> >>>>>>> Base version: >>>>>>> >>>>>>> Benchmark Mode Cnt Score Error Units >>>>>>> SetEnabledPerformanceTest.testContains thrpt 5 299145,642 ? >>>>>>> 2120,183 ops/ms >>>>>>> SetEnabledPerformanceTest.testFindComponentAt thrpt 5 >>>>>>> 1,101 ? 0,012 ops/ms >>>>>>> SetEnabledPerformanceTest.testGetComponentAt thrpt 5 >>>>>>> 6,792 ? 0,097 ops/ms >>>>>>> SetEnabledPerformanceTest.testSetEnabled thrpt 5 0,464 >>>>>>> ? 0,020 ops/ms >>>>>>> >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8071306 >>>>>>> Webrev can be found at: >>>>>>> http://cr.openjdk.java.net/~serb/8071306/webrev.03 >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Thu May 21 14:31:25 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 21 May 2015 17:31:25 +0300 Subject: [9] Review Request: 8041654 OutOfMemoryError: RepainManager doesn't clean up cache of volatile images In-Reply-To: <555DCB82.5070900@oracle.com> References: <555DCB82.5070900@oracle.com> Message-ID: <555DEC3D.3030409@oracle.com> Hello Sergey, the fix looks fine to me. -- Thanks, Alexander. On 05/21/2015 03:11 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > RepainManager adds a listener to the SGE.DisplayChangedListener() and > it don't hold a strong reference to this listener. The problem is that > SGE holds a listeners in the WeakHashMap so sometimes the listeners > can be cleared before they are called. Same issue exists in XToolkit. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8041654 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8041654/webrev.02 > From anton.tarasov at oracle.com Thu May 21 15:15:06 2015 From: anton.tarasov at oracle.com (Anton Tarasov) Date: Thu, 21 May 2015 18:15:06 +0300 Subject: [9] Review request for 8003399: JFileChooser gives wrong path to selected file when saving to Libraries folder on Windows 7 In-Reply-To: <555C9639.1080305@oracle.com> References: <554B1EE4.1080001@oracle.com> <554B21C5.9020500@oracle.com> <554B5AA1.1080206@oracle.com> <554CAFD0.9030305@oracle.com> <554CC1A4.90107@oracle.com> <555B5A9F.3090207@oracle.com> <555C7F60.5040407@oracle.com> <555C9639.1080305@oracle.com> Message-ID: <555DF67A.7090809@oracle.com> So, it looks fine to me now. Thanks. Anton. On 20/05/15 17:12, Semyon Sadetsky wrote: > Hi Anton, > > http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.02/ > I have added the macro you requested. > > --Semyon > > On 5/20/2015 3:34 PM, Anton V. Tarasov wrote: >> Hi Semyon, >> >> I'm fine with it, but don't you want to define a simple macro for this: >> >> + jfieldID field_guid = env->GetFieldID(cl, "guid", "Ljava/lang/String;"); >> + DASSERT(field_guid != NULL); >> + CHECK_NULL_RETURN(field_guid, NULL); >> >> To call it like: >> >> DEFINE_FIELD_ID(field_guid, cl, "guid", "Ljava/lang/String;"); >> >> You would reduce the code a lot and make it more readable. >> >> Regards, >> Anton. >> >> On 19.05.2015 18:45, Semyon Sadetsky wrote: >>> Hi Anton, >>> >>> here is an updated version: >>> http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.01/ >>> >>> --Semyon >>> >>> On 5/8/2015 5:01 PM, Semyon Sadetsky wrote: >>>> >>>> On 5/8/2015 3:45 PM, Sergey Bylokhov wrote: >>>>> On 07.05.15 15:29, Semyon Sadetsky wrote: >>>>>> Hi Sergey, >>>>>> >>>>>> Yes, after the fix filedialog produces usual filesystem paths for >>>>>> libraries which are readable for java.io. >>>>> Just to clarify: after the fix, both Open and Save dialog works? >>>> Open file in library was not a problem, because an exicting file >>>> has real FS path already. >>>> >>>>>> But there are no possibility to reference files in libraries >>>>>> directly using new File(). >>>>>> >>>>>> --Semyon >>>>>> >>>>>> On 5/7/2015 11:26 AM, Sergey Bylokhov wrote: >>>>>>> Hi, Semyon. >>>>>>> Can you please raise the supportness of this in the java.io on >>>>>>> the core-libs alias. >>>>>>> Does the open filedialog will work after the fix? >>>>>>> >>>>>>> On 07.05.15 11:14, Semyon Sadetsky wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review fix for JDK9. >>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/ >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8003399 >>>>>>>> >>>>>>>> ***THE ROOT CAUSE >>>>>>>> JDK uses legacy WINAPI special folders calls while MS >>>>>>>> introduced a new interfaces IKnownFolder and IShellLibrary to >>>>>>>> manage special folder locations and the new Libraries >>>>>>>> functionality in Windows 7 is not backward compatible with old >>>>>>>> special folders CSIDL. >>>>>>>> >>>>>>>> ***SOLUTION >>>>>>>> Since it is too expensive to migrate AWT shell to the new >>>>>>>> interfaces and still they are not supported in java.io the >>>>>>>> solution is to map virtual folder PIDL to the Known Folder GUID >>>>>>>> and replace libraries links with the default library save >>>>>>>> location. Thus the File save dialog will be able to work with >>>>>>>> any Libraries registered in the system (Windows Libraries >>>>>>>> concept assumes that Libraries can be added arbitrary). >>>>>>>> The resulting code should be compatible with older Windows >>>>>>>> versions because the new COM interfaces are called only if they >>>>>>>> are available and a Libraries link has been actually requested. >>>>>>>> >>>>>>>> ***TESTING >>>>>>>> A test scenario is added to check that all available Libraries >>>>>>>> links are converted into filesystem paths. >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Thu May 21 15:24:26 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 21 May 2015 18:24:26 +0300 Subject: [9] Review request for 8065739 [macosx] Frame warps to lower left of screen when displayed In-Reply-To: <555DCD05.1020005@oracle.com> References: <5525410A.8080407@oracle.com> <552EC29D.3090706@oracle.com> <554100C2.6050902@oracle.com> <554CABEF.7030502@oracle.com> <554CAF39.8040409@oracle.com> <555203BC.2090604@oracle.com> <55546D89.7080704@oracle.com> <5555D8F1.9000101@oracle.com> <555CAF63.4090409@oracle.com> <555DCD05.1020005@oracle.com> Message-ID: <555DF8AA.9060908@oracle.com> Hi Alexandr, the fix looks fine to me too. -- Thanks, Alexander. On 21.05.2015 15:18, Sergey Bylokhov wrote: > Hi, Alexander. > The fix looks fine. > > On 20.05.15 18:59, Alexander Scherbatiy wrote: >> >> On 5/15/2015 2:30 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> A few notes: >>> - _peer.setMaximizedBounds(_peer.getMaximizedBounds()); this line >>> looks odd, probably we can call updateMaximizedBounds in >>> LWWindowPeer. initializeImpl()? >>> - Do we need to call maximize(); in the initialize() or we can >>> leave it in the setVisible()? It seems that after we set >>> NSWindowStandardFrame isZoomed should work properly in the callback? >>> - Why we cannot return DefaultMaximizedBounds from the >>> getMaximizedBounds if it was not set? Then it will not be necessary >>> to check it to null everywhere. >>> - Can we call updateMaximizedBounds(); in >>> LWWindowPeer.displayChanged() only in case of new device? >>> >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8065739/webrev.05 >> >> The fix has been updated according to the comments. >> >> Thanks, >> Alexandr. >>> On 14.05.15 12:40, Alexander Scherbatiy wrote: >>>> On 5/12/2015 4:44 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Could you review the updated fix: >>>>> - maximized bounds are updated after switching to new screen if >>>>> they are not set by a user >>>>> - the test for the maximized window moved from one screen to >>>>> another is added >>>> Sorry. Just forgot to add the webrev link: >>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.04/ >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 5/8/2015 3:42 PM, Sergey Bylokhov wrote: >>>>>> Hi, Alexander. >>>>>> Does the new tests cover all corner cases which we discussed >>>>>> offline? >>>>>> >>>>>> On 08.05.15 15:28, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the updated fix: >>>>>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.03 >>>>>>> >>>>>>> - The -windowWillUseStandardFrame:defaultFrame: method is >>>>>>> implemented in AWTWindow to correctly get and check a size of >>>>>>> the maximized window. >>>>>>> After that the -isZoomed method correctly defines the zoomed >>>>>>> state for both visible and not visible window. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 4/29/2015 7:03 PM, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the updated fix: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.02 >>>>>>>> >>>>>>>> - the zoom state is applied after NSWindow creation if Frame >>>>>>>> has MAXIMIZED_BOTH state. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 4/15/2015 10:57 PM, Sergey Bylokhov wrote: >>>>>>>>> Hi, Alexander. >>>>>>>>> As far as I understand the main issue is that we get a native >>>>>>>>> notifications during window initialization(after nswindows was >>>>>>>>> created and before zoom method will be called)? Probably we >>>>>>>>> can apply the zoom state when we create a window in one appkit >>>>>>>>> call? >>>>>>>>> >>>>>>>>> On 08.04.15 17:54, Alexander Scherbatiy wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Could you review the fix: >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8065739 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8065739/webrev.00 >>>>>>>>>> >>>>>>>>>> Use case: >>>>>>>>>> ------------ >>>>>>>>>> Frame frame = new Frame(); >>>>>>>>>> frame.pack(); >>>>>>>>>> frame.setBounds(screenBounds); >>>>>>>>>> frame.setVisible(true); >>>>>>>>>> ------------ >>>>>>>>>> >>>>>>>>>> The frame is in the normal state but Mac OS X treats a >>>>>>>>>> frame with screen bounds as zoomed. >>>>>>>>>> The setVisible() method calls unmaximize() method to return >>>>>>>>>> the zoomed window to the normal state. >>>>>>>>>> The native zoom() method sets the initial sizes for the >>>>>>>>>> window which are zero because of the pack() call. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> There is already checkZoom() method which synchronizes >>>>>>>>>> native window zoom state and and the frame extended state >>>>>>>>>> when a frame is resized by mouse. >>>>>>>>>> However it can't be always used for the synchronization >>>>>>>>>> between native window zoom state and setBounds() call because >>>>>>>>>> of the following case: >>>>>>>>>> >>>>>>>>>> ----------------- >>>>>>>>>> Frame frame = new Frame(); >>>>>>>>>> frame.setBounds(smallBounds); >>>>>>>>>> frame.setExtendedState(Frame.MAXIMIZED_BOTH); >>>>>>>>>> frame.setVisible(true); >>>>>>>>>> ----------------- >>>>>>>>>> >>>>>>>>>> This is the valid scenario where the frame should be >>>>>>>>>> maximized. >>>>>>>>>> >>>>>>>>>> The solution synchronizes the zoom and the frame state only >>>>>>>>>> when the native window is zoomed. >>>>>>>>>> In opposite case we need to return from the zoomed sizes to >>>>>>>>>> previous sizes which are the same as for the zoomed window. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > From anton.tarasov at oracle.com Fri May 22 08:01:37 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 22 May 2015 11:01:37 +0300 Subject: [9] Review Request: 8041654 OutOfMemoryError: RepainManager doesn't clean up cache of volatile images In-Reply-To: <555DCB82.5070900@oracle.com> References: <555DCB82.5070900@oracle.com> Message-ID: <555EE261.9020104@oracle.com> Hi Sergey, The fix looks fine to me. However, I don't clearly understand what did you mean by these comments? 1689 // Empty non private constructor was added because access to this 1690 // class shouldn't be emulated by a synthetic accessor method. 1691 DisplayChangedHandler() { 1692 super(); 1693 } I would expect something like "we need to be able to instantiate the class", but why you refer to accessors?... Also, do you think the super() call is necessary here? Reagards, Anton. On 21.05.2015 15:11, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > RepainManager adds a listener to the SGE.DisplayChangedListener() and it don't hold a strong > reference to this listener. The problem is that SGE holds a listeners in the WeakHashMap so > sometimes the listeners can be cleared before they are called. Same issue exists in XToolkit. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8041654 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8041654/webrev.02 > From alexander.zvegintsev at oracle.com Fri May 22 10:20:16 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 22 May 2015 13:20:16 +0300 Subject: [9-dev] Review request for bug 8079440 : [TESTBUG] @run is missing in java/awt/TrayIcon/8072769/bug8072769.java In-Reply-To: <555ED743.9060108@oracle.com> References: <5549EEE8.9040806@oracle.com> <554B6592.8050403@oracle.com> <555ED743.9060108@oracle.com> Message-ID: <555F02E0.4090101@oracle.com> looks fine to me. Thanks, Alexander. On 05/22/2015 10:14 AM, shobhit gupta wrote: > Hi Alexander, > > I've updated the webrev : > http://cr.openjdk.java.net/~sgupta/8079440/webrev.01/ > It includes one test case i.e. bug8072769.java > > Thanks and Regards, > Shobhit Gupta > > On 07-May-15 6:46 PM, Alexander Zvegintsev wrote: >> Hi, >> >> the bug8072769.java looks fine to me. >> Path2DCopyConstructor.java is already fixed by [1]. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8078464 >> Thanks, >> >> Alexander. >> On 05/06/2015 01:37 PM, shobhit gupta wrote: >>> |Hi,| >>> |Please review a fix ||for| |the issue:| >>> >>> JDK-8079440 : [TESTBUG] @run is missing in >>> java/awt/TrayIcon/8072769/bug8072769.java| >>> | >>> https://bugs.openjdk.java.net/browse/JDK-8079440 >>> |Webrev is : http://cr.openjdk.java.net/~sgupta/8079440/webrev.00/ >>> >>> Thanks and Regards, >>> Shobhit Gupta >>> | >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri May 22 11:59:19 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 22 May 2015 14:59:19 +0300 Subject: [9] Review request for 8003399: JFileChooser gives wrong path to selected file when saving to Libraries folder on Windows 7 In-Reply-To: <555DF67A.7090809@oracle.com> References: <554B1EE4.1080001@oracle.com> <554B21C5.9020500@oracle.com> <554B5AA1.1080206@oracle.com> <554CAFD0.9030305@oracle.com> <554CC1A4.90107@oracle.com> <555B5A9F.3090207@oracle.com> <555C7F60.5040407@oracle.com> <555C9639.1080305@oracle.com> <555DF67A.7090809@oracle.com> Message-ID: <555F1A17.9060708@oracle.com> Hi, Semyon. A few notes: - You need to check all possible exceptions and nulls in the native part of the fix(for example when you call JNU_NewStringPlatform). It can be double checked using parfait. - Please send a request about this comment "this is a temp fix until java.io starts support Libraries" to the core-lib alias. If it will not be supported will mean that out fix is not temporary. - Small issues in using spaces in "if(" On 21.05.15 18:15, Anton Tarasov wrote: > So, it looks fine to me now. Thanks. > > Anton. > > On 20/05/15 17:12, Semyon Sadetsky wrote: >> Hi Anton, >> >> http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.02/ >> I have added the macro you requested. >> >> --Semyon >> >> On 5/20/2015 3:34 PM, Anton V. Tarasov wrote: >>> Hi Semyon, >>> >>> I'm fine with it, but don't you want to define a simple macro for this: >>> >>> + jfieldID field_guid = env->GetFieldID(cl, "guid", "Ljava/lang/String;"); >>> + DASSERT(field_guid != NULL); >>> + CHECK_NULL_RETURN(field_guid, NULL); >>> >>> To call it like: >>> >>> DEFINE_FIELD_ID(field_guid, cl, "guid", "Ljava/lang/String;"); >>> >>> You would reduce the code a lot and make it more readable. >>> >>> Regards, >>> Anton. >>> >>> On 19.05.2015 18:45, Semyon Sadetsky wrote: >>>> Hi Anton, >>>> >>>> here is an updated version: >>>> http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.01/ >>>> >>>> --Semyon >>>> >>>> On 5/8/2015 5:01 PM, Semyon Sadetsky wrote: >>>>> >>>>> On 5/8/2015 3:45 PM, Sergey Bylokhov wrote: >>>>>> On 07.05.15 15:29, Semyon Sadetsky wrote: >>>>>>> Hi Sergey, >>>>>>> >>>>>>> Yes, after the fix filedialog produces usual filesystem paths >>>>>>> for libraries which are readable for java.io. >>>>>> Just to clarify: after the fix, both Open and Save dialog works? >>>>> Open file in library was not a problem, because an exicting file >>>>> has real FS path already. >>>>> >>>>>>> But there are no possibility to reference files in libraries >>>>>>> directly using new File(). >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> On 5/7/2015 11:26 AM, Sergey Bylokhov wrote: >>>>>>>> Hi, Semyon. >>>>>>>> Can you please raise the supportness of this in the java.io on >>>>>>>> the core-libs alias. >>>>>>>> Does the open filedialog will work after the fix? >>>>>>>> >>>>>>>> On 07.05.15 11:14, Semyon Sadetsky wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review fix for JDK9. >>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/ >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8003399 >>>>>>>>> >>>>>>>>> ***THE ROOT CAUSE >>>>>>>>> JDK uses legacy WINAPI special folders calls while MS >>>>>>>>> introduced a new interfaces IKnownFolder and IShellLibrary to >>>>>>>>> manage special folder locations and the new Libraries >>>>>>>>> functionality in Windows 7 is not backward compatible with old >>>>>>>>> special folders CSIDL. >>>>>>>>> >>>>>>>>> ***SOLUTION >>>>>>>>> Since it is too expensive to migrate AWT shell to the new >>>>>>>>> interfaces and still they are not supported in java.io the >>>>>>>>> solution is to map virtual folder PIDL to the Known Folder >>>>>>>>> GUID and replace libraries links with the default library save >>>>>>>>> location. Thus the File save dialog will be able to work with >>>>>>>>> any Libraries registered in the system (Windows Libraries >>>>>>>>> concept assumes that Libraries can be added arbitrary). >>>>>>>>> The resulting code should be compatible with older Windows >>>>>>>>> versions because the new COM interfaces are called only if >>>>>>>>> they are available and a Libraries link has been actually >>>>>>>>> requested. >>>>>>>>> >>>>>>>>> ***TESTING >>>>>>>>> A test scenario is added to check that all available Libraries >>>>>>>>> links are converted into filesystem paths. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri May 22 12:35:05 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 22 May 2015 15:35:05 +0300 Subject: [9-dev] Review request for bug 8079440 : [TESTBUG] @run is missing in java/awt/TrayIcon/8072769/bug8072769.java In-Reply-To: <555F02E0.4090101@oracle.com> References: <5549EEE8.9040806@oracle.com> <554B6592.8050403@oracle.com> <555ED743.9060108@oracle.com> <555F02E0.4090101@oracle.com> Message-ID: <555F2279.3010901@oracle.com> The fix looks good to me. Thanks, Alexandr. On 5/22/2015 1:20 PM, Alexander Zvegintsev wrote: > looks fine to me. > Thanks, > > Alexander. > On 05/22/2015 10:14 AM, shobhit gupta wrote: >> Hi Alexander, >> >> I've updated the webrev : >> http://cr.openjdk.java.net/~sgupta/8079440/webrev.01/ >> It includes one test case i.e. bug8072769.java >> >> Thanks and Regards, >> Shobhit Gupta >> >> On 07-May-15 6:46 PM, Alexander Zvegintsev wrote: >>> Hi, >>> >>> the bug8072769.java looks fine to me. >>> Path2DCopyConstructor.java is already fixed by [1]. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8078464 >>> Thanks, >>> >>> Alexander. >>> On 05/06/2015 01:37 PM, shobhit gupta wrote: >>>> |Hi,| >>>> |Please review a fix ||for| |the issue:| >>>> >>>> JDK-8079440 : [TESTBUG] @run is missing in >>>> java/awt/TrayIcon/8072769/bug8072769.java| >>>> | >>>> https://bugs.openjdk.java.net/browse/JDK-8079440 >>>> |Webrev is : http://cr.openjdk.java.net/~sgupta/8079440/webrev.00/ >>>> >>>> Thanks and Regards, >>>> Shobhit Gupta >>>> | >>> >> > From alexey.ivanov at oracle.com Fri May 22 13:08:19 2015 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 22 May 2015 16:08:19 +0300 Subject: [9] Review Request: JDK-8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in WindowsClassicLookAndFeel In-Reply-To: <555CCA45.7090202@oracle.com> References: <554292E6.7080608@oracle.com> <5548C2A6.5070207@oracle.com> <555CCA45.7090202@oracle.com> Message-ID: <555F2A43.4000707@oracle.com> Hi Pooja, The fix looks good to me. Regards, Alexey On 20.05.2015 20:54, pooja chopra wrote: > Hi All, > > Please review the updated webrev link as per discussion with Alexey as > below for the fix :- > > Please review a fix for issue: > 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails > in WindowsClassicLookAndFeel > Test bug fix. > https://bugs.openjdk.java.net/browse/JDK-8078855 > The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.01 > > Regards, > Pooja > > On 5/5/2015 6:46 PM, Alexey Ivanov wrote: >> Hello Pooja, >> >> The modified test case does not reproduce the problem reported in >> https://bugs.openjdk.java.net/browse/JDK-8032878. So this fix cannot >> be applied to the regression test. >> >> I confirm that the original test fails in WindowsClassicLookAndFeel >> because the editor selects the text, thus the typed text '123' is not >> added to existing text but replaces it. It could be a bug in >> WindowsClassicLookAndFeel or its feature. If it's not a bug, then the >> test should expect the value of "123" rather than "one123" where >> WindowsClassicLookAndFeel is used. >> >> Regards, >> Alexey >> >> On 30.04.2015 23:39, pooja chopra wrote: >>> Hello, >>> Please review a fix for issue: >>> 8078855 [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java >>> fails in WindowsClassicLookAndFeel >>> Test bug fix. >>> https://bugs.openjdk.java.net/browse/JDK-8078855 >>> The webrev is : http://cr.openjdk.java.net/~pchopra/8078855/webrev.00/ >>> >>> Thanks, >>> Pooja >> > From shobhit.s.gupta at oracle.com Fri May 22 07:14:11 2015 From: shobhit.s.gupta at oracle.com (shobhit gupta) Date: Fri, 22 May 2015 12:44:11 +0530 Subject: [9-dev] Review request for bug 8079440 : [TESTBUG] @run is missing in java/awt/TrayIcon/8072769/bug8072769.java In-Reply-To: <554B6592.8050403@oracle.com> References: <5549EEE8.9040806@oracle.com> <554B6592.8050403@oracle.com> Message-ID: <555ED743.9060108@oracle.com> Hi Alexander, I've updated the webrev : http://cr.openjdk.java.net/~sgupta/8079440/webrev.01/ It includes one test case i.e. bug8072769.java Thanks and Regards, Shobhit Gupta On 07-May-15 6:46 PM, Alexander Zvegintsev wrote: > Hi, > > the bug8072769.java looks fine to me. > Path2DCopyConstructor.java is already fixed by [1]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8078464 > Thanks, > > Alexander. > On 05/06/2015 01:37 PM, shobhit gupta wrote: >> |Hi,| >> |Please review a fix ||for| |the issue:| >> >> JDK-8079440 : [TESTBUG] @run is missing in >> java/awt/TrayIcon/8072769/bug8072769.java| >> | >> https://bugs.openjdk.java.net/browse/JDK-8079440 >> |Webrev is : http://cr.openjdk.java.net/~sgupta/8079440/webrev.00/ >> >> Thanks and Regards, >> Shobhit Gupta >> | > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pooja.chopra at oracle.com Fri May 22 13:52:22 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Fri, 22 May 2015 19:22:22 +0530 Subject: [9] Review Request: JDK-8080932 [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java fails with Bad script error due to improper @run notation Message-ID: <555F3496.5030900@oracle.com> Hello, Please review a fix for issue: 8080932 [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java fails with Bad script error due to improper @run notation Test bug fix. https://bugs.openjdk.java.net/browse/JDK-8080932 The webrev is : http://cr.openjdk.java.net/~pchopra/8080932/webrev.00 Thanks, Pooja From pooja.chopra at oracle.com Fri May 22 13:53:46 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Fri, 22 May 2015 19:23:46 +0530 Subject: [9] Review Request: JDK-8080932 [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java fails with Bad script error due to improper @run notation In-Reply-To: <555F3496.5030900@oracle.com> References: <555F3496.5030900@oracle.com> Message-ID: <555F34EA.3050603@oracle.com> Hello, > Please review a fix for issue: > 8080932 [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java fails > with Bad script error due to improper @run notation > Test bug fix. > https://bugs.openjdk.java.net/browse/JDK-8080932 > The webrev is : http://cr.openjdk.java.net/~pchopra/8080932/webrev.00 > > Thanks, > Pooja From yuri.nesterenko at oracle.com Fri May 22 14:02:47 2015 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Fri, 22 May 2015 17:02:47 +0300 Subject: [9] Review Request: JDK-8080932 [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java fails with Bad script error due to improper @run notation In-Reply-To: <555F34EA.3050603@oracle.com> References: <555F3496.5030900@oracle.com> <555F34EA.3050603@oracle.com> Message-ID: <555F3707.6050703@oracle.com> Hi Pooja, looks OK to me. Thanks, -yan On 05/22/2015 04:53 PM, pooja chopra wrote: > Hello, >> Please review a fix for issue: >> 8080932 [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java fails >> with Bad script error due to improper @run notation >> Test bug fix. >> https://bugs.openjdk.java.net/browse/JDK-8080932 >> The webrev is : http://cr.openjdk.java.net/~pchopra/8080932/webrev.00 >> >> Thanks, >> Pooja > From semyon.sadetsky at oracle.com Fri May 22 14:51:42 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 22 May 2015 17:51:42 +0300 Subject: [9] Review request for 8003399: JFileChooser gives wrong path to selected file when saving to Libraries folder on Windows 7 In-Reply-To: <555F1A17.9060708@oracle.com> References: <554B1EE4.1080001@oracle.com> <554B21C5.9020500@oracle.com> <554B5AA1.1080206@oracle.com> <554CAFD0.9030305@oracle.com> <554CC1A4.90107@oracle.com> <555B5A9F.3090207@oracle.com> <555C7F60.5040407@oracle.com> <555C9639.1080305@oracle.com> <555DF67A.7090809@oracle.com> <555F1A17.9060708@oracle.com> Message-ID: <555F427E.1080404@oracle.com> Sergey, Thank you for the review. the improved version: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.03/ --Semyon On 5/22/2015 2:59 PM, Sergey Bylokhov wrote: > Hi, Semyon. > A few notes: > - You need to check all possible exceptions and nulls in the native > part of the fix(for example when you call JNU_NewStringPlatform). It > can be double checked using parfait. > - Please send a request about this comment "this is a temp fix until > java.io starts support Libraries" to the core-lib alias. If it will > not be supported will mean that out fix is not temporary. > - Small issues in using spaces in "if(" > > On 21.05.15 18:15, Anton Tarasov wrote: >> So, it looks fine to me now. Thanks. >> >> Anton. >> >> On 20/05/15 17:12, Semyon Sadetsky wrote: >>> Hi Anton, >>> >>> http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.02/ >>> I have added the macro you requested. >>> >>> --Semyon >>> >>> On 5/20/2015 3:34 PM, Anton V. Tarasov wrote: >>>> Hi Semyon, >>>> >>>> I'm fine with it, but don't you want to define a simple macro for this: >>>> >>>> + jfieldID field_guid = env->GetFieldID(cl, "guid", "Ljava/lang/String;"); >>>> + DASSERT(field_guid != NULL); >>>> + CHECK_NULL_RETURN(field_guid, NULL); >>>> >>>> To call it like: >>>> >>>> DEFINE_FIELD_ID(field_guid, cl, "guid", "Ljava/lang/String;"); >>>> >>>> You would reduce the code a lot and make it more readable. >>>> >>>> Regards, >>>> Anton. >>>> >>>> On 19.05.2015 18:45, Semyon Sadetsky wrote: >>>>> Hi Anton, >>>>> >>>>> here is an updated version: >>>>> http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.01/ >>>>> >>>>> --Semyon >>>>> >>>>> On 5/8/2015 5:01 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> On 5/8/2015 3:45 PM, Sergey Bylokhov wrote: >>>>>>> On 07.05.15 15:29, Semyon Sadetsky wrote: >>>>>>>> Hi Sergey, >>>>>>>> >>>>>>>> Yes, after the fix filedialog produces usual filesystem paths >>>>>>>> for libraries which are readable for java.io. >>>>>>> Just to clarify: after the fix, both Open and Save dialog works? >>>>>> Open file in library was not a problem, because an exicting file >>>>>> has real FS path already. >>>>>> >>>>>>>> But there are no possibility to reference files in libraries >>>>>>>> directly using new File(). >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> On 5/7/2015 11:26 AM, Sergey Bylokhov wrote: >>>>>>>>> Hi, Semyon. >>>>>>>>> Can you please raise the supportness of this in the java.io on >>>>>>>>> the core-libs alias. >>>>>>>>> Does the open filedialog will work after the fix? >>>>>>>>> >>>>>>>>> On 07.05.15 11:14, Semyon Sadetsky wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review fix for JDK9. >>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/ >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8003399 >>>>>>>>>> >>>>>>>>>> ***THE ROOT CAUSE >>>>>>>>>> JDK uses legacy WINAPI special folders calls while MS >>>>>>>>>> introduced a new interfaces IKnownFolder and IShellLibrary to >>>>>>>>>> manage special folder locations and the new Libraries >>>>>>>>>> functionality in Windows 7 is not backward compatible with >>>>>>>>>> old special folders CSIDL. >>>>>>>>>> >>>>>>>>>> ***SOLUTION >>>>>>>>>> Since it is too expensive to migrate AWT shell to the new >>>>>>>>>> interfaces and still they are not supported in java.io the >>>>>>>>>> solution is to map virtual folder PIDL to the Known Folder >>>>>>>>>> GUID and replace libraries links with the default library >>>>>>>>>> save location. Thus the File save dialog will be able to work >>>>>>>>>> with any Libraries registered in the system (Windows >>>>>>>>>> Libraries concept assumes that Libraries can be added >>>>>>>>>> arbitrary). >>>>>>>>>> The resulting code should be compatible with older Windows >>>>>>>>>> versions because the new COM interfaces are called only if >>>>>>>>>> they are available and a Libraries link has been actually >>>>>>>>>> requested. >>>>>>>>>> >>>>>>>>>> ***TESTING >>>>>>>>>> A test scenario is added to check that all available >>>>>>>>>> Libraries links are converted into filesystem paths. >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.cherkasov at oracle.com Fri May 22 16:28:50 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Fri, 22 May 2015 19:28:50 +0300 Subject: 8077409: Drawing deviates when validate() is invoked on java.awt.ScrollPane In-Reply-To: <5548EEAE.9030305@oracle.com> References: <5542861C.30103@oracle.com> <5548EEAE.9030305@oracle.com> Message-ID: <555F5942.9060800@oracle.com> Hello Sergey. There's a second version of fix with a test: http://cr.openjdk.java.net/~mcherkas/8077409v9/webrev.01/ I found out that the problem is in layout method, it should not use insets, ViewportSize is already calculated with considering about insets. During testing jdk without the fix I faced with rendering problems like described in jbs bug, also I faced with duplication of very first pixel of scroll pane. With http://cr.openjdk.java.net/~mcherkas/8077409v9/webrev.01/ everything works fine. I don't see any rendering issues or problems with scrolling. I also run test from test/(closed)/java/awt/ScrollPane, all tests are passed. Thanks, Mikhail. On 5/5/2015 7:24 PM, Sergey Bylokhov wrote: > Hi, Mikhail. > Is it possible to write a test for this issue based on the code in the > bug report? > > On 30.04.15 22:44, mikhail cherkasov wrote: >> Hi there, >> >> Could you please review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8077409 >> webrev: http://cr.openjdk.java.net/~mcherkas/8077409v9/webrev.00/ >> >> In ScrollPane, move() is called without considering the quota of >> Insets when invoking ScrollPane$PeerFixer.adjustmentValueChanged(). When >> validate() is called, drawing deviates to coordinate with Insets >> interanlly. >> >> Thanks, >> Mikhail. >> >> > > From pooja.chopra at oracle.com Fri May 22 16:59:23 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Fri, 22 May 2015 22:29:23 +0530 Subject: [9] Review Request: JDK-8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to wrongly typed bugid Message-ID: <555F606B.3040606@oracle.com> Hello, Please review a fix for issue: 8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to wrongly typed bugid Test bug fix. https://bugs.openjdk.java.net/browse/JDK-8080953 The webrev is : http://cr.openjdk.java.net/~pchopra/8080953/webrev.00 Thanks, Pooja From Sergey.Bylokhov at oracle.com Fri May 22 17:04:11 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 22 May 2015 20:04:11 +0300 Subject: [9] Review Request: JDK-8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to wrongly typed bugid In-Reply-To: <555F606B.3040606@oracle.com> References: <555F606B.3040606@oracle.com> Message-ID: <555F618B.7090507@oracle.com> cc 2d On 22.05.15 19:59, pooja chopra wrote: > Hello, > Please review a fix for issue: > 8080953 [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to > wrongly typed bugid > Test bug fix. > https://bugs.openjdk.java.net/browse/JDK-8080953 > The webrev is : http://cr.openjdk.java.net/~pchopra/8080953/webrev.00 > > Thanks, > Pooja > -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Fri May 22 18:56:42 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 22 May 2015 21:56:42 +0300 Subject: [OpenJDK 2D-Dev] [9] Review Request: 6587235 Incorrect javadoc: "no parameter" in 2d source code In-Reply-To: <554D39D9.4040301@oracle.com> References: <554D0D9F.9010207@oracle.com> <554D13EB.1070504@oracle.com> <554D39D9.4040301@oracle.com> Message-ID: <555F7BEA.7050409@oracle.com> the fix looks good to me too. -- Thanks, Alexander. On 09.05.2015 1:34, Sergey Bylokhov wrote: > Hi, Phil. > Thanks for a review! The new version: > http://cr.openjdk.java.net/~serb/6587235/webrev.01 > > On 08.05.15 22:52, Phil Race wrote: >> 273 * RuntimePermission("accessClassInPackage."+pkg) >> 274 * permission. >> 275 * >> 276 * @param pkgname the package name. >> >> >> perhaps line 273 should match ? >> >> 7 * @param srcArg The first source tile for the compositing >> operation. >> 88 * @param dstIn The second source tile for the compositing >> operation. >> 89 * @param dstOut The tile where the result of the operation >> is stored. >> 90 */ >> 91 public void compose(Raster srcArg, Raster dstIn, >> WritableRaster dstOut) { >> >> it might be better to rename the actual arguments to match the doc. >> >> >> 47 /** >> 48 * Construct a new dialog type selection enumeration value >> with the >> 49 * given integer value. >> 50 * >> 51 * @param frame Integer value. >> 52 */ >> 53 public DialogOwner(Frame frame) { >> >> Huh ? The entire doc seems to be nonsense .. changing the name of the >> param >> just makes it worse. The text seems to have been copied from >> javax.attribute.standard.DialogTypeSelection.java >> >> >> -phil. >> >> On 05/08/2015 12:25 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for a typos in jdk9. This CR was filed by me >>> long time ago and I doubt that someone will take a look at it. >>> I fixed all clients files in sun.** subpackages. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6587235 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/6587235/webrev.00 >>> >> > > From Sergey.Bylokhov at oracle.com Sun May 24 15:58:29 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 24 May 2015 18:58:29 +0300 Subject: [9] Review request for 8065739 [macosx] Frame warps to lower left of screen when displayed In-Reply-To: <555DCD05.1020005@oracle.com> References: <5525410A.8080407@oracle.com> <552EC29D.3090706@oracle.com> <554100C2.6050902@oracle.com> <554CABEF.7030502@oracle.com> <554CAF39.8040409@oracle.com> <555203BC.2090604@oracle.com> <55546D89.7080704@oracle.com> <5555D8F1.9000101@oracle.com> <555CAF63.4090409@oracle.com> <555DCD05.1020005@oracle.com> Message-ID: <5561F525.3090105@oracle.com> Hi, Alexander. I found one more issue. the new code in CPlatformWindow.checkZoom does not take into account that peer can be null for warning icon. On 21.05.15 15:18, Sergey Bylokhov wrote: > Hi, Alexander. > The fix looks fine. > > On 20.05.15 18:59, Alexander Scherbatiy wrote: >> >> On 5/15/2015 2:30 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> A few notes: >>> - _peer.setMaximizedBounds(_peer.getMaximizedBounds()); this line >>> looks odd, probably we can call updateMaximizedBounds in >>> LWWindowPeer. initializeImpl()? >>> - Do we need to call maximize(); in the initialize() or we can >>> leave it in the setVisible()? It seems that after we set >>> NSWindowStandardFrame isZoomed should work properly in the callback? >>> - Why we cannot return DefaultMaximizedBounds from the >>> getMaximizedBounds if it was not set? Then it will not be necessary >>> to check it to null everywhere. >>> - Can we call updateMaximizedBounds(); in >>> LWWindowPeer.displayChanged() only in case of new device? >>> >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8065739/webrev.05 >> >> The fix has been updated according to the comments. >> >> Thanks, >> Alexandr. >>> On 14.05.15 12:40, Alexander Scherbatiy wrote: >>>> On 5/12/2015 4:44 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Could you review the updated fix: >>>>> - maximized bounds are updated after switching to new screen if >>>>> they are not set by a user >>>>> - the test for the maximized window moved from one screen to >>>>> another is added >>>> Sorry. Just forgot to add the webrev link: >>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.04/ >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 5/8/2015 3:42 PM, Sergey Bylokhov wrote: >>>>>> Hi, Alexander. >>>>>> Does the new tests cover all corner cases which we discussed >>>>>> offline? >>>>>> >>>>>> On 08.05.15 15:28, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the updated fix: >>>>>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.03 >>>>>>> >>>>>>> - The -windowWillUseStandardFrame:defaultFrame: method is >>>>>>> implemented in AWTWindow to correctly get and check a size of >>>>>>> the maximized window. >>>>>>> After that the -isZoomed method correctly defines the zoomed >>>>>>> state for both visible and not visible window. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 4/29/2015 7:03 PM, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the updated fix: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.02 >>>>>>>> >>>>>>>> - the zoom state is applied after NSWindow creation if Frame >>>>>>>> has MAXIMIZED_BOTH state. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 4/15/2015 10:57 PM, Sergey Bylokhov wrote: >>>>>>>>> Hi, Alexander. >>>>>>>>> As far as I understand the main issue is that we get a native >>>>>>>>> notifications during window initialization(after nswindows was >>>>>>>>> created and before zoom method will be called)? Probably we >>>>>>>>> can apply the zoom state when we create a window in one appkit >>>>>>>>> call? >>>>>>>>> >>>>>>>>> On 08.04.15 17:54, Alexander Scherbatiy wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Could you review the fix: >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8065739 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8065739/webrev.00 >>>>>>>>>> >>>>>>>>>> Use case: >>>>>>>>>> ------------ >>>>>>>>>> Frame frame = new Frame(); >>>>>>>>>> frame.pack(); >>>>>>>>>> frame.setBounds(screenBounds); >>>>>>>>>> frame.setVisible(true); >>>>>>>>>> ------------ >>>>>>>>>> >>>>>>>>>> The frame is in the normal state but Mac OS X treats a >>>>>>>>>> frame with screen bounds as zoomed. >>>>>>>>>> The setVisible() method calls unmaximize() method to return >>>>>>>>>> the zoomed window to the normal state. >>>>>>>>>> The native zoom() method sets the initial sizes for the >>>>>>>>>> window which are zero because of the pack() call. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> There is already checkZoom() method which synchronizes >>>>>>>>>> native window zoom state and and the frame extended state >>>>>>>>>> when a frame is resized by mouse. >>>>>>>>>> However it can't be always used for the synchronization >>>>>>>>>> between native window zoom state and setBounds() call because >>>>>>>>>> of the following case: >>>>>>>>>> >>>>>>>>>> ----------------- >>>>>>>>>> Frame frame = new Frame(); >>>>>>>>>> frame.setBounds(smallBounds); >>>>>>>>>> frame.setExtendedState(Frame.MAXIMIZED_BOTH); >>>>>>>>>> frame.setVisible(true); >>>>>>>>>> ----------------- >>>>>>>>>> >>>>>>>>>> This is the valid scenario where the frame should be >>>>>>>>>> maximized. >>>>>>>>>> >>>>>>>>>> The solution synchronizes the zoom and the frame state only >>>>>>>>>> when the native window is zoomed. >>>>>>>>>> In opposite case we need to return from the zoomed sizes to >>>>>>>>>> previous sizes which are the same as for the zoomed window. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > -- Best regards, Sergey. From anton.nashatyrev at oracle.com Mon May 25 10:57:51 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Mon, 25 May 2015 13:57:51 +0300 Subject: [9] Review request for 8068886: IDEA IntelliJ crashes in objc_msgSend when an accessibility tool is enabled In-Reply-To: <55563AA3.5040409@oracle.com> References: <554CE9BD.9040001@oracle.com> <5552473D.4040902@oracle.com> <555600A4.1030506@oracle.com> <55563AA3.5040409@oracle.com> Message-ID: <5563002F.1000001@oracle.com> Hi Sergey, thanks for review! Could anybody else take a look at the fix? Thanks! Anton. On 15.05.2015 21:27, Sergey Bylokhov wrote: > Hi, Anton. > Thanks, the fix looks fine. >> I've sent you two suspects, but if this needs to fixed as well I >> suggest to make it under another bug. > ok, I'll take look at it. >> >> Thanks! >> Anton. >> >> On 12.05.2015 21:32, Sergey Bylokhov wrote: >>> Hi, Anton. >>> The fix looks fine, but I suggest to document the new resources >>> deallocation policy. I suppose documentation of loops, >>> CFRetainedResource, etc should be updated. >>> Also please confirm that all our code follow this rule. >>> >>> On 08.05.15 19:52, Anton Nashatyrev wrote: >>>> Hello, >>>> could you please review the following fix: >>>> >>>> fix: http://cr.openjdk.java.net/~anashaty/8068886/webrev.00/ >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8068886 >>>> >>>> Problem: the native window pointer is disposed in the inner >>>> AppKit loop, while it is still referenced on the stack in the >>>> native Cocoa method which caused the mentioned inner loop. When the >>>> inner loop is exited Cocoa crashes while dereferencing this window >>>> pointer >>>> >>>> Fix: dispose resources in the main AppKit loop only. For this a >>>> 'dispose message' posted which is processed only on the main loop. >>>> >>>> Thanks! >>>> Anton. >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.nashatyrev at oracle.com Mon May 25 11:00:24 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Mon, 25 May 2015 14:00:24 +0300 Subject: Approved: Re: [9] Review request for RFE-8074882: Support 'replacement range' feature in the Input Method API In-Reply-To: References: <551C1213.1050308@oracle.com> <5527BE32.4000500@oracle.com> Message-ID: <556300C8.6030409@oracle.com> ??????, ?????? ?????? ??????? ???? ???? ????? ???????! ?????. On 12.04.2015 13:57, Alexander Zuev wrote: > Looks fine to me. > > /Alex > > On 10 Apr 2015, at 15:12, Anton Nashatyrev > > wrote: > >> Hello, >> >> any volunteers to review? >> >> Thanks! >> Anton. >> >> On 01.04.2015 18:43, Anton Nashatyrev wrote: >>> Hello, >>> could you please review the following IM API extension proposal: >>> >>> fix: http://cr.openjdk.java.net/~anashaty/8074882/9/webrev.00/ >>> >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8074882 >>> >>> Problem: Press-and-hold Mac IM (when an accented char variant >>> could be selected) couldn't be supported by the components other >>> than TextComponent >>> >>> MacOS Cocoa Input Method API supports the 'replacement range' >>> parameter in its callbacks indicating what range of the committed >>> text of the document should be replaced with the new composed text. >>> In case of press-and-hold IM this parameter always indicates the >>> previous char. >>> >>> Fix: extends the IM API to support the 'replacement range'. The >>> fix includes the new API, its implementation and adoption to the >>> existing JTextComponent, the changes to be made in the MacOS code to >>> conform the new API. >>> The sample custom Java IM is attached to the JBS report to >>> demonstrate the new API usage and test the implementation. >>> >>> Thanks! >>> Anton. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.nashatyrev at oracle.com Mon May 25 11:04:33 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Mon, 25 May 2015 14:04:33 +0300 Subject: [9] Review request for 8078606: Deadlock in awt clipboard In-Reply-To: <554CDF8D.6010008@oracle.com> References: <554CDF8D.6010008@oracle.com> Message-ID: <556301C1.7030303@oracle.com> Hello, any volunteers? Thanks! Anton. On 08.05.2015 19:08, Anton Nashatyrev wrote: > Hello, > could you please review the following fix: > > fix: http://cr.openjdk.java.net/~anashaty/8078606/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8078606 > > Problem: XClipboard sometimes deadlocked > > Reason: XClipboard.registerClipboardViewerChecked acquires > XCliboard lock first, then tries to acquire AWTLock (within the > XWindow.getXAWTRootWindow() call) > > Fix: reverse the order of acquiring locks. Additionally eliminate > AWTLock when accessing XRootWindow singleton. > > Thanks! > Anton. From Sergey.Bylokhov at oracle.com Mon May 25 12:15:40 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 May 2015 15:15:40 +0300 Subject: [9] Review request for 8003399: JFileChooser gives wrong path to selected file when saving to Libraries folder on Windows 7 In-Reply-To: <555F427E.1080404@oracle.com> References: <554B1EE4.1080001@oracle.com> <554B21C5.9020500@oracle.com> <554B5AA1.1080206@oracle.com> <554CAFD0.9030305@oracle.com> <554CC1A4.90107@oracle.com> <555B5A9F.3090207@oracle.com> <555C7F60.5040407@oracle.com> <555C9639.1080305@oracle.com> <555DF67A.7090809@oracle.com> <555F1A17.9060708@oracle.com> <555F427E.1080404@oracle.com> Message-ID: <5563126C.4030509@oracle.com> Hi, Semyon. The fix looks good. On 22.05.15 17:51, Semyon Sadetsky wrote: > Sergey, > > Thank you for the review. > the improved version: > http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.03/ > > --Semyon > > On 5/22/2015 2:59 PM, Sergey Bylokhov wrote: >> Hi, Semyon. >> A few notes: >> - You need to check all possible exceptions and nulls in the native >> part of the fix(for example when you call JNU_NewStringPlatform). It >> can be double checked using parfait. >> - Please send a request about this comment "this is a temp fix until >> java.io starts support Libraries" to the core-lib alias. If it will >> not be supported will mean that out fix is not temporary. >> - Small issues in using spaces in "if(" >> >> On 21.05.15 18:15, Anton Tarasov wrote: >>> So, it looks fine to me now. Thanks. >>> >>> Anton. >>> >>> On 20/05/15 17:12, Semyon Sadetsky wrote: >>>> Hi Anton, >>>> >>>> http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.02/ >>>> I have added the macro you requested. >>>> >>>> --Semyon >>>> >>>> On 5/20/2015 3:34 PM, Anton V. Tarasov wrote: >>>>> Hi Semyon, >>>>> >>>>> I'm fine with it, but don't you want to define a simple macro for >>>>> this: >>>>> >>>>> + jfieldID field_guid = env->GetFieldID(cl, "guid", "Ljava/lang/String;"); >>>>> + DASSERT(field_guid != NULL); >>>>> + CHECK_NULL_RETURN(field_guid, NULL); >>>>> >>>>> To call it like: >>>>> >>>>> DEFINE_FIELD_ID(field_guid, cl, "guid", "Ljava/lang/String;"); >>>>> >>>>> You would reduce the code a lot and make it more readable. >>>>> >>>>> Regards, >>>>> Anton. >>>>> >>>>> On 19.05.2015 18:45, Semyon Sadetsky wrote: >>>>>> Hi Anton, >>>>>> >>>>>> here is an updated version: >>>>>> http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.01/ >>>>>> >>>>>> --Semyon >>>>>> >>>>>> On 5/8/2015 5:01 PM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> On 5/8/2015 3:45 PM, Sergey Bylokhov wrote: >>>>>>>> On 07.05.15 15:29, Semyon Sadetsky wrote: >>>>>>>>> Hi Sergey, >>>>>>>>> >>>>>>>>> Yes, after the fix filedialog produces usual filesystem paths >>>>>>>>> for libraries which are readable for java.io. >>>>>>>> Just to clarify: after the fix, both Open and Save dialog works? >>>>>>> Open file in library was not a problem, because an exicting file >>>>>>> has real FS path already. >>>>>>> >>>>>>>>> But there are no possibility to reference files in libraries >>>>>>>>> directly using new File(). >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> On 5/7/2015 11:26 AM, Sergey Bylokhov wrote: >>>>>>>>>> Hi, Semyon. >>>>>>>>>> Can you please raise the supportness of this in the java.io >>>>>>>>>> on the core-libs alias. >>>>>>>>>> Does the open filedialog will work after the fix? >>>>>>>>>> >>>>>>>>>> On 07.05.15 11:14, Semyon Sadetsky wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review fix for JDK9. >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8003399/webrev.00/ >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8003399 >>>>>>>>>>> >>>>>>>>>>> ***THE ROOT CAUSE >>>>>>>>>>> JDK uses legacy WINAPI special folders calls while MS >>>>>>>>>>> introduced a new interfaces IKnownFolder and IShellLibrary >>>>>>>>>>> to manage special folder locations and the new Libraries >>>>>>>>>>> functionality in Windows 7 is not backward compatible with >>>>>>>>>>> old special folders CSIDL. >>>>>>>>>>> >>>>>>>>>>> ***SOLUTION >>>>>>>>>>> Since it is too expensive to migrate AWT shell to the new >>>>>>>>>>> interfaces and still they are not supported in java.io the >>>>>>>>>>> solution is to map virtual folder PIDL to the Known Folder >>>>>>>>>>> GUID and replace libraries links with the default library >>>>>>>>>>> save location. Thus the File save dialog will be able to >>>>>>>>>>> work with any Libraries registered in the system (Windows >>>>>>>>>>> Libraries concept assumes that Libraries can be added >>>>>>>>>>> arbitrary). >>>>>>>>>>> The resulting code should be compatible with older Windows >>>>>>>>>>> versions because the new COM interfaces are called only if >>>>>>>>>>> they are available and a Libraries link has been actually >>>>>>>>>>> requested. >>>>>>>>>>> >>>>>>>>>>> ***TESTING >>>>>>>>>>> A test scenario is added to check that all available >>>>>>>>>>> Libraries links are converted into filesystem paths. >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.cherkasov at oracle.com Mon May 25 12:18:01 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Mon, 25 May 2015 15:18:01 +0300 Subject: 8077409: Drawing deviates when validate() is invoked on java.awt.ScrollPane In-Reply-To: <555F5942.9060800@oracle.com> References: <5542861C.30103@oracle.com> <5548EEAE.9030305@oracle.com> <555F5942.9060800@oracle.com> Message-ID: <556312F9.2040709@oracle.com> Hello, this is kindly reminder about the review request. Thanks, Mikhail. On 5/22/2015 7:28 PM, mikhail cherkasov wrote: > Hello Sergey. > > There's a second version of fix with a test: > http://cr.openjdk.java.net/~mcherkas/8077409v9/webrev.01/ > > I found out that the problem is in layout method, it should not use > insets, > ViewportSize is already calculated with considering about insets. > > During testing jdk without the fix I faced with rendering problems > like described in jbs bug, also > I faced with duplication of very first pixel of scroll pane. > > With http://cr.openjdk.java.net/~mcherkas/8077409v9/webrev.01/ > everything works fine. I don't see any rendering issues or problems > with scrolling. > I also run test from test/(closed)/java/awt/ScrollPane, all tests are > passed. > > Thanks, > Mikhail. > > On 5/5/2015 7:24 PM, Sergey Bylokhov wrote: >> Hi, Mikhail. >> Is it possible to write a test for this issue based on the code in >> the bug report? >> >> On 30.04.15 22:44, mikhail cherkasov wrote: >>> Hi there, >>> >>> Could you please review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8077409 >>> webrev: http://cr.openjdk.java.net/~mcherkas/8077409v9/webrev.00/ >>> >>> In ScrollPane, move() is called without considering the quota of >>> Insets when invoking ScrollPane$PeerFixer.adjustmentValueChanged(). >>> When >>> validate() is called, drawing deviates to coordinate with Insets >>> interanlly. >>> >>> Thanks, >>> Mikhail. >>> >>> >> >> > From alexander.zvegintsev at oracle.com Mon May 25 12:46:24 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 25 May 2015 15:46:24 +0300 Subject: [9] Review request for 8078606: Deadlock in awt clipboard In-Reply-To: <556301C1.7030303@oracle.com> References: <554CDF8D.6010008@oracle.com> <556301C1.7030303@oracle.com> Message-ID: <556319A0.2060807@oracle.com> Hello Anton, the fix looks fine to me. Thanks, Alexander. On 05/25/2015 02:04 PM, Anton Nashatyrev wrote: > Hello, > > any volunteers? > > Thanks! > Anton. > > On 08.05.2015 19:08, Anton Nashatyrev wrote: >> Hello, >> could you please review the following fix: >> >> fix: http://cr.openjdk.java.net/~anashaty/8078606/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8078606 >> >> Problem: XClipboard sometimes deadlocked >> >> Reason: XClipboard.registerClipboardViewerChecked acquires >> XCliboard lock first, then tries to acquire AWTLock (within the >> XWindow.getXAWTRootWindow() call) >> >> Fix: reverse the order of acquiring locks. Additionally eliminate >> AWTLock when accessing XRootWindow singleton. >> >> Thanks! >> Anton. > From alexandr.scherbatiy at oracle.com Mon May 25 15:40:58 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 25 May 2015 18:40:58 +0300 Subject: [9] Review request for 8065739 [macosx] Frame warps to lower left of screen when displayed In-Reply-To: <5561F525.3090105@oracle.com> References: <5525410A.8080407@oracle.com> <552EC29D.3090706@oracle.com> <554100C2.6050902@oracle.com> <554CABEF.7030502@oracle.com> <554CAF39.8040409@oracle.com> <555203BC.2090604@oracle.com> <55546D89.7080704@oracle.com> <5555D8F1.9000101@oracle.com> <555CAF63.4090409@oracle.com> <555DCD05.1020005@oracle.com> <5561F525.3090105@oracle.com> Message-ID: <5563428A.2040302@oracle.com> On 5/24/2015 6:58 PM, Sergey Bylokhov wrote: > Hi, Alexander. > I found one more issue. the new code in CPlatformWindow.checkZoom does > not take into account that peer can be null for warning icon. I have filled the issue JDK-8081019 Check peer to null in CPlatformWindow.checkZoom() method Thanks, Alexandr. > > On 21.05.15 15:18, Sergey Bylokhov wrote: >> Hi, Alexander. >> The fix looks fine. >> >> On 20.05.15 18:59, Alexander Scherbatiy wrote: >>> >>> On 5/15/2015 2:30 PM, Sergey Bylokhov wrote: >>>> Hi, Alexander. >>>> A few notes: >>>> - _peer.setMaximizedBounds(_peer.getMaximizedBounds()); this line >>>> looks odd, probably we can call updateMaximizedBounds in >>>> LWWindowPeer. initializeImpl()? >>>> - Do we need to call maximize(); in the initialize() or we can >>>> leave it in the setVisible()? It seems that after we set >>>> NSWindowStandardFrame isZoomed should work properly in the callback? >>>> - Why we cannot return DefaultMaximizedBounds from the >>>> getMaximizedBounds if it was not set? Then it will not be necessary >>>> to check it to null everywhere. >>>> - Can we call updateMaximizedBounds(); in >>>> LWWindowPeer.displayChanged() only in case of new device? >>>> >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.05 >>> >>> The fix has been updated according to the comments. >>> >>> Thanks, >>> Alexandr. >>>> On 14.05.15 12:40, Alexander Scherbatiy wrote: >>>>> On 5/12/2015 4:44 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Could you review the updated fix: >>>>>> - maximized bounds are updated after switching to new screen if >>>>>> they are not set by a user >>>>>> - the test for the maximized window moved from one screen to >>>>>> another is added >>>>> Sorry. Just forgot to add the webrev link: >>>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.04/ >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 5/8/2015 3:42 PM, Sergey Bylokhov wrote: >>>>>>> Hi, Alexander. >>>>>>> Does the new tests cover all corner cases which we discussed >>>>>>> offline? >>>>>>> >>>>>>> On 08.05.15 15:28, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the updated fix: >>>>>>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.03 >>>>>>>> >>>>>>>> - The -windowWillUseStandardFrame:defaultFrame: method is >>>>>>>> implemented in AWTWindow to correctly get and check a size of >>>>>>>> the maximized window. >>>>>>>> After that the -isZoomed method correctly defines the zoomed >>>>>>>> state for both visible and not visible window. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 4/29/2015 7:03 PM, Alexander Scherbatiy wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the updated fix: >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8065739/webrev.02 >>>>>>>>> >>>>>>>>> - the zoom state is applied after NSWindow creation if Frame >>>>>>>>> has MAXIMIZED_BOTH state. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> On 4/15/2015 10:57 PM, Sergey Bylokhov wrote: >>>>>>>>>> Hi, Alexander. >>>>>>>>>> As far as I understand the main issue is that we get a native >>>>>>>>>> notifications during window initialization(after nswindows >>>>>>>>>> was created and before zoom method will be called)? Probably >>>>>>>>>> we can apply the zoom state when we create a window in one >>>>>>>>>> appkit call? >>>>>>>>>> >>>>>>>>>> On 08.04.15 17:54, Alexander Scherbatiy wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Could you review the fix: >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8065739 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8065739/webrev.00 >>>>>>>>>>> >>>>>>>>>>> Use case: >>>>>>>>>>> ------------ >>>>>>>>>>> Frame frame = new Frame(); >>>>>>>>>>> frame.pack(); >>>>>>>>>>> frame.setBounds(screenBounds); >>>>>>>>>>> frame.setVisible(true); >>>>>>>>>>> ------------ >>>>>>>>>>> >>>>>>>>>>> The frame is in the normal state but Mac OS X treats a >>>>>>>>>>> frame with screen bounds as zoomed. >>>>>>>>>>> The setVisible() method calls unmaximize() method to >>>>>>>>>>> return the zoomed window to the normal state. >>>>>>>>>>> The native zoom() method sets the initial sizes for the >>>>>>>>>>> window which are zero because of the pack() call. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> There is already checkZoom() method which synchronizes >>>>>>>>>>> native window zoom state and and the frame extended state >>>>>>>>>>> when a frame is resized by mouse. >>>>>>>>>>> However it can't be always used for the synchronization >>>>>>>>>>> between native window zoom state and setBounds() call >>>>>>>>>>> because of the following case: >>>>>>>>>>> >>>>>>>>>>> ----------------- >>>>>>>>>>> Frame frame = new Frame(); >>>>>>>>>>> frame.setBounds(smallBounds); >>>>>>>>>>> frame.setExtendedState(Frame.MAXIMIZED_BOTH); >>>>>>>>>>> frame.setVisible(true); >>>>>>>>>>> ----------------- >>>>>>>>>>> >>>>>>>>>>> This is the valid scenario where the frame should be >>>>>>>>>>> maximized. >>>>>>>>>>> >>>>>>>>>>> The solution synchronizes the zoom and the frame state >>>>>>>>>>> only when the native window is zoomed. >>>>>>>>>>> In opposite case we need to return from the zoomed sizes >>>>>>>>>>> to previous sizes which are the same as for the zoomed window. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> > > From semyon.sadetsky at oracle.com Tue May 26 05:09:32 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 26 May 2015 08:09:32 +0300 Subject: [9] Review Request for 8017487: filechooser in Windows-Libraries folder: columns are mixed up In-Reply-To: <556337B0.1050404@oracle.com> References: <556337B0.1050404@oracle.com> Message-ID: <5564000C.2060101@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8017487 webrev: http://cr.openjdk.java.net/~ssadetsky/8017487/webrev.00/ File details view columns obtained by the legacy special folder API for the virtual Windows libraries are not consistent with child files inside those libraries. The details can be obtained only using new Windows APIs since MS stops to support the old API for the new Windows libraries. The fix redirects column details requests for Windows Libraries to their real file system locations. --Semyon From philip.race at oracle.com Tue May 26 18:48:07 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 26 May 2015 11:48:07 -0700 Subject: RFR: 8081231: JDK9 client build broken on Windows Message-ID: <5564BFE7.7070207@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8081231 ShellFolder2 only gets a definition of DASSERT if DEBUG is defined. Proposed fix :- diff --git a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp --- a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp +++ b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp @@ -66,7 +66,9 @@ #define DEFINE_FIELD_ID(var, cls, field, type) \ jfieldID var = env->GetFieldID(cls, field, type); \ +#ifdef DEBUG DASSERT(var != NULL); \ +#endif CHECK_NULL_RETURN(var, NULL); -phil. From alexander.zvegintsev at oracle.com Tue May 26 19:14:31 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 26 May 2015 22:14:31 +0300 Subject: RFR: 8081231: JDK9 client build broken on Windows In-Reply-To: <5564BFE7.7070207@oracle.com> References: <5564BFE7.7070207@oracle.com> Message-ID: <5564C617.3000203@oracle.com> Looks fine -- Thanks, Alexander. On 26.05.2015 21:48, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8081231 > > > ShellFolder2 only gets a definition of DASSERT if DEBUG is defined. > > Proposed fix :- > > diff --git > a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp > b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp > --- a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp > +++ b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp > @@ -66,7 +66,9 @@ > > #define DEFINE_FIELD_ID(var, cls, field, type) \ > jfieldID var = env->GetFieldID(cls, field, type); \ > +#ifdef DEBUG > DASSERT(var != NULL); \ > +#endif > CHECK_NULL_RETURN(var, NULL); > > -phil. From philip.race at oracle.com Tue May 26 19:21:53 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 26 May 2015 12:21:53 -0700 Subject: RfR JDK-8077296 RE build fails on non-Win builds when attempting to build Win only javadoc In-Reply-To: <555D8504.2030800@oracle.com> References: <555D6E3E.5030806@oracle.com> <555D8504.2030800@oracle.com> Message-ID: <5564C7D1.7080705@oracle.com> +1 -phil. On 05/21/2015 12:11 AM, Erik Joelsson wrote: > Hello Pete, > > This looks good to me. > > /Erik > > On 2015-05-21 07:33, Pete Brunet wrote: >> Please review the following change for 8u: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/ >> >> Background: >> >> - As part of the open sourcing of the JAB and Java Accessibility >> Utilities (JAU) the JAU Javadoc was setup to be added to the build. >> - Due to a 8u build issue (it uses source bundles) the Javadoc had to be >> temporarily disabled: JDK-8076552 >> - The issue was caused by JAU code being in windows instead of share. >> - For 9 the JAU code is in >> jdk.accessibility/share/classes/com/sun/java/accessibility/util (and the >> JAB code under jdk.accessibility/windows). >> - For 8u both the JAU and JAB code is in jdk/src/windows. >> - The problem on 8u is with non-windows builds; the 8 Javadoc build >> process doesn't find the JAU files because they are in a windows >> directory. >> - The fix is to refactor so 8u is like 9 with the JAU files in share; >> then the javadoc build process will find the source for all build >> platforms. >> - Make has been changed so jaccess.jar is built for all platforms >> - Some obsolete files have been removed as they were causing build >> problems. They were removed from 9 earlier but not from 8u. These are >> com/sun/java/accessibility/util/java/awt/ChoiceTranslator.java and all >> the files in com/sun/java/accessibility/extensions. >> >> Thanks, Pete > From philip.race at oracle.com Tue May 26 20:41:43 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 26 May 2015 13:41:43 -0700 Subject: RFR: 8081231: JDK9 client build broken on Windows In-Reply-To: <5564C617.3000203@oracle.com> References: <5564BFE7.7070207@oracle.com> <5564C617.3000203@oracle.com> Message-ID: <5564DA87.1060007@oracle.com> Actually no it wasn't :-) I'd overlooked the line escapes. So I'll try the following approach :- (but I am waiting for my build to complete) :- diff --git a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp --- a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp +++ b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp @@ -64,6 +64,9 @@ //#include +#ifndef DASSERT +#define DASSERT(x) +#endif #define DEFINE_FIELD_ID(var, cls, field, type) \ jfieldID var = env->GetFieldID(cls, field, type); \ DASSERT(var != NULL); \ -phil. On 05/26/2015 12:14 PM, Alexander Zvegintsev wrote: > Looks fine > > -- > Thanks, > Alexander. > > On 26.05.2015 21:48, Phil Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8081231 >> >> >> ShellFolder2 only gets a definition of DASSERT if DEBUG is defined. >> >> Proposed fix :- >> >> diff --git >> a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> --- a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> +++ b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> @@ -66,7 +66,9 @@ >> >> #define DEFINE_FIELD_ID(var, cls, field, type) \ >> jfieldID var = env->GetFieldID(cls, field, type); \ >> +#ifdef DEBUG >> DASSERT(var != NULL); \ >> +#endif >> CHECK_NULL_RETURN(var, NULL); >> >> -phil. > From alexander.zvegintsev at oracle.com Tue May 26 21:17:51 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 27 May 2015 00:17:51 +0300 Subject: RFR: 8081231: JDK9 client build broken on Windows In-Reply-To: <5564DA87.1060007@oracle.com> References: <5564BFE7.7070207@oracle.com> <5564C617.3000203@oracle.com> <5564DA87.1060007@oracle.com> Message-ID: <5564E2FF.9010804@oracle.com> Oh, I see :) +1 -- Thanks, Alexander. On 26.05.2015 23:41, Phil Race wrote: > Actually no it wasn't :-) I'd overlooked the line escapes. > > So I'll try the following approach :- (but I am waiting for my build > to complete) :- > diff --git > a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp > b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp > --- a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp > +++ b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp > @@ -64,6 +64,9 @@ > > //#include > > +#ifndef DASSERT > +#define DASSERT(x) > +#endif > #define DEFINE_FIELD_ID(var, cls, field, > type) \ > jfieldID var = env->GetFieldID(cls, field, > type); \ > DASSERT(var != > NULL); \ > > -phil. > > On 05/26/2015 12:14 PM, Alexander Zvegintsev wrote: >> Looks fine >> >> -- >> Thanks, >> Alexander. >> >> On 26.05.2015 21:48, Phil Race wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8081231 >>> >>> >>> ShellFolder2 only gets a definition of DASSERT if DEBUG is defined. >>> >>> Proposed fix :- >>> >>> diff --git >>> a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >>> b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >>> --- a/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >>> +++ b/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >>> @@ -66,7 +66,9 @@ >>> >>> #define DEFINE_FIELD_ID(var, cls, field, type) \ >>> jfieldID var = env->GetFieldID(cls, field, type); \ >>> +#ifdef DEBUG >>> DASSERT(var != NULL); \ >>> +#endif >>> CHECK_NULL_RETURN(var, NULL); >>> >>> -phil. >> > From Sergey.Bylokhov at oracle.com Wed May 27 13:48:11 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 27 May 2015 16:48:11 +0300 Subject: [9] Review Request: 8078658 Make custom Cursors available for modular build Message-ID: <5565CB1B.5070205@oracle.com> Hello. Please review the fix for jdk9. The usage of getResource() was changed to getResourceAsStream(). Note that before the fix the toolkit.getImage() cached the image, but it should not be a problem in the new code, because cursor itself is cached in the Cursor.getSystemCustomCursor(). Bug: https://bugs.openjdk.java.net/browse/JDK-8078658 Webrev can be found at: http://cr.openjdk.java.net/~serb/8078658/webrev.00 -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed May 27 15:51:27 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 May 2015 16:51:27 +0100 Subject: [9] Review Request: 8078658 Make custom Cursors available for modular build In-Reply-To: <5565CB1B.5070205@oracle.com> References: <5565CB1B.5070205@oracle.com> Message-ID: <5565E7FF.2010704@oracle.com> On 27/05/2015 14:48, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > The usage of getResource() was changed to getResourceAsStream(). Note > that before the fix the toolkit.getImage() cached the image, but it > should not be a problem in the new code, because cursor itself is > cached in the Cursor.getSystemCustomCursor(). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8078658 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8078658/webrev.00 This looks okay to me. I assume existing tests will exercise this code well. A minor comment on the usage of ByteArrayOutputStream is that you should be able to replace this soon with: Image image = toolkit.createImage( in.readAllBytes() ); The readAllBytes method is currently in review on core-libs-dev. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed May 27 16:03:32 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 27 May 2015 19:03:32 +0300 Subject: [9] Review Request: 8078658 Make custom Cursors available for modular build In-Reply-To: <5565E7FF.2010704@oracle.com> References: <5565CB1B.5070205@oracle.com> <5565E7FF.2010704@oracle.com> Message-ID: <5565EAD4.1020809@oracle.com> Hi, Alan. On 27.05.15 18:51, Alan Bateman wrote: > A minor comment on the usage of ByteArrayOutputStream is that you > should be able to replace this soon with: > Image image = toolkit.createImage( in.readAllBytes() ); > > The readAllBytes method is currently in review on core-libs-dev. Thanks for this suggestion. I'll postpone the fix a little bit. > > -Alan. -- Best regards, Sergey. From anton.nashatyrev at oracle.com Wed May 27 16:37:27 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Wed, 27 May 2015 19:37:27 +0300 Subject: [9] Review request for 8041470: JButtons stay pressed after they have lost focus if you use the mouse wheel Message-ID: <5565F2C7.6020408@oracle.com> Hello, could you please review the following fix: fix: http://cr.openjdk.java.net/~anashaty/8041470/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8041470 Problem: mouseRelease not called on a component after dragging outside and scrolling the wheel Fix: correct logical typo Thanks! Anton. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Wed May 27 20:04:24 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 27 May 2015 23:04:24 +0300 Subject: [9] Review request for 8041470: JButtons stay pressed after they have lost focus if you use the mouse wheel In-Reply-To: <5565F2C7.6020408@oracle.com> References: <5565F2C7.6020408@oracle.com> Message-ID: <55662348.4030404@oracle.com> Hello Anton, As I can see type and wheel_mouse parameters are no longer used in getModifiers(), so probably we can safely remove them. -- Thanks, Alexander. On 05/27/2015 07:37 PM, Anton Nashatyrev wrote: > Hello, > could you please review the following fix: > > fix: http://cr.openjdk.java.net/~anashaty/8041470/webrev.00/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8041470 > > Problem: mouseRelease not called on a component after dragging > outside and scrolling the wheel > > Fix: correct logical typo > > Thanks! > Anton. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu May 28 00:07:41 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 May 2015 17:07:41 -0700 Subject: RfR JDK-8077296 RE build fails on non-Win builds when attempting to build Win only javadoc In-Reply-To: <5564C7D1.7080705@oracle.com> References: <555D6E3E.5030806@oracle.com> <555D8504.2030800@oracle.com> <5564C7D1.7080705@oracle.com> Message-ID: <94D45306-CA55-49F0-A579-2B2D06BC828D@oracle.com> >> >> On 2015-05-21 07:33, Pete Brunet wrote: >>> Please review the following change for 8u: >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/ I only skimmed through the change. package-info.java should have @jdk.Exported. Mandy >>> >>> Background: >>> >>> - As part of the open sourcing of the JAB and Java Accessibility >>> Utilities (JAU) the JAU Javadoc was setup to be added to the build. >>> - Due to a 8u build issue (it uses source bundles) the Javadoc had to be >>> temporarily disabled: JDK-8076552 >>> - The issue was caused by JAU code being in windows instead of share. >>> - For 9 the JAU code is in >>> jdk.accessibility/share/classes/com/sun/java/accessibility/util (and the >>> JAB code under jdk.accessibility/windows). >>> - For 8u both the JAU and JAB code is in jdk/src/windows. >>> - The problem on 8u is with non-windows builds; the 8 Javadoc build >>> process doesn't find the JAU files because they are in a windows directory. >>> - The fix is to refactor so 8u is like 9 with the JAU files in share; >>> then the javadoc build process will find the source for all build platforms. >>> - Make has been changed so jaccess.jar is built for all platforms >>> - Some obsolete files have been removed as they were causing build >>> problems. They were removed from 9 earlier but not from 8u. These are >>> com/sun/java/accessibility/util/java/awt/ChoiceTranslator.java and all >>> the files in com/sun/java/accessibility/extensions. >>> >>> Thanks, Pete >> > From semyon.sadetsky at oracle.com Thu May 28 06:44:23 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 28 May 2015 09:44:23 +0300 Subject: [9] Review Request for 8022057: JFileChooser blocks EDT in Win32ShellFolder2.getIcon Message-ID: <5566B947.7040402@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8022057 webrev: http://cr.openjdk.java.net/~ssadetsky/8022057/webrev.00/ The full story can be found in the jira's comments and NetBeans tracker (https://netbeans.org/bugzilla/show_bug.cgi?id=188001). It seems the bug proposes to change the design of the AWT shell support on Windows platform. But instead I tried to eliminate the user experience issue it can be a good step to improve the situation. The user experience issue is the JFileChooser spontaneous delays caused by getIcon(): I could not reproduce this under Win7 and jdk8/9. But I found in MSDN that ExtractIcon Win32 API call can take significant amount of time in some cases. Mostly when the file is an executable or a link and its icon is not cached yet. MS propose a way how to avoid that: use asynchronous flag GIL_ASYNC with GetIconLocation call which then may return E_PENDING which means consequent ExtractIcon call can take time. There are several ways to handle E_PENDING return I propose just to use the default icon for the file which can be obtained with GIL_DEFAULTICON flag and should be much faster. Since I cannot reproduce the issue I don't know how effective it will be. Also in the fix I added possibility to get Windows-Libraries icons, which were not available before in the JFileChooser. --Semyon From alexandr.scherbatiy at oracle.com Thu May 28 12:09:24 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 28 May 2015 15:09:24 +0300 Subject: [9] Review request for 8081019 Check peer to null in CPlatformWindow.checkZoom() method Message-ID: <55670574.2080606@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8081019 webrev: http://cr.openjdk.java.net/~alexsch/8081019/webrev.00 Peer is checked to null in the checkZoom() method. Thanks, Alexandr. From anton.nashatyrev at oracle.com Thu May 28 12:32:36 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Thu, 28 May 2015 15:32:36 +0300 Subject: [9] Review request for 8041470: JButtons stay pressed after they have lost focus if you use the mouse wheel In-Reply-To: <55662348.4030404@oracle.com> References: <5565F2C7.6020408@oracle.com> <55662348.4030404@oracle.com> Message-ID: <55670AE4.2050307@oracle.com> Hello Alexander, On 27.05.2015 23:04, Alexander Zvegintsev wrote: > Hello Anton, > > As I can see type and wheel_mouse parameters are no longer used in > getModifiers(), > so probably we can safely remove them. Sure, please see the new version: http://cr.openjdk.java.net/~anashaty/8041470/webrev.01/ Thanks for review! Anton. > -- > Thanks, > Alexander. > On 05/27/2015 07:37 PM, Anton Nashatyrev wrote: >> Hello, >> could you please review the following fix: >> >> fix: http://cr.openjdk.java.net/~anashaty/8041470/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8041470 >> >> Problem: mouseRelease not called on a component after dragging >> outside and scrolling the wheel >> >> Fix: correct logical typo >> >> Thanks! >> Anton. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu May 28 12:56:03 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 28 May 2015 15:56:03 +0300 Subject: [9] Review Request: 8080695: splashscreen_png.c compile error with gcc 4.9.2 In-Reply-To: <555C3F03.4030004@gmail.com> References: <555B1574.7000302@gmail.com> <555B41DB.8040103@oracle.com> <555C3F03.4030004@gmail.com> Message-ID: <55671063.8090508@oracle.com> Hi. The fix looks fine. On 20.05.15 11:00, Peter Levart wrote: > Hi Alexander, > > I filed the issue as: > > https://bugs.openjdk.java.net/browse/JDK-8080695 > > The proposed patch is this, which also fixes compile time error: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/splashscreen_png/webrev.02/ > > If this is OK, I can push it if the change can go via jdk9-dev > repository where I can commit. Is there a special repository for > client libs? Do I need a sponsor? > > Regards, Peter > > On 05/19/2015 03:59 PM, Alexander Zvegintsev wrote: >> Hi Peter, >> >> I think that your solution can be simplified to: >> >> diff -r 729dffc8afa0 >> src/java.desktop/share/native/libsplashscreen/splashscreen_png.c >> --- a/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c >> +++ b/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c >> @@ -77,6 +77,8 @@ SplashDecodePng(Splash * splash, png_rw_ >> #else >> if (setjmp(png_jmpbuf(png_ptr))) { >> #endif >> + row_pointers = NULL; >> + image_data = NULL; >> goto done; >> } >> >> As another solution you can declare row_pointers and image_data as >> volatile. >> >> BTW, Could you please file an issue? >> >> Thanks, >> >> Alexander. >> On 05/19/2015 01:50 PM, Peter Levart wrote: >>> Hi, >>> >>> I hope this is the right thread to post the observation. >>> >>> Building recent OpenJDK 9 from sources on Fedora 21 fails with this: >>> >>> /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c: >>> In function 'SplashDecodePng': >>> /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c:51:16: >>> error: variable 'row_pointers' might be clobbered by 'longjmp' or >>> 'vfork' [-Werror=clobbered] >>> png_bytepp row_pointers = NULL; >>> ^ >>> /home/peter/work/hg/jdk9-dev/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_png.c:52:15: >>> error: variable 'image_data' might be clobbered by 'longjmp' or >>> 'vfork' [-Werror=clobbered] >>> png_bytep image_data = NULL; >>> ^ >>> cc1: all warnings being treated as errors >>> gmake[3]: *** >>> [/home/peter/work/hg/jdk9-dev/build/linux-x86_64-normal-server-release/support/native/java.desktop/libsplashscreen/splashscreen_png.o] >>> Error 1 >>> gmake[3]: *** Waiting for unfinished jobs.... >>> Awt2dLibraries.gmk:879: recipe for target >>> '/home/peter/work/hg/jdk9-dev/build/linux-x86_64-normal-server-release/support/native/java.desktop/libsplashscreen/splashscreen_png.o' >>> failed >>> gmake[2]: *** [java.desktop-libs] Error 1 >>> make/Main.gmk:168: recipe for target 'java.desktop-libs' failed >>> >>> >>> I found that making the following change eliminates the compiler error: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/splashscreen_png/webrev.01/ >>> >>> >>> Is this the right way to fix it? >>> >>> Regards, Peter >>> >> > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu May 28 13:03:59 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 28 May 2015 16:03:59 +0300 Subject: [9] Review request for 8081019 Check peer to null in CPlatformWindow.checkZoom() method In-Reply-To: <55670574.2080606@oracle.com> References: <55670574.2080606@oracle.com> Message-ID: <5567123F.70705@oracle.com> Hi, Alexander. The fix looks fine. On 28.05.15 15:09, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8081019 > webrev: http://cr.openjdk.java.net/~alexsch/8081019/webrev.00 > > Peer is checked to null in the checkZoom() method. > > Thanks, > Alexandr. > -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Thu May 28 13:15:39 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 28 May 2015 16:15:39 +0300 Subject: [9] Review request for 8081019 Check peer to null in CPlatformWindow.checkZoom() method In-Reply-To: <5567123F.70705@oracle.com> References: <55670574.2080606@oracle.com> <5567123F.70705@oracle.com> Message-ID: <556714FB.7070306@oracle.com> +1 Thanks, Alexander. On 05/28/2015 04:03 PM, Sergey Bylokhov wrote: > Hi, Alexander. > The fix looks fine. > > On 28.05.15 15:09, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8081019 >> webrev: http://cr.openjdk.java.net/~alexsch/8081019/webrev.00 >> >> Peer is checked to null in the checkZoom() method. >> >> Thanks, >> Alexandr. >> > > From alexander.zvegintsev at oracle.com Thu May 28 13:17:16 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 28 May 2015 16:17:16 +0300 Subject: [9] Review request for 8041470: JButtons stay pressed after they have lost focus if you use the mouse wheel In-Reply-To: <55670AE4.2050307@oracle.com> References: <5565F2C7.6020408@oracle.com> <55662348.4030404@oracle.com> <55670AE4.2050307@oracle.com> Message-ID: <5567155C.50101@oracle.com> the fix looks good to me. Thanks, Alexander. On 05/28/2015 03:32 PM, Anton Nashatyrev wrote: > Hello Alexander, > > On 27.05.2015 23:04, Alexander Zvegintsev wrote: >> Hello Anton, >> >> As I can see type and wheel_mouse parameters are no longer used in >> getModifiers(), >> so probably we can safely remove them. > > Sure, please see the new version: > http://cr.openjdk.java.net/~anashaty/8041470/webrev.01/ > > > Thanks for review! > Anton. > >> -- >> Thanks, >> Alexander. >> On 05/27/2015 07:37 PM, Anton Nashatyrev wrote: >>> Hello, >>> could you please review the following fix: >>> >>> fix: http://cr.openjdk.java.net/~anashaty/8041470/webrev.00/ >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8041470 >>> >>> Problem: mouseRelease not called on a component after dragging >>> outside and scrolling the wheel >>> >>> Fix: correct logical typo >>> >>> Thanks! >>> Anton. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.nashatyrev at oracle.com Thu May 28 15:13:03 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Thu, 28 May 2015 18:13:03 +0300 Subject: [9] Review request for 8041470: JButtons stay pressed after they have lost focus if you use the mouse wheel In-Reply-To: <5567155C.50101@oracle.com> References: <5565F2C7.6020408@oracle.com> <55662348.4030404@oracle.com> <55670AE4.2050307@oracle.com> <5567155C.50101@oracle.com> Message-ID: <5567307F.8070409@oracle.com> Alexander, thanks for review! Just found out that the test intermittently fails on Win (due to immediate 2nd mouse wheel scroll sometimes missed). Here is the new version with updated fix (wait for the first scroll event then make the second): http://cr.openjdk.java.net/~anashaty/8041470/webrev.02/ Thanks! Anton. On 28.05.2015 16:17, Alexander Zvegintsev wrote: > the fix looks good to me. > Thanks, > > Alexander. > On 05/28/2015 03:32 PM, Anton Nashatyrev wrote: >> Hello Alexander, >> >> On 27.05.2015 23:04, Alexander Zvegintsev wrote: >>> Hello Anton, >>> >>> As I can see type and wheel_mouse parameters are no longer used in >>> getModifiers(), >>> so probably we can safely remove them. >> >> Sure, please see the new version: >> http://cr.openjdk.java.net/~anashaty/8041470/webrev.01/ >> >> >> Thanks for review! >> Anton. >> >>> -- >>> Thanks, >>> Alexander. >>> On 05/27/2015 07:37 PM, Anton Nashatyrev wrote: >>>> Hello, >>>> could you please review the following fix: >>>> >>>> fix: http://cr.openjdk.java.net/~anashaty/8041470/webrev.00/ >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041470 >>>> >>>> Problem: mouseRelease not called on a component after dragging >>>> outside and scrolling the wheel >>>> >>>> Fix: correct logical typo >>>> >>>> Thanks! >>>> Anton. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.potochkin at oracle.com Thu May 28 17:06:48 2015 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Thu, 28 May 2015 20:06:48 +0300 Subject: [9] Review request for 8041470: JButtons stay pressed after they have lost focus if you use the mouse wheel In-Reply-To: <5567307F.8070409@oracle.com> References: <5565F2C7.6020408@oracle.com> <55662348.4030404@oracle.com> <55670AE4.2050307@oracle.com> <5567155C.50101@oracle.com> <5567307F.8070409@oracle.com> Message-ID: <55674B28.3060405@oracle.com> Looks good to me Thanks alexp > Alexander, thanks for review! > > Just found out that the test intermittently fails on Win (due to > immediate 2nd mouse wheel scroll sometimes missed). > > Here is the new version with updated fix (wait for the first scroll > event then make the second): > http://cr.openjdk.java.net/~anashaty/8041470/webrev.02/ > > > Thanks! > Anton. > > On 28.05.2015 16:17, Alexander Zvegintsev wrote: >> the fix looks good to me. >> Thanks, >> >> Alexander. >> On 05/28/2015 03:32 PM, Anton Nashatyrev wrote: >>> Hello Alexander, >>> >>> On 27.05.2015 23:04, Alexander Zvegintsev wrote: >>>> Hello Anton, >>>> >>>> As I can see type and wheel_mouse parameters are no longer used in >>>> getModifiers(), >>>> so probably we can safely remove them. >>> >>> Sure, please see the new version: >>> http://cr.openjdk.java.net/~anashaty/8041470/webrev.01/ >>> >>> >>> Thanks for review! >>> Anton. >>> >>>> -- >>>> Thanks, >>>> Alexander. >>>> On 05/27/2015 07:37 PM, Anton Nashatyrev wrote: >>>>> Hello, >>>>> could you please review the following fix: >>>>> >>>>> fix: http://cr.openjdk.java.net/~anashaty/8041470/webrev.00/ >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041470 >>>>> >>>>> Problem: mouseRelease not called on a component after dragging >>>>> outside and scrolling the wheel >>>>> >>>>> Fix: correct logical typo >>>>> >>>>> Thanks! >>>>> Anton. >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From javalists at cbfiddle.com Fri May 29 02:13:12 2015 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 28 May 2015 19:13:12 -0700 Subject: internal API usage: sun.awt.AppContext Message-ID: <9AC86A8B-CE08-473A-8019-B8B29F7DF6CA@cbfiddle.com> I am using code ? a custom Swing look and feel ? that uses the getAppContext(), get(), put(), and remove() methods of sun.awt.AppContext to store configuration data. Since the look and feel is registered by UIManager using the same mechanism, this seems like the right way to store configuration data for a look and feel. I also note that AppContext advertises itself as a better solution (e.g. better than static fields) to protect applets from being disrupted by other applets, so it may have other uses. Is there a way to duplicate this behavior using only public APIs? If not, I request that this functionality be exported in some form by JDK 9. Alan From gnu.andrew at redhat.com Fri May 29 02:24:04 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 28 May 2015 22:24:04 -0400 (EDT) Subject: RFR: 8081447: System JPEG builds include in-tree jpeglib.h, resulting in build failure In-Reply-To: <183469517.7327364.1432865930046.JavaMail.zimbra@redhat.com> Message-ID: <844575377.7327957.1432866244163.JavaMail.zimbra@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8081447 Webrev: http://cr.openjdk.java.net/~andrew/8081447/webrev.01/ In testing a fix for [0], I found that system jpeg support seems to have bitrotted. Due to the movement of makefiles, it's hard to trace where this change occurred, but we have the conditional code: ifeq ($(USE_EXTERNAL_LIBJPEG), true) BUILD_LIBJAVAJPEG_HEADERS := else BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC)) endif but then BUILD_LIBJAVAJPEG_HEADERS is not used and instead $(addprefix -I, $(LIBJAVAJPEG_SRC)) is hardcoded in BUILD_LIBJAVAJPEG: CFLAGS := $(CFLAGS_JDKLIB) $(addprefix -I, $(LIBJAVAJPEG_SRC)) \ When building using the system libjpeg, this means that the jpeglib.h from the in-tree copy of libjpeg is used to build jpegdecoder.o. This leads to references to symbols that don't exist in the system version and a failure to link libjavajpeg.so The simple fix for this is to use BUILD_LIBJAVAJPEG_HEADERS again, as in the listed webrev. Ok to push to client? Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Fri May 29 02:25:42 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 28 May 2015 22:25:42 -0400 (EDT) Subject: RFR: 8081447: System JPEG builds include in-tree jpeglib.h, resulting in build failure In-Reply-To: <844575377.7327957.1432866244163.JavaMail.zimbra@redhat.com> References: <844575377.7327957.1432866244163.JavaMail.zimbra@redhat.com> Message-ID: <1063513720.7328094.1432866342041.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Bug: https://bugs.openjdk.java.net/browse/JDK-8081447 > Webrev: http://cr.openjdk.java.net/~andrew/8081447/webrev.01/ > > In testing a fix for [0], I found that system jpeg support seems > to have bitrotted. Due to the movement of makefiles, it's hard > to trace where this change occurred, but we have the conditional > code: > > ifeq ($(USE_EXTERNAL_LIBJPEG), true) > BUILD_LIBJAVAJPEG_HEADERS := > else > BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC)) > endif > > but then BUILD_LIBJAVAJPEG_HEADERS is not used and > instead $(addprefix -I, $(LIBJAVAJPEG_SRC)) is hardcoded in > BUILD_LIBJAVAJPEG: > > CFLAGS := $(CFLAGS_JDKLIB) $(addprefix -I, $(LIBJAVAJPEG_SRC)) \ > > When building using the system libjpeg, this means that the jpeglib.h > from the in-tree copy of libjpeg is used to build jpegdecoder.o. This > leads to references to symbols that don't exist in the system version > and a failure to link libjavajpeg.so > > The simple fix for this is to use BUILD_LIBJAVAJPEG_HEADERS again, > as in the listed webrev. > > Ok to push to client? > > Thanks, Reference should have been: [0] https://bugs.openjdk.java.net/browse/JDK-8081315 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From philip.race at oracle.com Fri May 29 04:41:06 2015 From: philip.race at oracle.com (Phil Race) Date: Thu, 28 May 2015 21:41:06 -0700 Subject: RFR: 8081447: System JPEG builds include in-tree jpeglib.h, resulting in build failure In-Reply-To: <1063513720.7328094.1432866342041.JavaMail.zimbra@redhat.com> References: <844575377.7327957.1432866244163.JavaMail.zimbra@redhat.com> <1063513720.7328094.1432866342041.JavaMail.zimbra@redhat.com> Message-ID: <5567EDE2.10300@oracle.com> Looks OK to me. I've added 2d-dev (owner of the lib). I don't think this will cause any issue for closed builds but we'll address it if it does. -phil. On 5/28/15 7:25 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Bug: https://bugs.openjdk.java.net/browse/JDK-8081447 >> Webrev: http://cr.openjdk.java.net/~andrew/8081447/webrev.01/ >> >> In testing a fix for [0], I found that system jpeg support seems >> to have bitrotted. Due to the movement of makefiles, it's hard >> to trace where this change occurred, but we have the conditional >> code: >> >> ifeq ($(USE_EXTERNAL_LIBJPEG), true) >> BUILD_LIBJAVAJPEG_HEADERS := >> else >> BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC)) >> endif >> >> but then BUILD_LIBJAVAJPEG_HEADERS is not used and >> instead $(addprefix -I, $(LIBJAVAJPEG_SRC)) is hardcoded in >> BUILD_LIBJAVAJPEG: >> >> CFLAGS := $(CFLAGS_JDKLIB) $(addprefix -I, $(LIBJAVAJPEG_SRC)) \ >> >> When building using the system libjpeg, this means that the jpeglib.h >> from the in-tree copy of libjpeg is used to build jpegdecoder.o. This >> leads to references to symbols that don't exist in the system version >> and a failure to link libjavajpeg.so >> >> The simple fix for this is to use BUILD_LIBJAVAJPEG_HEADERS again, >> as in the listed webrev. >> >> Ok to push to client? >> >> Thanks, > Reference should have been: > > [0] https://bugs.openjdk.java.net/browse/JDK-8081315 From magnus.ihse.bursie at oracle.com Fri May 29 07:44:11 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 29 May 2015 09:44:11 +0200 Subject: RFR: 8081447: System JPEG builds include in-tree jpeglib.h, resulting in build failure In-Reply-To: <844575377.7327957.1432866244163.JavaMail.zimbra@redhat.com> References: <844575377.7327957.1432866244163.JavaMail.zimbra@redhat.com> Message-ID: <556818CB.6040400@oracle.com> An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri May 29 10:28:50 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 29 May 2015 13:28:50 +0300 Subject: [9] Review Request for 8017487: filechooser in Windows-Libraries folder: columns are mixed up In-Reply-To: <5564000C.2060101@oracle.com> References: <556337B0.1050404@oracle.com> <5564000C.2060101@oracle.com> Message-ID: <55683F62.3050201@oracle.com> Hi, The fix looks fine, except "Libraries" text. Does it mean that the same text is used in all locales? On 26.05.15 8:09, Semyon Sadetsky wrote: > > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8017487 > webrev: http://cr.openjdk.java.net/~ssadetsky/8017487/webrev.00/ > > File details view columns obtained by the legacy special folder API for > the virtual Windows libraries are not consistent with child files inside > those libraries. > The details can be obtained only using new Windows APIs since MS stops > to support the old API for the new Windows libraries. > The fix redirects column details requests for Windows Libraries to their > real file system locations. > > --Semyon > > > > -- Best regards, Sergey. From gnu.andrew at redhat.com Fri May 29 17:40:41 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 29 May 2015 13:40:41 -0400 (EDT) Subject: RFR: 8081447: System JPEG builds include in-tree jpeglib.h, resulting in build failure In-Reply-To: <556818CB.6040400@oracle.com> References: <844575377.7327957.1432866244163.JavaMail.zimbra@redhat.com> <556818CB.6040400@oracle.com> Message-ID: <2074812326.7807337.1432921241873.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 2015-05-29 04:24, Andrew Hughes wrote: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8081447 Webrev: > http://cr.openjdk.java.net/~andrew/8081447/webrev.01/ In testing a fix for > [0], I found that system jpeg support seems > to have bitrotted. Due to the movement of makefiles, it's hard > to trace where this change occurred, but we have the conditional > code: > > It was a casualty of JDK-8054834 (Modular Source Code ). > Yes, I traced it to that changeset, but it wasn't clear if it was actually changed there or the file was simply moved then. > Thanks for the fix, it looks good to me. My thanks to yourself and Phil. I've pushed the fix: http://hg.openjdk.java.net/jdk9/client/jdk/rev/6f87fd2df0d6 > > /Magnus > > > > > ifeq ($(USE_EXTERNAL_LIBJPEG), true) > BUILD_LIBJAVAJPEG_HEADERS := > else > BUILD_LIBJAVAJPEG_HEADERS := $(addprefix -I, $(LIBJAVAJPEG_SRC)) > endif > > but then BUILD_LIBJAVAJPEG_HEADERS is not used and > instead $(addprefix -I, $(LIBJAVAJPEG_SRC)) is hardcoded in > BUILD_LIBJAVAJPEG: > > CFLAGS := $(CFLAGS_JDKLIB) $(addprefix -I, $(LIBJAVAJPEG_SRC)) \ > > When building using the system libjpeg, this means that the jpeglib.h > from the in-tree copy of libjpeg is used to build jpegdecoder.o. This > leads to references to symbols that don't exist in the system version > and a failure to link libjavajpeg.so > > The simple fix for this is to use BUILD_LIBJAVAJPEG_HEADERS again, > as in the listed webrev. > > Ok to push to client? > > Thanks, > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07