From semyon.sadetsky at oracle.com Mon Nov 2 13:51:53 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 2 Nov 2015 16:51:53 +0300 Subject: [9] Review Request for 8078514: Nightly: api/javax_swing/DefaultRowSorter/index_ModelStructChanged failure In-Reply-To: <55644D39.2080208@oracle.com> References: <55560786.9010306@oracle.com> <555B1885.2020605@oracle.com> <555DECDB.6020301@oracle.com> <55644D39.2080208@oracle.com> Message-ID: <56376A78.3090900@oracle.com> On 5/26/2015 1:38 PM, Alexander Scherbatiy wrote: > On 5/21/2015 5:34 PM, Semyon Sadetsky wrote: >> Hello, >> >> I have decided to remake the fix. >> The reason for that is sun.swing.FilePane class. One of its inner >> classes extends DefaultRowSorter and relays on lazy initialization of >> the DefaultRowSorter in unsorted state. After removing the lazy init >> the FilePane crashes with AOB exception. > > It looks like FilePane tries to call some operations like > DefaultRowSorter.convertRowIndexToView(int) on non updated > DefaultRowSorter. > Is it possible to fix it in FilePane? I fixed the FilePane. Please review the updated webrev: http://cr.openjdk.java.net/~ssadetsky/8078514/webrev.02/ > > Thanks, > Alexandr. > >> This can be fixed, but I think it will be too big change for the >> issue and users can be already using the DefaultRowSorter in the >> similar way. >> Here is the new approach: >> http://cr.openjdk.java.net/~ssadetsky/8078514/webrev.01/ >> It looks a little bit risky ,but all related tests have been passed. >> >> --Semyon >> >> On 5/19/2015 2:03 PM, Alexander Scherbatiy wrote: >>> On 5/15/2015 5:49 PM, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Please review fix for JDK9: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8078514 >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8078514/webrev.00/ >>> >>> DefaultRowSorter >>> 221 allChanged(); >>> 222 modelRowCount = getModelWrapper().getRowCount(); >>> >>> - This can be moved to a private method that will be used both in >>> the public modelStructureChanged() and setModelWrapper() methods. >>> >>> 532 public void sort() >>> - Could the rawFilter be null in case viewToModel != null an >>> !isUnsorted() ? >>> - isUnsorted() method is called twice. Is it possible to store its >>> value to a variable and use it? >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> The 6894632 fix violated a contract between the table and its row >>>> sorter: the sorter should receive TableChanged events even if table >>>> is not sorted actually. >>>> Another way to fix 6894632 is to initialize sorter internal >>>> structures instantly. The last is applied in the fix. >>>> >>>> --Semyon >>>> >>> >> > From rajeev.chamyal at oracle.com Mon Nov 2 16:19:30 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Mon, 2 Nov 2015 08:19:30 -0800 (PST) Subject: Review request for JDK-8030099 Memory usage of java process increases after pressing start button in test window In-Reply-To: <56327601.40103@oracle.com> References: <562565A7.6000701@oracle.com> <56256D75.9010003@oracle.com> <6937cb71-466b-4972-b12a-15c5d7607b28@default> <56313450.4010704@oracle.com> <56327601.40103@oracle.com> Message-ID: <24f6a8c3-6070-4f64-9128-fc45b562349d@default> Hello Phil, Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8030099/webrev.02/ The test case has been updated as per review comments. Added tests for both Parallel and default collector. Regards, Rajeev Chamyal -----Original Message----- From: Phil Race Sent: 30 October 2015 01:10 To: Rajeev Chamyal Cc: Sergey Bylokhov; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Re: Review request for JDK-8030099 Memory usage of java process increases after pressing start button in test window It is arguably most important to run this with the *default* collector. If that changes to G1 (I think it is at least temporarily so changed in JDK 9) then we will never see problems in the case people end up using. But you obviously also want to test the case that shows the bug. So I would say the best option is to test both : explicit parallel GC and again with default .. even if they are the same there should be no harm done. You may want to increase timeout if running twice but you will have to verify that. -phil. On 10/29/2015 05:48 AM, Rajeev Chamyal wrote: > Hello Sergey, > > Please review the updated test case. > Webrev : http://cr.openjdk.java.net/~rchamyal/8030099/webrev.01/ > > As this issue is reported for Parallel GC collector. So, I have added -XX:+UseParallelGC to child process VM arguments in test case. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Sergey Bylokhov > Sent: 29 October 2015 02:17 > To: Rajeev Chamyal; Philip Race > Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net > Subject: Re: Review request for JDK-8030099 Memory usage of java > process increases after pressing start button in test window > > Thanks for clarification. > The fix looks fine. > > On 20.10.15 11:49, Rajeev Chamyal wrote: >> Hello Sergey, >> >> I mentioned incorrectly that JDK8 is using CMS as default garbage collector. JDK 8 uses Parallel GC as default collector. >> >> Following are the results with Parallel GC as default collector in JDK9. >> >> Max java process size before fix while running test case(webrev) : 220MB (approx.) JDK version build 1.9.0-ea-b86. >> Max java process size after fix while running test case(webrev) : 130MB(approx.). JDK9 version 1.9.0-internal-_2015_10_15_21_12-b00. >> >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Rajeev Chamyal >> Sent: 20 October 2015 12:10 >> To: Sergey Bylokhov; Philip Race >> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net >> Subject: RE: Review request for JDK-8030099 Memory usage of java >> process increases after pressing start button in test window >> >> Hello Sergey, >> >> Below are my observation while testing the fix. >> >> Max java process size before fix while running test case(webrev) : 170MB (approx.) JDK version build 1.9.0-ea-b86. >> Max java process size after fix while running test case(webrev) : 165MB(approx.). JDK9 version 1.9.0-internal-_2015_10_15_21_12-b00. >> The results are not consistent always in both cases. >> >> We cannot compare these results with JDK8 because it uses CMS collector as default garbage collector while JDK9 is using G1 collector. >> G1 collector is giving better results because it does heap compaction as well. >> >> We are using different reference types in different files ( files registering instances with Disposer) e.g. StrikeCache uses SoftReferences. >> >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: 20 October 2015 03:54 >> To: Philip Race; Rajeev Chamyal >> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net >> Subject: Re: Review request for JDK-8030099 Memory usage of java >> process increases after pressing start button in test window >> >> On 20.10.15 0:50, Philip Race wrote: >>> The code change looks fine. The test is delightfully complicated. >> I still have not got a benefit of weak references in this use case. Does it mean that weak are always better? If yes, then we should at some point change default policy for all other cases as well. >> >>> Did you run it under jtreg ? >>> >>> -phil. >>> >>> >>> On 10/19/15, 5:10 AM, Rajeev Chamyal wrote: >>>> Hello, >>>> >>>> Please review the following fix for Jdk9: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030099 >>>> >>>> Webrev:http://cr.openjdk.java.net/~rchamyal/8030099/webrev.00/ >>>> >>>> >>>> Issue: The memory usage of java process goes on increasing if we >>>> call ShellFolder:listFiles API >>>> >>>> aggressively on some folder with large number of files/folders. >>>> >>>> Cause: Win32ShellFolder class registers its instances and native >>>> data with sun.java2d.Disposer class for later disposal. >>>> Win32ShellFolder instances are getting registered as >>>> PhantomReferences with Disposer and are not getting cleared immediately. >>>> This leads to increase of memory usage by java process. >>>> Fix: Instead of registering the complete Win32ShellFolder object >>>> reference with disposer we are now adding only a sentinel object >>>> and also using sun.java2d.Disposer :: addObjectRecord API which >>>> adds the references as WeakReferences. >>>> Regards, >>>> Rajeev Chamyal >>>> >> >> -- >> Best regards, Sergey. >> > > -- > Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Nov 2 20:09:01 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 2 Nov 2015 23:09:01 +0300 Subject: [9] Review Request for 8081722: Provide public API for file hierarchy provided by sun.awt.shell.ShellFolder In-Reply-To: <563265D5.8010205@oracle.com> References: <562E2FD1.1070301@oracle.com> <563265D5.8010205@oracle.com> Message-ID: <5637C2DD.6060801@oracle.com> On 29.10.15 21:30, Phil Race wrote: > We should specify what happens if you pass in to get(String) > a) null > b) an unrecognised name. > > Would it make sense to define string constants on FileSystemView > as otherwise people have to spell these exactly right without compiler > help ? > > Also I expect (hope!) that we do not assert any privileges here so there > will be a SecurityException if the caller does not have the necessary > permissions. > That should be documented. > > I find it odd that isLink(File) catches FNFE and just returns "false" > like this > was a normal file. Why is that ? In fact I find it particularly odd since > getLinkLocation() *does* throw FNFE if it does not exist. I guess the new code should follow the rules which are used by other methods in the same class, most of them catch FNFE and return some default value. Also most of them returns default value if the passed File is null. Anyway I think that NPE is better than IAE. At least we should discuss this. I am not sure why this methods are static unlike old/others methods(). public static Object get(String key) {} Probably this method too flexible? What kind of use case for this method inside the users application? How the user will know which parameters to use in a cross-platform manner? For example "fileChooserDefaultFolder" property already covered by FileSystemView.getDefaultDirectory(), the "roots" is covered by getRoots(). > > Also the docs casually say > "a shell interpreted link" and "platform shell" without explaining > what they mean by a shell. Should this term be used at all or > should the docs describe this in some other words ? > > getLinkLocation says > > "Returns a file linked to the specified file if the specified file" > > What that reads like to me is that you get back a link if > you pass in a regular file, whereas (I believe) you mean > the opposite. > > I think you mean : > "Returns the regular file referenced by the specified link file" > > I also note that one of the uses we located was of > ShellFolder.getShellFolder(File) > That internal API returns a ShellFolder but it we expose that it would > have to > be the java.io.File superclass I expect. > > -phil. > > > > > > > > > > -phil. > > > On 10/26/2015 06:51 AM, Semyon Sadetsky wrote: >> Hello, >> >> Please review fix for JDK9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8081722 >> webrev: http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.00 >> >> As the solution it is suggested to have 3 new static methods in the >> javax.swing.filechooser.FileSystemView class. Those methods proxy >> sun.awt.shell.ShellFolder calls and it is enough to cover NetBeans >> request. getShellFolder() method is not added because it returns the >> ShellFolder instance which is not for public use under the proposed >> approach. >> The CCC request will be rework when the fix is approved. >> >> --Semyon > -- Best regards, Sergey. From avik.niyogi at oracle.com Tue Nov 3 09:20:07 2015 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Tue, 3 Nov 2015 14:50:07 +0530 Subject: Review request for 7124218: Space should select cell in the JTable Message-ID: <706FBB8F-3206-4F11-B92E-C155BD2C2AE0@oracle.com> Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-7124218 Webrev: http://cr.openjdk.java.net/~rchamyal/avik/7124218/webrev.00/ Issue: "Space should select cell in the JTable" is being expected for Look and Feels (and OS) where key-bindings are different. Cause: Keybindings expected in the test case are not taking native key-bindings into account. Fix: Recreated test case with appropriate cases for all required OS to account for supported native, non-native and cross-platform Look and Feels. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Tue Nov 3 09:07:05 2015 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Tue, 3 Nov 2015 14:37:05 +0530 Subject: Review request for 7124218: Space should select cell in the JTable Message-ID: Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-7124218 Webrev: http://cr.openjdk.java.net/~rchamyal/avik/7124218/webrev.00/ Issue: "Space should select cell in the JTable" is being expected for Look and Feels (and OS) where key-bindings are different. Cause: Keybindings expected in the test case are not taking native key-bindings into account. Fix: Recreated test case with appropriate cases for all required OS to account for supported native, non-native and cross-platform Look and Feels. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Wed Nov 4 09:20:53 2015 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Wed, 4 Nov 2015 14:50:53 +0530 Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX Message-ID: Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8132770 Webrev: http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.00/ Issue: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX where non-eligible Look and Feels are not taken into account. Cause: TestCase flow for non-Basic JRadioButton UI such as Aqua, Nimbus and GTK have different focus traversal track as compared to the rest and require different test case flow with regards to focus owner. Fix: Modified test case with appropriate deviant test case for Look and Feels which are not eligible for focus traversal as expected previously in test file. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Fri Nov 6 09:38:33 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Fri, 6 Nov 2015 01:38:33 -0800 (PST) Subject: Review request for JDK-8079253 Test javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails Message-ID: <8311be49-f2d6-4698-bec7-f139293d6b40@default> Hello All, Please review the following fix for Jdk9: Bug: https://bugs.openjdk.java.net/browse/JDK-8079253 Webrev: http://cr.openjdk.java.net/~rchamyal/8079253/webrev.00/ Issue: The test case shortens two text labels and writes the resulting same strings to buffered images. On Ubuntu linux the image pixels are not matching. Cause: The frame size in Ubuntu is coming different every time which is resulting in different size images and resulting into issue. Bug HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8073710"JDK-8073710 is already reported for this issue. Also we need set the opaque property on label component which makes sure that all of the bits contained within component's rectangular bounds are painted. Fix: Setting the default look and feel decoration for frame size issue and making label opaque. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Nov 6 10:09:15 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 06 Nov 2015 13:09:15 +0300 Subject: Review request for JDK-8079253 Test javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails In-Reply-To: <8311be49-f2d6-4698-bec7-f139293d6b40@default> References: <8311be49-f2d6-4698-bec7-f139293d6b40@default> Message-ID: <563C7C4B.5030101@oracle.com> On 11/6/2015 12:38 PM, Rajeev Chamyal wrote: > Hello All, > > Please review the following fix for Jdk9: > > Bug:https://bugs.openjdk.java.net/browse/JDK-8079253 > > Webrev:http://cr.openjdk.java.net/~rchamyal/8079253/webrev.00/ > > > Issue: The test case shortens two text labels and writes the resulting > same strings to buffered images. > > On Ubuntu linux the image pixels are not matching. > > > Cause: The frame size in Ubuntu is coming different every time which is resulting in different size images and resulting into issue. > BugJDK-8073710 is already reported for this issue. > Also we need set the opaque property on label component which makes sure that all of the bits contained within component?s rectangular bounds are painted. Should the original test (without the proposed changes) work if JDK-8073710 is fixed? If yes, the current issue should be closed as duplicate of the JDK-8073710. Thanks, Alexandr. > > Fix: Setting the default look and feel decoration for frame size issue and making label opaque. > > Regards, > Rajeev Chamyal > From rajeev.chamyal at oracle.com Fri Nov 6 10:21:02 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Fri, 6 Nov 2015 02:21:02 -0800 (PST) Subject: Review request for JDK-8079253 Test javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails In-Reply-To: <563C7C4B.5030101@oracle.com> References: <8311be49-f2d6-4698-bec7-f139293d6b40@default> <563C7C4B.5030101@oracle.com> Message-ID: Hello Alexander, Thanks for the review. We need to set the opaque property on the label as well. Regards, Rajeev Chamyal -----Original Message----- From: Alexander Scherbatiy Sent: 06 November 2015 15:39 To: Rajeev Chamyal Cc: Sergey Bylokhov; swing-dev at openjdk.java.net Subject: Re: Review request for JDK-8079253 Test javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails On 11/6/2015 12:38 PM, Rajeev Chamyal wrote: > Hello All, > > Please review the following fix for Jdk9: > > Bug:https://bugs.openjdk.java.net/browse/JDK-8079253 > > Webrev:http://cr.openjdk.java.net/~rchamyal/8079253/webrev.00/ > > > Issue: The test case shortens two text labels and writes the resulting > same strings to buffered images. > > On Ubuntu linux the image pixels are not matching. > > > Cause: The frame size in Ubuntu is coming different every time which is resulting in different size images and resulting into issue. > BugJDK-8073710 is already reported for this issue. > Also we need set the opaque property on label component which makes sure that all of the bits contained within component's rectangular bounds are painted. Should the original test (without the proposed changes) work if JDK-8073710 is fixed? If yes, the current issue should be closed as duplicate of the JDK-8073710. Thanks, Alexandr. > > Fix: Setting the default look and feel decoration for frame size issue and making label opaque. > > Regards, > Rajeev Chamyal > From alexandr.scherbatiy at oracle.com Fri Nov 6 10:27:44 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 06 Nov 2015 13:27:44 +0300 Subject: Review request for JDK-8079253 Test javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails In-Reply-To: References: <8311be49-f2d6-4698-bec7-f139293d6b40@default> <563C7C4B.5030101@oracle.com> Message-ID: <563C80A0.2020408@oracle.com> On 11/6/2015 1:21 PM, Rajeev Chamyal wrote: > Hello Alexander, > > Thanks for the review. > We need to set the opaque property on the label as well. I see. The idea is that we do not fix tests itself so they just work. The tests are necessary to find as much issues as possible. If this test requires that the JDK-8073710 would be fixed first we need to leave it and wait for the JDK-8073710 fix. The issue the the opaque property can be added as a comment to the JDK-8073710 bug so it will be updated with the JDK-8073710 fix. Thanks, Alexandr. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexander Scherbatiy > Sent: 06 November 2015 15:39 > To: Rajeev Chamyal > Cc: Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: Review request for JDK-8079253 Test javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails > > On 11/6/2015 12:38 PM, Rajeev Chamyal wrote: >> Hello All, >> >> Please review the following fix for Jdk9: >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8079253 >> >> Webrev:http://cr.openjdk.java.net/~rchamyal/8079253/webrev.00/ >> >> >> Issue: The test case shortens two text labels and writes the resulting >> same strings to buffered images. >> >> On Ubuntu linux the image pixels are not matching. >> >> >> Cause: The frame size in Ubuntu is coming different every time which is resulting in different size images and resulting into issue. >> BugJDK-8073710 is already reported for this issue. >> Also we need set the opaque property on label component which makes sure that all of the bits contained within component's rectangular bounds are painted. > Should the original test (without the proposed changes) work if > JDK-8073710 is fixed? > If yes, the current issue should be closed as duplicate of the JDK-8073710. > > Thanks, > Alexandr. >> >> Fix: Setting the default look and feel decoration for frame size issue and making label opaque. >> >> Regards, >> Rajeev Chamyal >> From Sergey.Bylokhov at oracle.com Fri Nov 6 11:16:31 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 6 Nov 2015 14:16:31 +0300 Subject: Review request for JDK-8079253 Test javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails In-Reply-To: <563C80A0.2020408@oracle.com> References: <8311be49-f2d6-4698-bec7-f139293d6b40@default> <563C7C4B.5030101@oracle.com> <563C80A0.2020408@oracle.com> Message-ID: <563C8C0F.4010307@oracle.com> On 06.11.15 13:27, Alexander Scherbatiy wrote: > The issue the the opaque property can be added as a comment to the > JDK-8073710 bug so it will be updated with the JDK-8073710 fix. I guess that the opaque property is unrelated to the size and is unrelated to the JDK-8073710, we can fix it here but with notice in jbs that it still fails because of JDK-8073710. -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri Nov 6 13:39:20 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 06 Nov 2015 16:39:20 +0300 Subject: [9] Review Request for 8140527: JInternalFrame has incorrect title button width In-Reply-To: <56309B44.7020307@oracle.com> References: <56309B44.7020307@oracle.com> Message-ID: <563CAD88.0@oracle.com> On 10/28/2015 12:54 PM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8140527 > webrev: http://cr.openjdk.java.net/~ssadetsky/8140527/webrev.00/ > > Title buttons under Widows Classic LnF got their sizes from the XP > desktop theme in which button width can be bigger than height. The > proposed fix forces title buttons to be square and to fit the frame > title in height. It looks like the "InternalFrame.titleButtonWidth" property can be set by a user in UIManager. Should not the updated width value be used in this case instead of the height property? The test uses internal OSInfo class. The appropriate @modules tag should be done in this case for the jake build. Thanks, Alexandr. From alexandr.scherbatiy at oracle.com Fri Nov 6 14:11:29 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 06 Nov 2015 17:11:29 +0300 Subject: Review request for JDK-6288609 JInternalFrame.setDefaultCloseOperation() interferes with "close" behavior In-Reply-To: References: Message-ID: <563CB511.70809@oracle.com> On 10/29/2015 10:41 AM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following fix for Jdk9: > > *Bug*:https://bugs.openjdk.java.net/browse/JDK-6288609 > > *Webrev*:http://cr.openjdk.java.net/~rchamyal/6288609/webrev.00/ > > > *Issue*: On disposing the Top level JInternalFrame focus is not > shifting to the JInternalFrame below it. > > *Cause*: Dispose method is changing the selection of currently closing > frame and then it calls the DefaultDeskTopManager:closeFrame which > > finds the JInternalFrame below the closing frame based on selection of > the closing frame and then shifts the focus to frame below it. > > Since selection is already changed by dispose method > DefaultDeskTopManager:closeFrame is unable to find reference to > previous frame. > > *Fix*: Removed the selection change code from Dispose method. Are there any cases that the JInternalFrame is still selected after the IS_CLOSED_PROPERTY is fired in the dispose() method so it is still necessary to set the selection to false? Thanks, Alexandr. > > Regards, > Rajeev Chamyal From alexander.zvegintsev at oracle.com Fri Nov 6 17:20:43 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 6 Nov 2015 20:20:43 +0300 Subject: [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager In-Reply-To: <56050F19.1030102@oracle.com> References: <55B7BAEB.5050501@oracle.com> <55ED7805.9040602@oracle.com> <55ED9A43.1010301@oracle.com> <55EDA5B3.8060309@oracle.com> <55EE9C1A.2040600@oracle.com> <55EEA9D1.8020805@oracle.com> <55EEAF07.7010101@oracle.com> <55EEB348.7040002@oracle.com> <55EEC141.7050104@oracle.com> <55EEC212.4060907@oracle.com> <55EEFAA3.300@oracle.com> <55F16D2A.90709@oracle.com> <55F17A1C.10909@oracle.com> <55F17B73.6020905@oracle.com> <55F18EB4.3020703@oracle.com> <55F1900A.7070204@oracle.com> <55F1A10B.9060106@oracle.com> <55F1A5DA.1030008@oracle.com> <55F1B03C.9040706@oracle.com> <55F2ED8B.4010406@oracle.com> <55F30030.7030402@oracle.com> <55F8363B.2000306@oracle.com> <55F87367.6040407@oracle.com> <55F9468E.3010705@oracle.com> <55F97936.8050105@oracle.com> <55FC32F1.7020303@oracle.com> <55FC3A50.3060001@oracle.com> <55FFBF6E.8030502@oracle.com> <55FFCBB3.1030302@oracle.com> <5601553D.4000801@oracle.com> <56015FE8.6020505@oracle.com> <56043266.2000907@oracle.! com> <56050F19.1030102@oracle.com> Message-ID: <563CE16B.60208@oracle.com> +1 -- Thanks, Alexander. On 09/25/2015 12:08 PM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 9/24/2015 8:27 PM, Semyon Sadetsky wrote: >> >> >> On 9/22/2015 5:04 PM, Semyon Sadetsky wrote: >>> >>> >>> On 9/22/2015 4:18 PM, Alexander Scherbatiy wrote: >>>> On 9/21/2015 12:19 PM, Semyon Sadetsky wrote: >>>>> >>>>> >>>>> On 9/21/2015 11:27 AM, Alexandr Scherbatiy wrote: >>>>>> 18.09.2015 19:22, Semyon Sadetsky ?????: >>>>>>> >>>>>>> >>>>>>> On 9/18/2015 6:51 PM, Alexander Scherbatiy wrote: >>>>>>>> On 9/16/2015 5:14 PM, Semyon Sadetsky wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/16/2015 1:38 PM, Alexander Scherbatiy wrote: >>>>>>>>>> On 9/15/2015 10:37 PM, Semyon Sadetsky wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9/15/2015 6:16 PM, Alexander Scherbatiy wrote: >>>>>>>>>>>> On 9/11/2015 7:24 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The deadlock that you described exists only because >>>>>>>>>>>> AbstractDocument uses locks in the >>>>>>>>>>>> UndoableEdit.undo()/redo() methods. >>>>>>>>>>>> Applications that use UndoManager and do not use lock in >>>>>>>>>>>> the UndoableEdit.undo()/redo() methods do not have >>>>>>>>>>>> deadlock. They worked fine before the fix and can lost data >>>>>>>>>>>> consistency after the fix. This is definitely the regression. >>>>>>>>>>> You mean scenario when a document that does not support >>>>>>>>>>> synchronization but anyway is modified from several threads. >>>>>>>>>>> You can expect that such scenario is functional only if such >>>>>>>>>>> document is a single atomic field. >>>>>>>>>>> I updated the fix >>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.04/ >>>>>>>>>>> take it into account. >>>>>>>>>> >>>>>>>>>> This looks better. There are just some comments: >>>>>>>>>> - The 'inProgress' variable in >>>>>>>>>> UndoManager.undo()/redo()/undoOrRedo() methods should have >>>>>>>>>> synchronization. >>>>>>>>>> Is it possible to move 'if (inProgress)' check into >>>>>>>>>> tryUndoOrRedo() method similarly to as it was used in the >>>>>>>>>> version 2 of the fix? >>>>>>>>>> - UndoManager line 489: why not to use the original check >>>>>>>>>> from the undoOrRedo() method "if (indexOfNextAdd == >>>>>>>>>> edits.size())" to pick up undo or redo action? >>>>>>>>>> - UndoManager line 516: An undoable edit can be requested >>>>>>>>>> two times for the ANY action because the 'undo' variable can >>>>>>>>>> have old value in the second synchronized block. >>>>>>>>>> Even the logic is right it is better to take an edit >>>>>>>>>> based on the 'action' variable. >>>>>>>>>> - UndoManager.undoOrRedo() throws CannotUndoException now >>>>>>>>>> instead of CannotRedoException if the redo action is not >>>>>>>>>> possible. >>>>>>>>>> - It is possible to get rid of the 'done ' variable in >>>>>>>>>> UndoManager.tryUndoOrRedo() just simply have an infinity loop. >>>>>>>>>> - It is possible to use Boolean values TRUE, FALSE or null >>>>>>>>>> for three-state logic. But it is up to you to choose enums or >>>>>>>>>> Boolean in the fix. >>>>>>>>>> >>>>>>>>> I made the changes: >>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.05/ >>>>>>>>> except for the last one. Actually triple Boolean logic is a >>>>>>>>> bad style. >>>>>>>> >>>>>>>> >>>>>>>> There are two main synchronized block in the >>>>>>>> tryUndoOrRedo() method: one to look up an undoable edit lock >>>>>>>> and the second which use the undoable edit lock. >>>>>>>> In the version 02 of the fix the original code from undo() >>>>>>>> and redo() methods were moved to these two blocks. >>>>>>>> It is not clear why don't you want to do the same (just >>>>>>>> call tryUndoOrRedo() with necessary argument for all >>>>>>>> UndoManager.undo()/redo()/undoOrRedo() methods) in the latest fix? >>>>>>>> >>>>>>>> Splitting logic like: >>>>>>>> ------------------- >>>>>>>> 420 public void undo() throws CannotUndoException { >>>>>>>> 421 if (!tryUndoOrRedo(Action.UNDO)) { >>>>>>>> 422 synchronized (this) { >>>>>>>> 423 super.undo(); >>>>>>>> 424 } >>>>>>>> 425 } >>>>>>>> 426 } >>>>>>>> ------------------- >>>>>>>> always have a question that before the fix the super.undo() >>>>>>>> was called only for '!inProgress' condition but now the >>>>>>>> 'inProgress' can be changed when super.undo() is called. >>>>>>>> >>>>>>> inProgress can be changed when super.undo() is called because it >>>>>>> is protected by synchronized block. >>>>>>> Imagine that undo() is called with inProgress = true, then it is >>>>>>> blocked by the concurrent document change, and after the retry >>>>>>> it finds inProgress= false, so it cannot undo by usual way >>>>>>> anymore, because the UndoManager is converted into a single edit >>>>>>> and it should undo using super.undo(). >>>>>> >>>>>> I am talking about slightly different thing. >>>>>> This is the code for the undo() method before the fix. >>>>>> ------------------- >>>>>> 410 public synchronized void undo() throws >>>>>> CannotUndoException { >>>>>> 411 if (inProgress) { >>>>>> 412 UndoableEdit edit = editToBeUndone(); >>>>>> ... >>>>>> 416 undoTo(edit); >>>>>> 417 } else { >>>>>> 418 super.undo(); >>>>>> 419 } >>>>>> 420 } >>>>>> ------------------- >>>>>> >>>>>> Checking the 'inProgress' variable and calling undoTo(edit) and >>>>>> super.undo() is done under the same synchronized block. >>>>>> >>>>>> Let's slightly modify the code: >>>>>> ------------------- >>>>>> public void undo() throws CannotUndoException { >>>>>> >>>>>> boolean res = true; >>>>>> >>>>>> synchronized (this) { >>>>>> if (inProgress) { >>>>>> UndoableEdit edit = editToBeUndone(); >>>>>> ... >>>>>> undoTo(edit); >>>>> It is not possible to execute undoTo() here because it will cause >>>>> the deadlock we are trying to fix. >>>> >>>> May be with the updated sample it would be cleaner. >>>> This is just a some method which uses a synchronization: >>>> ---------------------- >>>> public synchronized void someMethod() { >>>> if (inProgress) { >>>> // do something >>>> } else { >>>> // do something else >>>> } >>>> } >>>> ---------------------- >>>> >>>> This is an updated method: >>>> ------------------- >>>> public void someMethod() { >>>> >>>> boolean res = true; >>>> >>>> [some synchronization] >>>> if (inProgress) { >>>> // do something >>>> } else { >>>> res = false; >>>> } >>>> [end of some synchronization] >>>> >>>> >>>> [some synchronization] >>>> if (!res) { >>>> do something else >>>> } >>>> [end of some synchronization] >>>> } >>>> ------------------- >>>> >>>> The problem with the updated method is that inProgress variable >>>> can have a value different from 'res' and the 'do something else' >>>> action can be executed even inProgress is true. >>> InProgress goes only one direction true->false. Once it detected as >>> false the super method should be called always. >> Alexander, the version as per our off-line discussion: >> http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.06/ >>>> >>>>>> } else { >>>>>> res = false; >>>>>> } >>>>>> } >>>>>> >>>>>> synchronized (this) { >>>>>> if (!res) { >>>>>> super.undo(); >>>>>> } >>>>>> } >>>>>> } >>>>>> ------------------- >>>>>> >>>>>> Now the 'inProgress' variable checking and undoTo() is done on >>>>>> the first synchronized block. >>>>>> The result of the inProgress is used in the second synchronized >>>>>> block. But the 'inProgress' variable >>>>>> can be changed between these two blocks and we can't relay on >>>>>> the 'res' value. >>>>>> Instead of 'res' the original 'inProgress' value should be >>>>>> checked in the second synchronized block and if it is true the >>>>>> undoTo(edit) should be called again instead of super.undo(). >>>>>> >>>>> Above you provided the code logic bore the fix which is reworked >>>>> because it does not work. Why do we need to discuss it? >>>> >>>> We need to discuss this because the inProgress variable in your >>>> latest fix is used exactly as in the provided sample. >>>> UndoManager line: 473 tryUndoOrRedo(action) returns false if >>>> inProgress is false. >>>> UndoManager line: 422 super.undo() is called if >>>> tryUndoOrRedo(action) returns false despite the real 'inProgress' >>>> variable value. >>>> >>>> Thanks, >>>> Alexandr. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>> Also synchronization is needed to provide coherency >>>>>>>>>>>>>>>>> with the state of the document. If those two are not >>>>>>>>>>>>>>>>> provided the document can be corrupted. This is enough >>>>>>>>>>>>>>>>> most usages. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I still think that updating the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableManager for one particular >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstarctManager class can be made >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only after investigation of other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possibilities. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You could start with choosing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior which you want to achieve or >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to keep, like: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - fix the deadlock >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - atomic undo() method >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - serialization >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - immediate roll back action >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - abstract document consistency >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> after undo() action >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - ... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We need to pay attention to the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deadlock at first of cause. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Serialization and consistency are >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> achieved. Any concrete doubts? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> immediate roll back action -- ?what is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "if user starts a long edit >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operation and press undo after that he >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> expects when the long edit is finished >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it will be rolled back immediately." - >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what ever does it mean. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Got it. It will work within the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fairness. We have discussed this allready. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I sacrificed undo/redo call atomicity >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because you did not like doc >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> references in undo manager. I think it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is not important for the most >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multithreaded undo/redo scenarios. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Could you give more details about >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it. Which doc references do you mean? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Your statement a dozen iterations ago >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was: "There should be a way to solve >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> these problems without storing links of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> external classes inside the UndoManager." >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I guess you used "link" term for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> references. I would recommend to use >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> standard terminology: reference to the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> object, dependency on the class, etc... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to avoid misunderstanding. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Usually "link" is in a browser document >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or a tool that produces executables >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> after compilation. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and look which of the following >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> approaches can better solve them >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (where the fist is more preferred and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the last is less preferred case): >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - using UndoManager as is without >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> adding links from some specific >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> classes to it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - provide an API for UndoManager to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work with UndoableEdit-s which have >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization for undo/redo methods >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - adding links of external classes >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> directly to UndoManager >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What do you mean under link term? A >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reference or dependency? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are two options. If >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager is a class designed to be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only used with the AbstractDocument and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> placed in the javax.swing.text package >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it definitly can have special code to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> handle an abstract document instance in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a special way. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If UndoManager is a general purpose >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> class, it looks strange that it handles >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some special classes in different way >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as all others. It usually mean that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> there are some design problems in this >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> class. That is why I just asked to look >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at other ways at first. Only if other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> solutions are not suitable it has sense >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to look at the way that you are provided. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Correct. I introduced extra dependency. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is optional, but anyway. Of cause >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> there is a design problem in undo >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> javax.swing.undo package. But I cannot >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rewrite the API because we will get a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compatibility problem then. I mentioned >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this several times in this thread. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We are constrained by compatibility >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> requirements. UndoManager is a broadly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used class we cannot change the API so >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> drastically. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think that you can generalize your >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> solution just adding an internal >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> interface like sun.swing.UndoableEditLock. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Every UndoableEdit which implements >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this interface can provide a lock for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its synchronization. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If this will work it can be made >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public in some days so other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application can also have proper >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization for their undo/redo >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK. I added it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.02/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - We can return a public class that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implements an internal interface, but we >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can't expose an internal API in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> public class definition. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> May be it is possible to wrap an >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEdit to the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEditLockSupport in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEditEvent or in some other place. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - The similar code is used both in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager.undo() and redo() methods. Is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it possible to move this code to one >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method that does undo or redo depending >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on the given argument? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK. accepted. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.03/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> - UndoManager.undo/redo methods >>>>>>>>>>>>>>>>>>>>>>>>>>>> In your previous fix inProgress >>>>>>>>>>>>>>>>>>>>>>>>>>>> variable and the super call were used under >>>>>>>>>>>>>>>>>>>>>>>>>>>> the lock. It may leads to some >>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization issues if you decide to >>>>>>>>>>>>>>>>>>>>>>>>>>>> omit it. >>>>>>>>>>>>>>>>>>>>>>>>>>>> - UndoManager.tryUndoOrRedo() >>>>>>>>>>>>>>>>>>>>>>>>>>>> It is possible to get rid of 'done' >>>>>>>>>>>>>>>>>>>>>>>>>>>> variable just using an infinity loop and >>>>>>>>>>>>>>>>>>>>>>>>>>>> return the exact result where the loop is >>>>>>>>>>>>>>>>>>>>>>>>>>>> terminated. >>>>>>>>>>>>>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstractDocument.DefaultDocumentEventUndoableWrapper >>>>>>>>>>>>>>>>>>>>>>>>>>>> implements both UndoableEdit and >>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEditLockSupport interfaces but >>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEditLockSupport already extends >>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEdit. >>>>>>>>>>>>>>>>>>>>>>>>>>>> - "@since 1.9" javadoc for >>>>>>>>>>>>>>>>>>>>>>>>>>>> DefaultDocumentEventUndoableWrapper.lockEdit()/unlockEdit() >>>>>>>>>>>>>>>>>>>>>>>>>>>> methods really belongs to the >>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEditLockSupport methods. >>>>>>>>>>>>>>>>>>>>>>>>>>>> In this case there is no need for >>>>>>>>>>>>>>>>>>>>>>>>>>>> {@inheritDoc} tag. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "adding links of external classes >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> directly to UndoManager" - Sorry, did >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not catch what are you about? Could >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you clarify? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is a mistake in your >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> scenario steps: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fireUndoableEditUpdate() is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> called before the freeing the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lock (see >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstractDocument.handleInsertString() >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yet another argument do not >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do this from the user >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> experience: if user starts >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a long edit operation and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> press undo after that he >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> expects when the long edit >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is finished it will be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rolled back immediately. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is not true. The >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> first process adds his undo >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> edit to the UndoManager. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> While a user trying to press >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo the second long process >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can be started. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is what led to this >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> issue because when undo is in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> progress document writing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should be allowed. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry but I didn't see why is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "It not true"? Then what is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your expectation when you >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> press undo button while edit >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is not finished yet and there >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is no way to abort it? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It would be good if it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> works as you described. But it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not work in this way with >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or without your fix. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo() action has >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> writeLock in AbstractDocument >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and because of it is always >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed after insert string >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> action. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If a user sees that undo >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is available, he can call it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but the second long >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> insertString process can start >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> earlier and acquire the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> writeLock. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is what we are going to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fix. And this does work after >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this fix. Undo call will be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> blocked by the long edit until >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the last is done without any >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deadlocks. And when edit is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> done undo() will acquire the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lock and prevent any new edits >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> until undo() is done. Please >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide a scenario when in your >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> opinion it does not wok. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The first process starts >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for 5 minutes. When it is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> finished a user sees that he can >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> press undo. While he is pressing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo button, the second long >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> process starts for 10 minutes >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and acquire the write lock. The >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user presses undo but he needs >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to wait 10 more minutes until >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the second process is finished. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, if two or more threads >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are waiting for a monitor it is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not determined which one will get >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the control after the signal. To >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> order that the ReentrantLock API >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> could be used but >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstractDocument uses wait/notify >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for locking. I think it is not >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> worth to dig so deep. It does not >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cause any issues >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue that is considered >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is "if user starts a long edit >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operation and press undo after >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that he expects when the long edit >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is finished it will be rolled back >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> immediately." >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you are agree that it is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not always possible to do the roll >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> back "immediately" there is no >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> point to discussion. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I agree. On that level it is not >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible to predict the order >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> exactly in such scenario. But the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state of the document will be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistent. And it is possible to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have it predictable using lock >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fairness. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because undo() always get the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> last edit anyway. If it will be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> important for somebody to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> preserve the execution order on >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that level of details we will fix >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So undo should be executed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> after the edit is fully >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> performed because the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding UndoableEdit >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which undos this edit can >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be produced only after the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> edit is done. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think at first we need to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> look on the situation >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> externally rather than >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> concentrate on >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation questions >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> like in which class do >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> references go. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, please look on this >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> situation from a user point >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of view which wants to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implement simple Java Painter. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But could you describe this >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> scenario? Just steps when >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this simple Painter fails >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> under the proposed fix?I >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, if this Painter's >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> content is not an >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstarctDocument it will work >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as before the fix. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any application that uses >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager and wants to have >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the same synchronization (have >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the same lock both for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEdit adding and undo() >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method execution) will have >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the same deadlock problems. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As I have already written: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Consider someone writes >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Java Painter application where >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it is possible to draw lines >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and images and uses >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager for undo/redo >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> He might want that it was >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible to work with copied >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> images. He can get lock on >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ctrl+v action, process an >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> image, prepare UndoableEdit >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and notify the UndoManager. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> He also can use lock/unlock >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the undo action to have a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistent state with the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processed image. If someone >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calls undo action during the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> image processing and gets a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deadlock does it mean that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> link from Java Painter need to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be added to the UndoManager? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --------------- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Still do not understand the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> steps for your Painter >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> scenario. A link (reference?) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can be added if it is required >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to implement functionality. If >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the content is not an >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstarctDocument it may be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required to implement custom >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager to support the same >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What is the difference >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> between the AbstractDocument and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> other classes (in Swing or user >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined)? Do you mean that the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager is intended only to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be used with AbstractDocument >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and it shouldn't be used in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> other cases where undo/redo >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actions are required for non >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> text data? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, undo manager can be used with >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any classes. But since we have it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assigned to AbstarctDocument so >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> often we need to do our best to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make undo manager working with it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly because users do not >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> like deadlocks usualy. For other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> classes we cannot provide >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization by default >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because there is no API to get >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the lock. So it remains up to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user how to provide the undo >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> manager synchronization with the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> object it controls for other classes >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What we should do just to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that the same deadlock >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can happen in an user applications >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because he wants to use the same >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization both for the data >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processing and for the undo >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> action. If so, there should be two >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> investigations: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Is it possible to achieve the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> requested goals without changing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager? In other words The >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager should be used in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proper way as it is required by >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its design. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. Is it possible to update the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager API to provide >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> functionality that meets new >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> requests? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> With API change it is reachable. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But I would preserve the current >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> API as less constrained. If we add >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some methods for locking we will >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determine the way how a user should >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronize his undoable content. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And user may not need any >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization at all. We should >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> keep in mind this opportunity as well. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Only after this discussion there >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can be a reason to look to other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ways. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think our undo manager >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation do not pretend to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be used as the global undo >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> manager for big complex >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> applications and it cannot cover >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> all possible undo approaches. But >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> some basic functionality can be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provided and it should be usable. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Without edits serialization >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> approach it is not usable for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multithreaded use. So either we >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do not pretend to provide a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multithreaded undo manager and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> remove all synchronize keywords >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from UndoManager class, either we >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> need to support serialization >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> approach which does not cause >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deadlocks. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I don't see a contradiction >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here, could you point on it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> more precisely? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/30/2015 5:27 PM, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexander Scherbatiy >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Consider someone >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> writes Java Painter >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> application where it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is possible to draw >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lines and images and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses UndoManager for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo/redo actions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> He might want that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it was possible to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work with copied >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> images. He can get >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lock on ctrl+v action, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> process an image, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prepare UndoableEdit >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and notify the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> He also can use >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lock/unlock in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo action to have a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistent state with >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the processed image. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If someone calls undo >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> action during the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> image processing and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> gets a deadlock does >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it mean that link from >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Java Painter need to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be added to the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It looks like >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstractDocument >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> violates UndoManager >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> contract when it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> both use lock to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work with >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager and in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the implemented >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo() method. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Tue Nov 10 11:26:04 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 10 Nov 2015 14:26:04 +0300 Subject: Review request for 8133039 Provide public API to sun.swing.UIAction#isEnabled(Object) Message-ID: <5641D44C.5040902@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8133039 webrev: http://cr.openjdk.java.net/~alexsch/8133039/webrev.00 There are two use cases for the requested API: - javax.swing.Action can be only enabled or disabled for all components at once. Sometimes it is necessary that an action was enabled only for some components with required properties. This is now implemented by internal sun.swing.UIAction.isEnabled(Object sender) method. - Wrap an existed action to add new behaviour. For example: ------------------------------------------ /** * Mute an action by doing nothing if the original action is enabled */ private static class MutedAction extends AbstractAction { private final Object sender; private final Action action; public MutedAction(Object sender, Action action) { this.sender = sender; this.action = action; } @Override public void actionPerformed(ActionEvent e) { // muted } @Override public boolean isEnabled() { if(action instanceof sun.swing.UIAction) { // internal API is used return ((sun.swing.UIAction) action).isEnabled(sender); } else { return action.isEnabled(); } } } ------------------------------------------ For more details see the email: http://mail.openjdk.java.net/pipermail/swing-dev/2015-August/004729.html The proposed fix adds public 'accept' method to the javax.swing.Action class: ------------------------------------------ /** * Determines whether the action should be invoked for the specified * component. * * @param component the component to check * @return {@code true} if the action should be invoked for the passed * component */ default boolean accept(JComponent component) { return true; } ------------------------------------------ Thanks, Alexandr. From andrej.golovnin at gmail.com Tue Nov 10 12:10:52 2015 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Tue, 10 Nov 2015 13:10:52 +0100 Subject: Review request for 8133039 Provide public API to sun.swing.UIAction#isEnabled(Object) In-Reply-To: <5641D44C.5040902@oracle.com> References: <5641D44C.5040902@oracle.com> Message-ID: Hi Alexander, you patch changes the signature of a public method in SwingUtilities: Current JDK 1731 public static boolean notifyAction(Action action, KeyStroke ks, 1732 KeyEvent event, Object sender, After your change: 1731 public static boolean notifyAction(Action action, KeyStroke ks, 1732 KeyEvent event, JComponent sender, Don't you think it may break binary compatibility? The method exists since JDK 1.3. Best regards, Andrej Golovnin From Sergey.Bylokhov at oracle.com Tue Nov 10 12:12:38 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Nov 2015 15:12:38 +0300 Subject: RfR JDK-8134116, Add more comprehensive fix and regression test for JDK-8133897 In-Reply-To: <56343555.8090308@oracle.com> References: <5626619E.1080902@oracle.com> <563108EB.6050502@oracle.com> <56339AF7.1090809@oracle.com> <56343555.8090308@oracle.com> Message-ID: <5641DF36.3080301@oracle.com> Hi, Pete. On 31.10.15 6:28, Pete Brunet wrote: > http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.03/ My suggestion was to remove all usage of parent.indexOfTab(title) in the code and replace it by parent.indexOfTabComponent(comp). For example: getTabBounds(parent, parent.indexOfTab(getTitle())); Can return incorrect bounds if a few pages will have the same title. Another problem in the fix is that it iterates over components twice: in the getTitle()->(parent.indexOfComponent(component)), and in the parent.indexOfTab(title). Please do not use such comments in the code "// For JDK-8133897/JDK-8134116", this information can be obtained from the mercurial history. >>> I guess it will be better to don't use the title (especially >>> parent.indexOfTab(title)) at all in the our code, except the situation >>> when we should access the title(like in getAccessibleName()). All >>> other cases should be rewritten to use >>> parent.indexOfTabComponent(comp). For example your "private String >>> getTitle() {}" can be implemented like this: >>> >>> return getTitleAt(parent.indexOfTabComponent(comp)); >>> >>> On 20.10.15 18:45, Pete Brunet wrote: >>>> Please review this patch: >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.02/ >>>> >>>> The issue raised/fixed in 8133897 and now resolved in a better fashion >>>> in this patch is caused by an override of the functionality of >>>> JTabbedPane such that its Page inner class title field is not kept up to >>>> date by the overriding code. When the Page title field is empty >>>> getTitleAt is now called so that the overridden getTitleAt will provide >>>> the title. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134116 >>>> >>>> Pete >>>> >>> > -- Best regards, Sergey. From peter.brunet at oracle.com Tue Nov 10 20:52:57 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 10 Nov 2015 14:52:57 -0600 Subject: RfR JDK-8134116, Add more comprehensive fix and regression test for JDK-8133897 In-Reply-To: <5641DF36.3080301@oracle.com> References: <5626619E.1080902@oracle.com> <563108EB.6050502@oracle.com> <56339AF7.1090809@oracle.com> <56343555.8090308@oracle.com> <5641DF36.3080301@oracle.com> Message-ID: <56425929.80502@oracle.com> Thanks Sergey, Please see http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.04/ parent.indexOfTab(title) is replaced with parent.indexOfTabComponent(tabComponent). The regression test runs OK. Pete On 11/10/15 6:12 AM, Sergey Bylokhov wrote: > Hi, Pete. > On 31.10.15 6:28, Pete Brunet wrote: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.03/ > > My suggestion was to remove all usage of parent.indexOfTab(title) in > the code and replace it by parent.indexOfTabComponent(comp). > For example: > getTabBounds(parent, parent.indexOfTab(getTitle())); > Can return incorrect bounds if a few pages will have the same title. > > Another problem in the fix is that it iterates over components twice: > in the getTitle()->(parent.indexOfComponent(component)), and in the > parent.indexOfTab(title). > > Please do not use such comments in the code "// For > JDK-8133897/JDK-8134116", this information can be obtained from the > mercurial history. > > > >>>> I guess it will be better to don't use the title (especially >>>> parent.indexOfTab(title)) at all in the our code, except the situation >>>> when we should access the title(like in getAccessibleName()). All >>>> other cases should be rewritten to use >>>> parent.indexOfTabComponent(comp). For example your "private String >>>> getTitle() {}" can be implemented like this: >>>> >>>> return getTitleAt(parent.indexOfTabComponent(comp)); >>>> >>>> On 20.10.15 18:45, Pete Brunet wrote: >>>>> Please review this patch: >>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.02/ >>>>> >>>>> The issue raised/fixed in 8133897 and now resolved in a better >>>>> fashion >>>>> in this patch is caused by an override of the functionality of >>>>> JTabbedPane such that its Page inner class title field is not kept >>>>> up to >>>>> date by the overriding code. When the Page title field is empty >>>>> getTitleAt is now called so that the overridden getTitleAt will >>>>> provide >>>>> the title. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134116 >>>>> >>>>> Pete >>>>> >>>> >> > > From rajeev.chamyal at oracle.com Wed Nov 11 06:02:20 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Tue, 10 Nov 2015 22:02:20 -0800 (PST) Subject: Review request for JDK-8079253 Test javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails In-Reply-To: <563C80A0.2020408@oracle.com> References: <8311be49-f2d6-4698-bec7-f139293d6b40@default> <563C7C4B.5030101@oracle.com> <563C80A0.2020408@oracle.com> Message-ID: <2c4ea2da-cf65-4427-b10e-f3ab4c331169@default> Hello, Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8079253/webrev.01/ Removed the line JFrame.setDefaultLookAndFeelDecorated as Frame size issue will be fixed once JDK-8073710 is resolved. Updated the bug description for JDK-8079253. Regards, Rajeev Chamyal -----Original Message----- From: Alexander Scherbatiy Sent: 06 November 2015 15:58 To: Rajeev Chamyal Cc: Sergey Bylokhov; swing-dev at openjdk.java.net Subject: Re: Review request for JDK-8079253 Test javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails On 11/6/2015 1:21 PM, Rajeev Chamyal wrote: > Hello Alexander, > > Thanks for the review. > We need to set the opaque property on the label as well. I see. The idea is that we do not fix tests itself so they just work. The tests are necessary to find as much issues as possible. If this test requires that the JDK-8073710 would be fixed first we need to leave it and wait for the JDK-8073710 fix. The issue the the opaque property can be added as a comment to the JDK-8073710 bug so it will be updated with the JDK-8073710 fix. Thanks, Alexandr. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexander Scherbatiy > Sent: 06 November 2015 15:39 > To: Rajeev Chamyal > Cc: Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: Review request for JDK-8079253 Test > javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails > > On 11/6/2015 12:38 PM, Rajeev Chamyal wrote: >> Hello All, >> >> Please review the following fix for Jdk9: >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8079253 >> >> Webrev:http://cr.openjdk.java.net/~rchamyal/8079253/webrev.00/ >> >> >> Issue: The test case shortens two text labels and writes the >> resulting same strings to buffered images. >> >> On Ubuntu linux the image pixels are not matching. >> >> >> Cause: The frame size in Ubuntu is coming different every time which is resulting in different size images and resulting into issue. >> BugJDK-8073710 is already reported for this issue. >> Also we need set the opaque property on label component which makes sure that all of the bits contained within component's rectangular bounds are painted. > Should the original test (without the proposed changes) work if > JDK-8073710 is fixed? > If yes, the current issue should be closed as duplicate of the JDK-8073710. > > Thanks, > Alexandr. >> >> Fix: Setting the default look and feel decoration for frame size issue and making label opaque. >> >> Regards, >> Rajeev Chamyal >> From alexandr.scherbatiy at oracle.com Wed Nov 11 08:04:28 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 11 Nov 2015 11:04:28 +0300 Subject: Review request for JDK-8079253 Test javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails In-Reply-To: <2c4ea2da-cf65-4427-b10e-f3ab4c331169@default> References: <8311be49-f2d6-4698-bec7-f139293d6b40@default> <563C7C4B.5030101@oracle.com> <563C80A0.2020408@oracle.com> <2c4ea2da-cf65-4427-b10e-f3ab4c331169@default> Message-ID: <5642F68C.80102@oracle.com> The fix looks good to me. Thanks, Alexandr. On 11/11/2015 9:02 AM, Rajeev Chamyal wrote: > Hello, > > Please review the updated webrev. > http://cr.openjdk.java.net/~rchamyal/8079253/webrev.01/ > > Removed the line JFrame.setDefaultLookAndFeelDecorated as Frame size issue will be fixed once JDK-8073710 is resolved. > Updated the bug description for JDK-8079253. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexander Scherbatiy > Sent: 06 November 2015 15:58 > To: Rajeev Chamyal > Cc: Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: Review request for JDK-8079253 Test javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails > > On 11/6/2015 1:21 PM, Rajeev Chamyal wrote: >> Hello Alexander, >> >> Thanks for the review. >> We need to set the opaque property on the label as well. > I see. > > The idea is that we do not fix tests itself so they just work. The tests are necessary to find as much issues as possible. > If this test requires that the JDK-8073710 would be fixed first we need to leave it and wait for the JDK-8073710 fix. > > The issue the the opaque property can be added as a comment to the > JDK-8073710 bug so it will be updated with the JDK-8073710 fix. > > Thanks, > Alexandr. > >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Alexander Scherbatiy >> Sent: 06 November 2015 15:39 >> To: Rajeev Chamyal >> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net >> Subject: Re: Review request for JDK-8079253 Test >> javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails >> >> On 11/6/2015 12:38 PM, Rajeev Chamyal wrote: >>> Hello All, >>> >>> Please review the following fix for Jdk9: >>> >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8079253 >>> >>> Webrev:http://cr.openjdk.java.net/~rchamyal/8079253/webrev.00/ >>> >>> >>> Issue: The test case shortens two text labels and writes the >>> resulting same strings to buffered images. >>> >>> On Ubuntu linux the image pixels are not matching. >>> >>> >>> Cause: The frame size in Ubuntu is coming different every time which is resulting in different size images and resulting into issue. >>> BugJDK-8073710 is already reported for this issue. >>> Also we need set the opaque property on label component which makes sure that all of the bits contained within component's rectangular bounds are painted. >> Should the original test (without the proposed changes) work if >> JDK-8073710 is fixed? >> If yes, the current issue should be closed as duplicate of the JDK-8073710. >> >> Thanks, >> Alexandr. >>> >>> Fix: Setting the default look and feel decoration for frame size issue and making label opaque. >>> >>> Regards, >>> Rajeev Chamyal >>> From alexandr.scherbatiy at oracle.com Wed Nov 11 08:25:16 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 11 Nov 2015 11:25:16 +0300 Subject: RfR JDK-8134116, Add more comprehensive fix and regression test for JDK-8133897 In-Reply-To: <56425929.80502@oracle.com> References: <5626619E.1080902@oracle.com> <563108EB.6050502@oracle.com> <56339AF7.1090809@oracle.com> <56343555.8090308@oracle.com> <5641DF36.3080301@oracle.com> <56425929.80502@oracle.com> Message-ID: <5642FB6C.8060502@oracle.com> On 11/10/2015 11:52 PM, Pete Brunet wrote: > Thanks Sergey, Please see > > http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.04/ > > parent.indexOfTab(title) is replaced with > parent.indexOfTabComponent(tabComponent). > > The regression test runs OK. It looks like the check to null component in the getTitleMethod() is not necessary. Even if a page contains a null component the parent.indexOfComponent(null) returns the correct index. So we always asks for a component (it may be null) which definitely is containded in the pages list. Here is a small example: --------------- tabbedPane.addTab("Label 1", new JLabel("Label 1")); tabbedPane.addTab("Null", null); tabbedPane.addTab("Label 2", new JLabel("Label 2")); System.out.println("index of null component: " + tabbedPane.indexOfComponent(null)); // returns index 1 --------------- Thanks, Alexandr. > > Pete > > On 11/10/15 6:12 AM, Sergey Bylokhov wrote: >> Hi, Pete. >> On 31.10.15 6:28, Pete Brunet wrote: >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.03/ >> My suggestion was to remove all usage of parent.indexOfTab(title) in >> the code and replace it by parent.indexOfTabComponent(comp). >> For example: >> getTabBounds(parent, parent.indexOfTab(getTitle())); >> Can return incorrect bounds if a few pages will have the same title. >> >> Another problem in the fix is that it iterates over components twice: >> in the getTitle()->(parent.indexOfComponent(component)), and in the >> parent.indexOfTab(title). >> >> Please do not use such comments in the code "// For >> JDK-8133897/JDK-8134116", this information can be obtained from the >> mercurial history. >> >> >> >>>>> I guess it will be better to don't use the title (especially >>>>> parent.indexOfTab(title)) at all in the our code, except the situation >>>>> when we should access the title(like in getAccessibleName()). All >>>>> other cases should be rewritten to use >>>>> parent.indexOfTabComponent(comp). For example your "private String >>>>> getTitle() {}" can be implemented like this: >>>>> >>>>> return getTitleAt(parent.indexOfTabComponent(comp)); >>>>> >>>>> On 20.10.15 18:45, Pete Brunet wrote: >>>>>> Please review this patch: >>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.02/ >>>>>> >>>>>> The issue raised/fixed in 8133897 and now resolved in a better >>>>>> fashion >>>>>> in this patch is caused by an override of the functionality of >>>>>> JTabbedPane such that its Page inner class title field is not kept >>>>>> up to >>>>>> date by the overriding code. When the Page title field is empty >>>>>> getTitleAt is now called so that the overridden getTitleAt will >>>>>> provide >>>>>> the title. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134116 >>>>>> >>>>>> Pete >>>>>> >> From alexandr.scherbatiy at oracle.com Wed Nov 11 13:22:53 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 11 Nov 2015 16:22:53 +0300 Subject: Review request for 8133039 Provide public API to sun.swing.UIAction#isEnabled(Object) In-Reply-To: References: <5641D44C.5040902@oracle.com> Message-ID: <5643412D.70305@oracle.com> On 11/10/2015 3:10 PM, Andrej Golovnin wrote: > Hi Alexander, > > you patch changes the signature of a public method in SwingUtilities: > > Current JDK > 1731 public static boolean notifyAction(Action action, KeyStroke ks, > 1732 KeyEvent event, Object sender, > > After your change: > > 1731 public static boolean notifyAction(Action action, KeyStroke ks, > 1732 KeyEvent event, JComponent sender, > > Don't you think it may break binary compatibility? The method exists > since JDK 1.3. You are right. There is the updated fix there the sender type is Object: http://cr.openjdk.java.net/~alexsch/8133039/webrev.01 Thanks, Alexandr. > > Best regards, > Andrej Golovnin From andrej.golovnin at gmail.com Wed Nov 11 13:59:38 2015 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Wed, 11 Nov 2015 14:59:38 +0100 Subject: Review request for 8133039 Provide public API to sun.swing.UIAction#isEnabled(Object) In-Reply-To: <5643412D.70305@oracle.com> References: <5641D44C.5040902@oracle.com> <5643412D.70305@oracle.com> Message-ID: Hi Alexander, > You are right. > > There is the updated fix there the sender type is Object: > http://cr.openjdk.java.net/~alexsch/8133039/webrev.01 > this one looks good for me. Best regards, Andrej Golovnin From alexandr.scherbatiy at oracle.com Wed Nov 11 14:50:16 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 11 Nov 2015 17:50:16 +0300 Subject: Review request for 7124218: Space should select cell in the JTable In-Reply-To: <706FBB8F-3206-4F11-B92E-C155BD2C2AE0@oracle.com> References: <706FBB8F-3206-4F11-B92E-C155BD2C2AE0@oracle.com> Message-ID: <564355A8.9090002@oracle.com> - May be isMac() method can only check L&F because a L&F which contains Mac description usually implies that it is L&F designed for Mac OS X - isMac(osName, lookAndFeel) check is used to do different actions but the only essential difference is in the provided key code. it can be changed to keyTap(isMac(...) ? KeyEvent.VK_ENTER : KeyEvent.SPACE) - The exception handling in the tryLookAndFeel() method is skipped. What should be the test behavior in case if it is not possible to set a L&F? - runTestCase() method should access JTable methods on EDT. Thanks, Alexandr. On 11/3/2015 12:20 PM, Avik Niyogi wrote: > Hi All, > > Kindly review the fix for JDK9. > *Bug*: https://bugs.openjdk.java.net/browse/JDK-7124218 > > *Webrev*: http://cr.openjdk.java.net/~rchamyal/avik/7124218/webrev.00/ > > > *Issue*: "Space should select cell in the JTable" is being expected > for Look and Feels (and OS) > where key-bindings are different. > > *Cause*: Keybindings expected in the test case are not taking native > key-bindings into account. > > *Fix*: Recreated test case with appropriate cases for all required OS > to account > for supported native, non-native and cross-platform Look and Feels. > > With Regards, > Avik Niyogi From rajeev.chamyal at oracle.com Wed Nov 11 15:47:45 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Wed, 11 Nov 2015 07:47:45 -0800 (PST) Subject: Review request for JDK-8075084 JOptionPane.showMessageDialog causes JScrollBar to move Message-ID: <556d6cec-a723-42a4-a96a-dc22b7d2f112@default> Hello All, Please review the following fix for Jdk9: Bug: https://bugs.openjdk.java.net/browse/JDK-8075084 Webrev: http://cr.openjdk.java.net/~rchamyal/8075084/webrev.00/ Issue: On running the sample program attached in bug JDK-8075084 user is expected to see a scrollbar and on clicking the scrollbar tracker or scrollbar up/down arrow buttons a JOption dialog should come once. The program works fine if scrollbar tracker is clicked i.e. JOption dialog comes only once. But on clicking up/down arrow buttons of scrollbar the JOption dialog keeps on coming repeatedly. Cause: The mouse pressed event of scrollbar arrow buttons calls BasicScrollBarUI::scrollByUnit method which creates a property change event and calls scroll bar action listener which again calls BasicScrollBarUI::scrollByUnit. This is becoming a recursive call and causing the scrollbar slider to move repeatedly till it reaches the other end of scrollbar. Fix: Added checks in the BasicScrollBarUI action listener to stop the recursion. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.brunet at oracle.com Wed Nov 11 16:19:12 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 11 Nov 2015 10:19:12 -0600 Subject: RfR JDK-8134116, Add more comprehensive fix and regression test for JDK-8133897 In-Reply-To: <5642FB6C.8060502@oracle.com> References: <5626619E.1080902@oracle.com> <563108EB.6050502@oracle.com> <56339AF7.1090809@oracle.com> <56343555.8090308@oracle.com> <5641DF36.3080301@oracle.com> <56425929.80502@oracle.com> <5642FB6C.8060502@oracle.com> Message-ID: <56436A80.1050506@oracle.com> Thanks Alexandr, I made that change and added a test to ensure getAccessibleName returns the proper page when the page's component is null. Please see the following webrev. http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.05/ Pete On 11/11/15 2:25 AM, Alexander Scherbatiy wrote: > On 11/10/2015 11:52 PM, Pete Brunet wrote: >> Thanks Sergey, Please see >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.04/ >> >> parent.indexOfTab(title) is replaced with >> parent.indexOfTabComponent(tabComponent). >> >> The regression test runs OK. > > It looks like the check to null component in the getTitleMethod() is > not necessary. > Even if a page contains a null component the > parent.indexOfComponent(null) returns the correct index. > So we always asks for a component (it may be null) which definitely > is containded in the pages list. > Here is a small example: > --------------- > tabbedPane.addTab("Label 1", new JLabel("Label 1")); > tabbedPane.addTab("Null", null); > tabbedPane.addTab("Label 2", new JLabel("Label 2")); > System.out.println("index of null component: " + > tabbedPane.indexOfComponent(null)); // returns index 1 > --------------- > > Thanks, > Alexandr. > >> >> Pete >> >> On 11/10/15 6:12 AM, Sergey Bylokhov wrote: >>> Hi, Pete. >>> On 31.10.15 6:28, Pete Brunet wrote: >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.03/ >>> My suggestion was to remove all usage of parent.indexOfTab(title) in >>> the code and replace it by parent.indexOfTabComponent(comp). >>> For example: >>> getTabBounds(parent, parent.indexOfTab(getTitle())); >>> Can return incorrect bounds if a few pages will have the same title. >>> >>> Another problem in the fix is that it iterates over components twice: >>> in the getTitle()->(parent.indexOfComponent(component)), and in the >>> parent.indexOfTab(title). >>> >>> Please do not use such comments in the code "// For >>> JDK-8133897/JDK-8134116", this information can be obtained from the >>> mercurial history. >>> >>> >>> >>>>>> I guess it will be better to don't use the title (especially >>>>>> parent.indexOfTab(title)) at all in the our code, except the >>>>>> situation >>>>>> when we should access the title(like in getAccessibleName()). All >>>>>> other cases should be rewritten to use >>>>>> parent.indexOfTabComponent(comp). For example your "private String >>>>>> getTitle() {}" can be implemented like this: >>>>>> >>>>>> return getTitleAt(parent.indexOfTabComponent(comp)); >>>>>> >>>>>> On 20.10.15 18:45, Pete Brunet wrote: >>>>>>> Please review this patch: >>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.02/ >>>>>>> >>>>>>> The issue raised/fixed in 8133897 and now resolved in a better >>>>>>> fashion >>>>>>> in this patch is caused by an override of the functionality of >>>>>>> JTabbedPane such that its Page inner class title field is not kept >>>>>>> up to >>>>>>> date by the overriding code. When the Page title field is empty >>>>>>> getTitleAt is now called so that the overridden getTitleAt will >>>>>>> provide >>>>>>> the title. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134116 >>>>>>> >>>>>>> Pete >>>>>>> >>> > From Sergey.Bylokhov at oracle.com Wed Nov 11 16:23:10 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 11 Nov 2015 19:23:10 +0300 Subject: Review request for JDK-8079253 Test javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails In-Reply-To: <5642F68C.80102@oracle.com> References: <8311be49-f2d6-4698-bec7-f139293d6b40@default> <563C7C4B.5030101@oracle.com> <563C80A0.2020408@oracle.com> <2c4ea2da-cf65-4427-b10e-f3ab4c331169@default> <5642F68C.80102@oracle.com> Message-ID: <56436B6E.2080700@oracle.com> On 11.11.15 11:04, Alexander Scherbatiy wrote: > > The fix looks good to me. Looks fine. > > Thanks, > Alexandr. > > On 11/11/2015 9:02 AM, Rajeev Chamyal wrote: >> Hello, >> >> Please review the updated webrev. >> http://cr.openjdk.java.net/~rchamyal/8079253/webrev.01/ >> >> Removed the line JFrame.setDefaultLookAndFeelDecorated as Frame size >> issue will be fixed once JDK-8073710 is resolved. >> Updated the bug description for JDK-8079253. >> >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Alexander Scherbatiy >> Sent: 06 November 2015 15:58 >> To: Rajeev Chamyal >> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net >> Subject: Re: Review request for JDK-8079253 Test >> javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails >> >> On 11/6/2015 1:21 PM, Rajeev Chamyal wrote: >>> Hello Alexander, >>> >>> Thanks for the review. >>> We need to set the opaque property on the label as well. >> I see. >> >> The idea is that we do not fix tests itself so they just work. >> The tests are necessary to find as much issues as possible. >> If this test requires that the JDK-8073710 would be fixed first >> we need to leave it and wait for the JDK-8073710 fix. >> >> The issue the the opaque property can be added as a comment to the >> JDK-8073710 bug so it will be updated with the JDK-8073710 fix. >> >> Thanks, >> Alexandr. >> >>> Regards, >>> Rajeev Chamyal >>> >>> -----Original Message----- >>> From: Alexander Scherbatiy >>> Sent: 06 November 2015 15:39 >>> To: Rajeev Chamyal >>> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net >>> Subject: Re: Review request for JDK-8079253 Test >>> javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java fails >>> >>> On 11/6/2015 12:38 PM, Rajeev Chamyal wrote: >>>> Hello All, >>>> >>>> Please review the following fix for Jdk9: >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8079253 >>>> >>>> Webrev:http://cr.openjdk.java.net/~rchamyal/8079253/webrev.00/ >>>> >>>> >>>> Issue: The test case shortens two text labels and writes the >>>> resulting same strings to buffered images. >>>> >>>> On Ubuntu linux the image pixels are not matching. >>>> >>>> Cause: The frame size in Ubuntu is coming different every time which >>>> is resulting in different size images and resulting into issue. >>>> BugJDK-8073710 >>>> is already reported for this issue. >>>> Also we need set the opaque property on label component which makes >>>> sure that all of the bits contained within component's rectangular >>>> bounds are painted. >>> Should the original test (without the proposed changes) work if >>> JDK-8073710 is fixed? >>> If yes, the current issue should be closed as duplicate of the >>> JDK-8073710. >>> >>> Thanks, >>> Alexandr. >>>> Fix: Setting the default look and feel decoration for frame size >>>> issue and making label opaque. >>>> Regards, >>>> Rajeev Chamyal >>>> > -- Best regards, Sergey. From rajeev.chamyal at oracle.com Thu Nov 12 09:05:00 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 12 Nov 2015 01:05:00 -0800 (PST) Subject: Review request for JDK-6288609 JInternalFrame.setDefaultCloseOperation() interferes with "close" behavior In-Reply-To: <563CB511.70809@oracle.com> References: <563CB511.70809@oracle.com> Message-ID: <9ada93ec-35ee-4434-adf1-b6348741dcf5@default> Hello Alexander, At all other places we call firePropertyChange(IS_CLOSED_PROPERTY, Boolean.FALSE,Boolean.TRUE); before calling dispose. Which will result in unselecting and closing the frame. If API user is extending the InternalFrameUI classes then they have to care of selection/deselection themselves. I have tested the fix with all look and feels on Windows and Ubuntu and on MAC with Aqua LAF as well. Regards, Rajeev Chamyal -----Original Message----- From: Alexander Scherbatiy Sent: 06 November 2015 19:41 To: Rajeev Chamyal Cc: Sergey Bylokhov; swing-dev at openjdk.java.net Subject: Re: Review request for JDK-6288609 JInternalFrame.setDefaultCloseOperation() interferes with "close" behavior On 10/29/2015 10:41 AM, Rajeev Chamyal wrote: > > Hello All, > > Please review the following fix for Jdk9: > > *Bug*:https://bugs.openjdk.java.net/browse/JDK-6288609 > > *Webrev*:http://cr.openjdk.java.net/~rchamyal/6288609/webrev.00/ > > > *Issue*: On disposing the Top level JInternalFrame focus is not > shifting to the JInternalFrame below it. > > *Cause*: Dispose method is changing the selection of currently closing > frame and then it calls the DefaultDeskTopManager:closeFrame which > > finds the JInternalFrame below the closing frame based on selection of > the closing frame and then shifts the focus to frame below it. > > Since selection is already changed by dispose method > DefaultDeskTopManager:closeFrame is unable to find reference to > previous frame. > > *Fix*: Removed the selection change code from Dispose method. Are there any cases that the JInternalFrame is still selected after the IS_CLOSED_PROPERTY is fired in the dispose() method so it is still necessary to set the selection to false? Thanks, Alexandr. > > Regards, > Rajeev Chamyal From Sergey.Bylokhov at oracle.com Thu Nov 12 10:32:27 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Nov 2015 13:32:27 +0300 Subject: Review request for JDK-8030099 Memory usage of java process increases after pressing start button in test window In-Reply-To: <24f6a8c3-6070-4f64-9128-fc45b562349d@default> References: <562565A7.6000701@oracle.com> <56256D75.9010003@oracle.com> <6937cb71-466b-4972-b12a-15c5d7607b28@default> <56313450.4010704@oracle.com> <56327601.40103@oracle.com> <24f6a8c3-6070-4f64-9128-fc45b562349d@default> Message-ID: <56446ABB.6050000@oracle.com> Still looks fine to me. On 02.11.15 19:19, Rajeev Chamyal wrote: > Hello Phil, > > Please review the updated webrev. > http://cr.openjdk.java.net/~rchamyal/8030099/webrev.02/ > > The test case has been updated as per review comments. Added tests for both Parallel and default collector. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Phil Race > Sent: 30 October 2015 01:10 > To: Rajeev Chamyal > Cc: Sergey Bylokhov; Alexander Scherbatiy; swing-dev at openjdk.java.net > Subject: Re: Review request for JDK-8030099 Memory usage of java process increases after pressing start button in test window > > It is arguably most important to run this with the *default* collector. > If that changes to G1 (I think it is at least temporarily so changed in JDK 9) then we will never see problems in the case people end up using. > > But you obviously also want to test the case that shows the bug. > > So I would say the best option is to test both : explicit parallel GC and again with default .. even if they are the same there should be no harm done. > > You may want to increase timeout if running twice but you will have to verify that. > > -phil. > > > On 10/29/2015 05:48 AM, Rajeev Chamyal wrote: >> Hello Sergey, >> >> Please review the updated test case. >> Webrev : http://cr.openjdk.java.net/~rchamyal/8030099/webrev.01/ >> >> As this issue is reported for Parallel GC collector. So, I have added -XX:+UseParallelGC to child process VM arguments in test case. >> >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: 29 October 2015 02:17 >> To: Rajeev Chamyal; Philip Race >> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net >> Subject: Re: Review request for JDK-8030099 Memory usage of java >> process increases after pressing start button in test window >> >> Thanks for clarification. >> The fix looks fine. >> >> On 20.10.15 11:49, Rajeev Chamyal wrote: >>> Hello Sergey, >>> >>> I mentioned incorrectly that JDK8 is using CMS as default garbage collector. JDK 8 uses Parallel GC as default collector. >>> >>> Following are the results with Parallel GC as default collector in JDK9. >>> >>> Max java process size before fix while running test case(webrev) : 220MB (approx.) JDK version build 1.9.0-ea-b86. >>> Max java process size after fix while running test case(webrev) : 130MB(approx.). JDK9 version 1.9.0-internal-_2015_10_15_21_12-b00. >>> >>> Regards, >>> Rajeev Chamyal >>> >>> -----Original Message----- >>> From: Rajeev Chamyal >>> Sent: 20 October 2015 12:10 >>> To: Sergey Bylokhov; Philip Race >>> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net >>> Subject: RE: Review request for JDK-8030099 Memory usage of java >>> process increases after pressing start button in test window >>> >>> Hello Sergey, >>> >>> Below are my observation while testing the fix. >>> >>> Max java process size before fix while running test case(webrev) : 170MB (approx.) JDK version build 1.9.0-ea-b86. >>> Max java process size after fix while running test case(webrev) : 165MB(approx.). JDK9 version 1.9.0-internal-_2015_10_15_21_12-b00. >>> The results are not consistent always in both cases. >>> >>> We cannot compare these results with JDK8 because it uses CMS collector as default garbage collector while JDK9 is using G1 collector. >>> G1 collector is giving better results because it does heap compaction as well. >>> >>> We are using different reference types in different files ( files registering instances with Disposer) e.g. StrikeCache uses SoftReferences. >>> >>> Regards, >>> Rajeev Chamyal >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: 20 October 2015 03:54 >>> To: Philip Race; Rajeev Chamyal >>> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net >>> Subject: Re: Review request for JDK-8030099 Memory usage of java >>> process increases after pressing start button in test window >>> >>> On 20.10.15 0:50, Philip Race wrote: >>>> The code change looks fine. The test is delightfully complicated. >>> I still have not got a benefit of weak references in this use case. Does it mean that weak are always better? If yes, then we should at some point change default policy for all other cases as well. >>> >>>> Did you run it under jtreg ? >>>> >>>> -phil. >>>> >>>> >>>> On 10/19/15, 5:10 AM, Rajeev Chamyal wrote: >>>>> Hello, >>>>> >>>>> Please review the following fix for Jdk9: >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030099 >>>>> >>>>> Webrev:http://cr.openjdk.java.net/~rchamyal/8030099/webrev.00/ >>>>> >>>>> >>>>> Issue: The memory usage of java process goes on increasing if we >>>>> call ShellFolder:listFiles API >>>>> >>>>> aggressively on some folder with large number of files/folders. >>>>> >>>>> Cause: Win32ShellFolder class registers its instances and native >>>>> data with sun.java2d.Disposer class for later disposal. >>>>> Win32ShellFolder instances are getting registered as >>>>> PhantomReferences with Disposer and are not getting cleared immediately. >>>>> This leads to increase of memory usage by java process. >>>>> Fix: Instead of registering the complete Win32ShellFolder object >>>>> reference with disposer we are now adding only a sentinel object >>>>> and also using sun.java2d.Disposer :: addObjectRecord API which >>>>> adds the references as WeakReferences. >>>>> Regards, >>>>> Rajeev Chamyal >>>>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Nov 12 11:07:12 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 12 Nov 2015 14:07:12 +0300 Subject: Review request for JDK-6288609 JInternalFrame.setDefaultCloseOperation() interferes with "close" behavior In-Reply-To: <9ada93ec-35ee-4434-adf1-b6348741dcf5@default> References: <563CB511.70809@oracle.com> <9ada93ec-35ee-4434-adf1-b6348741dcf5@default> Message-ID: <564472E0.6000009@oracle.com> The fix looks good to me. Thanks, Alexandr. On 11/12/2015 12:05 PM, Rajeev Chamyal wrote: > Hello Alexander, > > At all other places we call firePropertyChange(IS_CLOSED_PROPERTY, Boolean.FALSE,Boolean.TRUE); before calling dispose. Which will result in unselecting and closing the frame. > If API user is extending the InternalFrameUI classes then they have to care of selection/deselection themselves. > I have tested the fix with all look and feels on Windows and Ubuntu and on MAC with Aqua LAF as well. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexander Scherbatiy > Sent: 06 November 2015 19:41 > To: Rajeev Chamyal > Cc: Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: Review request for JDK-6288609 JInternalFrame.setDefaultCloseOperation() interferes with "close" behavior > > On 10/29/2015 10:41 AM, Rajeev Chamyal wrote: >> Hello All, >> >> Please review the following fix for Jdk9: >> >> *Bug*:https://bugs.openjdk.java.net/browse/JDK-6288609 >> >> *Webrev*:http://cr.openjdk.java.net/~rchamyal/6288609/webrev.00/ >> >> >> *Issue*: On disposing the Top level JInternalFrame focus is not >> shifting to the JInternalFrame below it. >> >> *Cause*: Dispose method is changing the selection of currently closing >> frame and then it calls the DefaultDeskTopManager:closeFrame which >> >> finds the JInternalFrame below the closing frame based on selection of >> the closing frame and then shifts the focus to frame below it. >> >> Since selection is already changed by dispose method >> DefaultDeskTopManager:closeFrame is unable to find reference to >> previous frame. >> >> *Fix*: Removed the selection change code from Dispose method. > Are there any cases that the JInternalFrame is still selected after the IS_CLOSED_PROPERTY is fired in the dispose() method so it is still necessary to set the selection to false? > > Thanks, > Alexandr. > >> >> Regards, >> Rajeev Chamyal From rajeev.chamyal at oracle.com Thu Nov 12 11:22:56 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 12 Nov 2015 03:22:56 -0800 (PST) Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX In-Reply-To: References: Message-ID: Hello Avik, 1) In the tryLookAndFeel exception handling is skipped. createUI and other calls should be skipped in case of exception.. 2) What all platforms you have tested the bug? Regards, Rajeev Chamyal From: Avik Niyogi Sent: 04 November 2015 14:51 To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8132770 Webrev: http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.00/ Issue: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX where non-eligible Look and Feels are not taken into account. Cause: TestCase flow for non-Basic JRadioButton UI such as Aqua, Nimbus and GTK have different focus traversal track as compared to the rest and require different test case flow with regards to focus owner. Fix: Modified test case with appropriate deviant test case for Look and Feels which are not eligible for focus traversal as expected previously in test file. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Nov 12 11:20:11 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 12 Nov 2015 14:20:11 +0300 Subject: RfR JDK-8134116, Add more comprehensive fix and regression test for JDK-8133897 In-Reply-To: <56436A80.1050506@oracle.com> References: <5626619E.1080902@oracle.com> <563108EB.6050502@oracle.com> <56339AF7.1090809@oracle.com> <56343555.8090308@oracle.com> <5641DF36.3080301@oracle.com> <56425929.80502@oracle.com> <5642FB6C.8060502@oracle.com> <56436A80.1050506@oracle.com> Message-ID: <564475EB.7090803@oracle.com> The fix looks good to me. Thanks, Alexandr. On 11/11/2015 7:19 PM, Pete Brunet wrote: > Thanks Alexandr, I made that change and added a test to ensure > getAccessibleName returns the proper page when the page's component is > null. Please see the following webrev. > > http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.05/ > > Pete > > On 11/11/15 2:25 AM, Alexander Scherbatiy wrote: >> On 11/10/2015 11:52 PM, Pete Brunet wrote: >>> Thanks Sergey, Please see >>> >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.04/ >>> >>> parent.indexOfTab(title) is replaced with >>> parent.indexOfTabComponent(tabComponent). >>> >>> The regression test runs OK. >> It looks like the check to null component in the getTitleMethod() is >> not necessary. >> Even if a page contains a null component the >> parent.indexOfComponent(null) returns the correct index. >> So we always asks for a component (it may be null) which definitely >> is containded in the pages list. >> Here is a small example: >> --------------- >> tabbedPane.addTab("Label 1", new JLabel("Label 1")); >> tabbedPane.addTab("Null", null); >> tabbedPane.addTab("Label 2", new JLabel("Label 2")); >> System.out.println("index of null component: " + >> tabbedPane.indexOfComponent(null)); // returns index 1 >> --------------- >> >> Thanks, >> Alexandr. >> >>> Pete >>> >>> On 11/10/15 6:12 AM, Sergey Bylokhov wrote: >>>> Hi, Pete. >>>> On 31.10.15 6:28, Pete Brunet wrote: >>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.03/ >>>> My suggestion was to remove all usage of parent.indexOfTab(title) in >>>> the code and replace it by parent.indexOfTabComponent(comp). >>>> For example: >>>> getTabBounds(parent, parent.indexOfTab(getTitle())); >>>> Can return incorrect bounds if a few pages will have the same title. >>>> >>>> Another problem in the fix is that it iterates over components twice: >>>> in the getTitle()->(parent.indexOfComponent(component)), and in the >>>> parent.indexOfTab(title). >>>> >>>> Please do not use such comments in the code "// For >>>> JDK-8133897/JDK-8134116", this information can be obtained from the >>>> mercurial history. >>>> >>>> >>>> >>>>>>> I guess it will be better to don't use the title (especially >>>>>>> parent.indexOfTab(title)) at all in the our code, except the >>>>>>> situation >>>>>>> when we should access the title(like in getAccessibleName()). All >>>>>>> other cases should be rewritten to use >>>>>>> parent.indexOfTabComponent(comp). For example your "private String >>>>>>> getTitle() {}" can be implemented like this: >>>>>>> >>>>>>> return getTitleAt(parent.indexOfTabComponent(comp)); >>>>>>> >>>>>>> On 20.10.15 18:45, Pete Brunet wrote: >>>>>>>> Please review this patch: >>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.02/ >>>>>>>> >>>>>>>> The issue raised/fixed in 8133897 and now resolved in a better >>>>>>>> fashion >>>>>>>> in this patch is caused by an override of the functionality of >>>>>>>> JTabbedPane such that its Page inner class title field is not kept >>>>>>>> up to >>>>>>>> date by the overriding code. When the Page title field is empty >>>>>>>> getTitleAt is now called so that the overridden getTitleAt will >>>>>>>> provide >>>>>>>> the title. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134116 >>>>>>>> >>>>>>>> Pete >>>>>>>> From Sergey.Bylokhov at oracle.com Thu Nov 12 13:48:47 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Nov 2015 16:48:47 +0300 Subject: RfR JDK-8134116, Add more comprehensive fix and regression test for JDK-8133897 In-Reply-To: <564475EB.7090803@oracle.com> References: <5626619E.1080902@oracle.com> <563108EB.6050502@oracle.com> <56339AF7.1090809@oracle.com> <56343555.8090308@oracle.com> <5641DF36.3080301@oracle.com> <56425929.80502@oracle.com> <5642FB6C.8060502@oracle.com> <56436A80.1050506@oracle.com> <564475EB.7090803@oracle.com> Message-ID: <564498BF.2030404@oracle.com> Looks fine. On 12.11.15 14:20, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 11/11/2015 7:19 PM, Pete Brunet wrote: >> Thanks Alexandr, I made that change and added a test to ensure >> getAccessibleName returns the proper page when the page's component is >> null. Please see the following webrev. >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.05/ >> >> Pete >> >> On 11/11/15 2:25 AM, Alexander Scherbatiy wrote: >>> On 11/10/2015 11:52 PM, Pete Brunet wrote: >>>> Thanks Sergey, Please see >>>> >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.04/ >>>> >>>> parent.indexOfTab(title) is replaced with >>>> parent.indexOfTabComponent(tabComponent). >>>> >>>> The regression test runs OK. >>> It looks like the check to null component in the getTitleMethod() is >>> not necessary. >>> Even if a page contains a null component the >>> parent.indexOfComponent(null) returns the correct index. >>> So we always asks for a component (it may be null) which definitely >>> is containded in the pages list. >>> Here is a small example: >>> --------------- >>> tabbedPane.addTab("Label 1", new JLabel("Label 1")); >>> tabbedPane.addTab("Null", null); >>> tabbedPane.addTab("Label 2", new JLabel("Label 2")); >>> System.out.println("index of null component: " + >>> tabbedPane.indexOfComponent(null)); // returns index 1 >>> --------------- >>> >>> Thanks, >>> Alexandr. >>> >>>> Pete >>>> >>>> On 11/10/15 6:12 AM, Sergey Bylokhov wrote: >>>>> Hi, Pete. >>>>> On 31.10.15 6:28, Pete Brunet wrote: >>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.03/ >>>>> My suggestion was to remove all usage of parent.indexOfTab(title) in >>>>> the code and replace it by parent.indexOfTabComponent(comp). >>>>> For example: >>>>> getTabBounds(parent, parent.indexOfTab(getTitle())); >>>>> Can return incorrect bounds if a few pages will have the same title. >>>>> >>>>> Another problem in the fix is that it iterates over components twice: >>>>> in the getTitle()->(parent.indexOfComponent(component)), and in the >>>>> parent.indexOfTab(title). >>>>> >>>>> Please do not use such comments in the code "// For >>>>> JDK-8133897/JDK-8134116", this information can be obtained from the >>>>> mercurial history. >>>>> >>>>> >>>>> >>>>>>>> I guess it will be better to don't use the title (especially >>>>>>>> parent.indexOfTab(title)) at all in the our code, except the >>>>>>>> situation >>>>>>>> when we should access the title(like in getAccessibleName()). All >>>>>>>> other cases should be rewritten to use >>>>>>>> parent.indexOfTabComponent(comp). For example your "private String >>>>>>>> getTitle() {}" can be implemented like this: >>>>>>>> >>>>>>>> return getTitleAt(parent.indexOfTabComponent(comp)); >>>>>>>> >>>>>>>> On 20.10.15 18:45, Pete Brunet wrote: >>>>>>>>> Please review this patch: >>>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134116/webrev.02/ >>>>>>>>> >>>>>>>>> The issue raised/fixed in 8133897 and now resolved in a better >>>>>>>>> fashion >>>>>>>>> in this patch is caused by an override of the functionality of >>>>>>>>> JTabbedPane such that its Page inner class title field is not kept >>>>>>>>> up to >>>>>>>>> date by the overriding code. When the Page title field is empty >>>>>>>>> getTitleAt is now called so that the overridden getTitleAt will >>>>>>>>> provide >>>>>>>>> the title. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134116 >>>>>>>>> >>>>>>>>> Pete >>>>>>>>> > -- Best regards, Sergey. From javalists at cbfiddle.com Thu Nov 12 21:41:00 2015 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 12 Nov 2015 13:41:00 -0800 Subject: design question regarding UI defaults and painting Message-ID: <950E0B0B-6F9D-4737-BAA0-150CEBA80456@cbfiddle.com> I am curious about a design decision that was made in the implementation of textured window backgrounds in the Aqua LAF/AWT. In a nutshell, a textured window background is an optional NSWindow background style that involves gradients. Textured windows are requested in Java using a window client property. The implementation of this property sets the appropriate style on the NSWindow. More importantly, it also attempts to prevent Java from painting over the window background in places where the textured background is intended to be visible. Part of this is preventing Java from painting its own window background. The more interesting part is preventing certain components from painting over the textured background. This latter issue is handled in an unusual way. That Aqua LAF changes the behavior of JPanel, JRootPane, and JToolBar when painting the component background. If the component background color is a UIDefault that matches the system window background color, then instead of painting the background, it erases the corresponding region in the layer (frame buffer). The effect is to punch a hole in whatever background was painted by ancestor components. I am wondering why a more straightforward solution was not chosen -- making isOpaque()==false and background==Color(0,0,0,0) the default for all components that normally reveal the window background. (I tried this and it seems to work. I see various comments in the code that there must be an opaque component at the top of the hierarchy, but I have not found that to be true on OS X.) Is this a performance issue? A compatibility issue? An architectural issue? The components that would need to change are JPanel, JRootPane, JLayeredPane, JOptionPane, JSplitPane, JToolBar. Thanks in advance. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Fri Nov 13 04:16:08 2015 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Fri, 13 Nov 2015 09:46:08 +0530 Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX In-Reply-To: References: Message-ID: <63A5405D-6251-4D5B-ADD2-F7DC03E90963@oracle.com> Hi Rajeev, Will fix and create webrev.01 with inputs provided. Also, we have verified on Mac OS X, Windows and Ubuntu. With Regards, Avik Niyogi > On 12-Nov-2015, at 4:52 pm, Rajeev Chamyal wrote: > > Hello Avik, > > 1) In the tryLookAndFeel exception handling is skipped. createUI and other calls should be skipped in case of exception.. > 2) What all platforms you have tested the bug? > > Regards, > Rajeev Chamyal > > From: Avik Niyogi > Sent: 04 November 2015 14:51 > To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net > Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX > > Hi All, > > Kindly review the fix for JDK9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8132770 > > Webrev: http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.00/ > > Issue: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX where non-eligible Look and Feels are not taken into account. > > Cause: TestCase flow for non-Basic JRadioButton UI such as Aqua, Nimbus and GTK have different focus traversal track as compared to the rest and require different test case flow with regards to focus owner. > > Fix: Modified test case with appropriate deviant test case for Look and Feels which are not eligible for focus traversal as expected previously in test file. > > With Regards, > Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Mon Nov 16 05:21:45 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Sun, 15 Nov 2015 21:21:45 -0800 (PST) Subject: Review request for JDK-8030099 Memory usage of java process increases after pressing start button in test window In-Reply-To: <56446ABB.6050000@oracle.com> References: <562565A7.6000701@oracle.com> <56256D75.9010003@oracle.com> <6937cb71-466b-4972-b12a-15c5d7607b28@default> <56313450.4010704@oracle.com> <56327601.40103@oracle.com> <24f6a8c3-6070-4f64-9128-fc45b562349d@default> <56446ABB.6050000@oracle.com> Message-ID: <7de228d8-fe4d-4d61-989e-8afd090281d7@default> Hello Phil, I have updated the test case as per your review comments. Could you please review it. http://cr.openjdk.java.net/~rchamyal/8030099/webrev.02/ Regards, Rajeev Chamyal -----Original Message----- From: Sergey Bylokhov Sent: 12 November 2015 16:02 To: Rajeev Chamyal; Philip Race; Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Re: Review request for JDK-8030099 Memory usage of java process increases after pressing start button in test window Still looks fine to me. On 02.11.15 19:19, Rajeev Chamyal wrote: > Hello Phil, > > Please review the updated webrev. > http://cr.openjdk.java.net/~rchamyal/8030099/webrev.02/ > > The test case has been updated as per review comments. Added tests for both Parallel and default collector. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Phil Race > Sent: 30 October 2015 01:10 > To: Rajeev Chamyal > Cc: Sergey Bylokhov; Alexander Scherbatiy; swing-dev at openjdk.java.net > Subject: Re: Review request for JDK-8030099 Memory usage of java > process increases after pressing start button in test window > > It is arguably most important to run this with the *default* collector. > If that changes to G1 (I think it is at least temporarily so changed in JDK 9) then we will never see problems in the case people end up using. > > But you obviously also want to test the case that shows the bug. > > So I would say the best option is to test both : explicit parallel GC and again with default .. even if they are the same there should be no harm done. > > You may want to increase timeout if running twice but you will have to verify that. > > -phil. > > > On 10/29/2015 05:48 AM, Rajeev Chamyal wrote: >> Hello Sergey, >> >> Please review the updated test case. >> Webrev : http://cr.openjdk.java.net/~rchamyal/8030099/webrev.01/ >> >> As this issue is reported for Parallel GC collector. So, I have added -XX:+UseParallelGC to child process VM arguments in test case. >> >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Sergey Bylokhov >> Sent: 29 October 2015 02:17 >> To: Rajeev Chamyal; Philip Race >> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net >> Subject: Re: Review request for JDK-8030099 Memory usage of java >> process increases after pressing start button in test window >> >> Thanks for clarification. >> The fix looks fine. >> >> On 20.10.15 11:49, Rajeev Chamyal wrote: >>> Hello Sergey, >>> >>> I mentioned incorrectly that JDK8 is using CMS as default garbage collector. JDK 8 uses Parallel GC as default collector. >>> >>> Following are the results with Parallel GC as default collector in JDK9. >>> >>> Max java process size before fix while running test case(webrev) : 220MB (approx.) JDK version build 1.9.0-ea-b86. >>> Max java process size after fix while running test case(webrev) : 130MB(approx.). JDK9 version 1.9.0-internal-_2015_10_15_21_12-b00. >>> >>> Regards, >>> Rajeev Chamyal >>> >>> -----Original Message----- >>> From: Rajeev Chamyal >>> Sent: 20 October 2015 12:10 >>> To: Sergey Bylokhov; Philip Race >>> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net >>> Subject: RE: Review request for JDK-8030099 Memory usage of java >>> process increases after pressing start button in test window >>> >>> Hello Sergey, >>> >>> Below are my observation while testing the fix. >>> >>> Max java process size before fix while running test case(webrev) : 170MB (approx.) JDK version build 1.9.0-ea-b86. >>> Max java process size after fix while running test case(webrev) : 165MB(approx.). JDK9 version 1.9.0-internal-_2015_10_15_21_12-b00. >>> The results are not consistent always in both cases. >>> >>> We cannot compare these results with JDK8 because it uses CMS collector as default garbage collector while JDK9 is using G1 collector. >>> G1 collector is giving better results because it does heap compaction as well. >>> >>> We are using different reference types in different files ( files registering instances with Disposer) e.g. StrikeCache uses SoftReferences. >>> >>> Regards, >>> Rajeev Chamyal >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: 20 October 2015 03:54 >>> To: Philip Race; Rajeev Chamyal >>> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net >>> Subject: Re: Review request for JDK-8030099 Memory usage of java >>> process increases after pressing start button in test window >>> >>> On 20.10.15 0:50, Philip Race wrote: >>>> The code change looks fine. The test is delightfully complicated. >>> I still have not got a benefit of weak references in this use case. Does it mean that weak are always better? If yes, then we should at some point change default policy for all other cases as well. >>> >>>> Did you run it under jtreg ? >>>> >>>> -phil. >>>> >>>> >>>> On 10/19/15, 5:10 AM, Rajeev Chamyal wrote: >>>>> Hello, >>>>> >>>>> Please review the following fix for Jdk9: >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030099 >>>>> >>>>> Webrev:http://cr.openjdk.java.net/~rchamyal/8030099/webrev.00/ >>>>> >>>>> >>>>> Issue: The memory usage of java process goes on increasing if we >>>>> call ShellFolder:listFiles API >>>>> >>>>> aggressively on some folder with large number of files/folders. >>>>> >>>>> Cause: Win32ShellFolder class registers its instances and native >>>>> data with sun.java2d.Disposer class for later disposal. >>>>> Win32ShellFolder instances are getting registered as >>>>> PhantomReferences with Disposer and are not getting cleared immediately. >>>>> This leads to increase of memory usage by java process. >>>>> Fix: Instead of registering the complete Win32ShellFolder object >>>>> reference with disposer we are now adding only a sentinel object >>>>> and also using sun.java2d.Disposer :: addObjectRecord API which >>>>> adds the references as WeakReferences. >>>>> Regards, >>>>> Rajeev Chamyal >>>>> >>> >>> -- >>> Best regards, Sergey. >>> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From rajeev.chamyal at oracle.com Mon Nov 16 05:40:13 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Sun, 15 Nov 2015 21:40:13 -0800 (PST) Subject: RFR: [9] [JDK-8081491] The case print incomplete. In-Reply-To: <5644732F.6050100@oracle.com> References: <5620CF39.8000802@oracle.com> <5644732F.6050100@oracle.com> Message-ID: <6461c67d-55e1-418d-8a97-a83d8d086e25@default> The fix looks good to me. ? Regards, Rajeev Chamyal ? Subject: Re: RFR: [9] [JDK-8081491] The case print incomplete. Date: Fri, 16 Oct 2015 13:19:37 +0300 From: Alexander Scherbatiy HYPERLINK "mailto:alexandr.scherbatiy at oracle.com" To: prasanta sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com" CC: Phil Race HYPERLINK "mailto:philip.race at oracle.com", Sergey Bylokhov HYPERLINK "mailto:Sergey.Bylokhov at oracle.com", HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net ? ? The fix looks good to me. ? ? Thanks, ? Alexandr. ? On 10/14/2015 2:26 PM, prasanta sadhukhan wrote: >? >? > On 10/9/2015 3:00 PM, Alexander Scherbatiy wrote: >> On 10/7/2015 3:10 PM, prasanta sadhukhan wrote: >>> Hi All, >>>? >>> @Sergey,Phil,Alexander Z >>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.10/ >>? >>???? Have you checked the corner cases like printing a table which has >> only one row (with and without a scroll pane)? >>???? Could you add these scenarios to the test? >>? > Yes, I have checked this cases. JTable with 1 row will not show a > scrollpane so it will be same as a table with 1 row without a scrollpane. > I have added one row without scrollpane subtest >? > http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.11/ >? > Regards > Prasanta >> Thanks, >>??? Alexandr, >>? >>>? >>> Any more comments/feedback? Can I get a +1 for this? >>>? >>> Regards >>> Prasanta >>>>>>>>? >>>>>>>>? >>>>>>>> On 09/25/2015 04:47 AM, prasanta sadhukhan wrote: >>>>>>>>> Thanks Alexander. Can I get a +1 for this? >>>>>>>>>? >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> On 9/25/2015 2:43 PM, Alexander Scherbatiy wrote: >>>>>>>>>>? >>>>>>>>>>?? The fix looks good to me. >>>>>>>>>>? >>>>>>>>>>?? Thanks, >>>>>>>>>>?? Alexandr. >>>>>>>>>>? >>>>>>>>>> On 9/25/2015 9:26 AM, prasanta sadhukhan wrote: >>>>>>>>>>> Added null check for SwingUtilities.getUnwrappedParent(table). >>>>>>>>>>> Please review the updated webrev >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.08/ >>>>>>>>>>>? >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>>>>> On 9/24/2015 5:19 PM, Alexander Scherbatiy wrote: >>>>>>>>>>>> On 9/23/2015 12:26 PM, prasanta sadhukhan wrote: >>>>>>>>>>>>>? >>>>>>>>>>>>>? >>>>>>>>>>>>> On 9/23/2015 2:46 PM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> On 9/23/2015 9:42 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>>>> I have updated the code as per your comment. >>>>>>>>>>>>>>> Please review this webrev >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.07/ >>>>>>>>>>>>>>? >>>>>>>>>>>>>>??? - Is it possible that >>>>>>>>>>>>>> SwingUtilities.getUnwrappedParent(table) returns null? >>>>>>>>>>>>> I have not seen it. It will return at least JRootPane, I >>>>>>>>>>>>> guess. >>>>>>>>>>>>? >>>>>>>>>>>>??? Is it possible just crate a JTable with some rows and >>>>>>>>>>>> print it, without adding to a frame or some others components? >>>>>>>>>>>>? >>>>>>>>>>>>??? Thanks, >>>>>>>>>>>>??? Alexandr. >>>>>>>>>>>>>>??? - Does the fix work correctly for a case when rMax has >>>>>>>>>>>>>> initial zero value but it is decremented on line 1857? >>>>>>>>>>>>> rMax can have -1 from table.rowAtPoint() in which case it >>>>>>>>>>>>> will be changed to total rowCount so it will not be 0 >>>>>>>>>>>>> before line 1857. >>>>>>>>>>>>>? >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>? >>>>>>>>>>>>>>?? Thanks, >>>>>>>>>>>>>>?? Alexandr. >>>>>>>>>>>>>>? >>>>>>>>>>>>>>>? >>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>> On 9/22/2015 7:01 PM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>> On 9/21/2015 12:05 PM, prasanta sadhukhan wrote: >>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>> On 9/21/2015 2:20 PM, Alexandr Scherbatiy wrote: >>>>>>>>>>>>>>>>>> 18.09.2015 10:16, prasanta sadhukhan ?????: >>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>> On 9/17/2015 8:18 PM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>> On 9/16/2015 2:04 PM, prasanta sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>> Hi Alexander, Sergey, >>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>> Waiting for your review on this. >>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.06/ >>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>??? Could you describe why the paint artifacts are >>>>>>>>>>>>>>>>>>>> drawn when a scroll pane is present? >>>>>>>>>>>>>>>>>>> I see that normally JTable has always been >>>>>>>>>>>>>>>>>>> associated with JScrollpane and it uses >>>>>>>>>>>>>>>>>>> // Paint the grid. >>>>>>>>>>>>>>>>>>>? paintGrid(g, rMin, rMax, cMin, cMax); >>>>>>>>>>>>>>>>>>> // Paint the cells. >>>>>>>>>>>>>>>>>>> paintCells(g, rMin, rMax, cMin, cMax); >>>>>>>>>>>>>>>>>>> to paint the cells in the table. >>>>>>>>>>>>>>>>>>> When we scroll the table, rMin can be say 41 and >>>>>>>>>>>>>>>>>>> rMax can be 43 so it expects to draw 3 rows with the >>>>>>>>>>>>>>>>>>> above code (since the for loop uses rows = rMin; >>>>>>>>>>>>>>>>>>> rows <= rMax) >>>>>>>>>>>>>>>>>>> Also, sometimes rMin canbe 44 and rMax can be 44 too >>>>>>>>>>>>>>>>>>> in which case 1 row would be painted as per the >>>>>>>>>>>>>>>>>>> above for loop >>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>> but since I have modified the code to use (to make >>>>>>>>>>>>>>>>>>> same rows to show on console and in printed page) >>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>> // Paint the grid. >>>>>>>>>>>>>>>>>>>? paintGrid(g, rMin, rMax-1, cMin, cMax); >>>>>>>>>>>>>>>>>>> // Paint the cells. >>>>>>>>>>>>>>>>>>> paintCells(g, rMin, rMax-1, cMin, cMax); >>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>> it paints only 2 rows (or 0 rows in case >>>>>>>>>>>>>>>>>>> rMin=rMax=44 where rMax-1 is 43 so for loop will not >>>>>>>>>>>>>>>>>>> be executed) and when we go on scrolling, 1 less row >>>>>>>>>>>>>>>>>>> gets painted always than what it expects resulting >>>>>>>>>>>>>>>>>>> in artifacts. >>>>>>>>>>>>>>>>>>> So, I have kept the same code for JTable when it has >>>>>>>>>>>>>>>>>>> scrollpane (which was till now the case) >>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>???? - Does it mean if the initialpaintGrid()/Cell() >>>>>>>>>>>>>>>>>> methods are used there are artifacts when a table is >>>>>>>>>>>>>>>>>> not used with JScrollPane? >>>>>>>>>>>>>>>>> When table is not used with JScrollPane, there is no >>>>>>>>>>>>>>>>> change of table visible rows (since user is not >>>>>>>>>>>>>>>>> scrolling the table) so there is no artifacts if table >>>>>>>>>>>>>>>>> does not have jscrollpane. >>>>>>>>>>>>>>>>>>???? - It is not necessary to add isScrollPanePresent >>>>>>>>>>>>>>>>>> varibale if it is used only once >>>>>>>>>>>>>>>>> I did not understand. It's a variable and not a >>>>>>>>>>>>>>>>> function. So, what you are proposing me to do? >>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>> It is possible just to use >>>>>>>>>>>>>>>> ----------------------------- >>>>>>>>>>>>>>>> +??????? if (some expression) { >>>>>>>>>>>>>>>>??????????????? // do something >>>>>>>>>>>>>>>>?????????? } >>>>>>>>>>>>>>>> ----------------------------- >>>>>>>>>>>>>>>> instead of >>>>>>>>>>>>>>>> ----------------------------- >>>>>>>>>>>>>>>> +??????? boolean isScrollPanePresent = true; >>>>>>>>>>>>>>>> +??????? if (some expression) { >>>>>>>>>>>>>>>> +??????????? isScrollPanePresent = false; >>>>>>>>>>>>>>>> +??????? } >>>>>>>>>>>>>>>> +??????? if (isScrollPanePresent) { >>>>>>>>>>>>>>>>??????????????? // do something >>>>>>>>>>>>>>>>?????????? } >>>>>>>>>>>>>>>> ----------------------------- >>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>? In your case it is even better just to update the rMax >>>>>>>>>>>>>>>> according to is scroll pane presence. >>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>???? Thanks, >>>>>>>>>>>>>>>>>>??? Alexandr. >>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>??? Thanks, >>>>>>>>>>>>>>>>>>>>??? Alexandr. >>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>>>>>> On 9/15/2015 10:55 AM, prasanta sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>> On 9/14/2015 12:48 PM, prasanta sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>> On 9/11/2015 2:20 PM, prasanta sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>> On 9/10/2015 4:48 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 10.09.15 13:35, prasanta sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>> On 9/10/2015 3:42 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 10.09.15 9:36, prasanta sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> Please review the modified webrev which >>>>>>>>>>>>>>>>>>>>>>>>>>>> solves this artifacts. >>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.05/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>> What will happen if the table will be added >>>>>>>>>>>>>>>>>>>>>>>>>>> to the jpanel and the >>>>>>>>>>>>>>>>>>>>>>>>>>> jpanel will be added to JScrollPane? Will >>>>>>>>>>>>>>>>>>>>>>>>>>> this configuration work as >>>>>>>>>>>>>>>>>>>>>>>>>>> expected? >>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>> Please review which takes care of this >>>>>>>>>>>>>>>>>>>>>>> configuration >>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.06/ >>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>> Gentle reminder for review request. >>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>> I also added a reg test for this regression >>>>>>>>>>>>>>>>>>>>>>>>>>>> but I am not able to create >>>>>>>>>>>>>>>>>>>>>>>>>>>> a automated testcase to deal with the >>>>>>>>>>>>>>>>>>>>>>>>>>>> scrolling artifacts, so I added a >>>>>>>>>>>>>>>>>>>>>>>>>>>> manual test. >>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>> I suggest to try to automate it somehow. >>>>>>>>>>>>>>>>>>>>>>>>>>> Probably make some small >>>>>>>>>>>>>>>>>>>>>>>>>>> unity test? Or using robot? >>>>>>>>>>>>>>>>>>>>>>>>>> Even with Robot or unity test, how will I >>>>>>>>>>>>>>>>>>>>>>>>>> check the artifact has >>>>>>>>>>>>>>>>>>>>>>>>>> happened? THis is a visual problem. I do not >>>>>>>>>>>>>>>>>>>>>>>>>> know how to test it >>>>>>>>>>>>>>>>>>>>>>>>>> automatically. >>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>> In case of unit test you can check the return >>>>>>>>>>>>>>>>>>>>>>>>> value of some methods or the state of the >>>>>>>>>>>>>>>>>>>>>>>>> objects which are cause the artifacts. For >>>>>>>>>>>>>>>>>>>>>>>>> test with robot, you can fill all rows of >>>>>>>>>>>>>>>>>>>>>>>>> table in some color, then scroll it, and check >>>>>>>>>>>>>>>>>>>>>>>>> the color of the table using >>>>>>>>>>>>>>>>>>>>>>>>> robot.getPixelColor(). >>>>>>>>>>>>>>>>>>>>>>>> Thanks Sergey for the suggestion. I am trying >>>>>>>>>>>>>>>>>>>>>>>> to use Robot to test this artifacts. But when I >>>>>>>>>>>>>>>>>>>>>>>> use Robot to scroll up/down, the artifacts are >>>>>>>>>>>>>>>>>>>>>>>> not seen even when the scrollbar moved up and >>>>>>>>>>>>>>>>>>>>>>>> down. But manually if I scroll, I can see the >>>>>>>>>>>>>>>>>>>>>>>> artifacts. Can you please let me know if the >>>>>>>>>>>>>>>>>>>>>>>> attached testcase is missing something? >>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>> --Prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/8/2015 4:27 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, Prasanta. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Just before the push of this fix I made >>>>>>>>>>>>>>>>>>>>>>>>>>>>> small pit, and found a >>>>>>>>>>>>>>>>>>>>>>>>>>>>> regression. Please run the SwingSet2, open >>>>>>>>>>>>>>>>>>>>>>>>>>>>> JTable demo, and scroll the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> table. You will see some artifacts. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 08.09.15 13:13, prasanta sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Sergey for pointing this. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have taken care of this plus formatting >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in for loop. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please have a look >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.04/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/8/2015 3:32 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, Prasanta. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A few small notes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? - BasicTableUI: typo "1850 // otherwise >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1 extra rows are ptinted" >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? - ImageableAreaTest: the test >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instructions have copy pasted numbers >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1/2/2/2 etc. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 08.09.15 12:43, prasanta sadhukhan >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for your review. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>?? I need +1 for this. Alexander >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Z/Sergey, can you please approve >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fix? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/8/2015 3:02 PM, Alexander >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>?? The fix looks good to me. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>?? But you need to properly format >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> spaces in the 'for' loop on line >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TablePrintable:410 before the push. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>?? Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>?? Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/8/2015 12:26 PM, prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/7/2015 5:50 PM, Alexander >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/7/2015 9:23 AM, prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I guess it will be same but anyways >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have modified to use >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> visibleBounds.getLocation() to be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on safeside as we are dealing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with visible region for this fix. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please review the updated webrev >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.02/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> TablePrintable: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>????? - Could the rMin be equal to -1? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This should never happen so long >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bounds intersects the clip but as >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> done in BasicTableUI, I have added >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the check just in case >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - Line: 406 int rowHeight = >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (rMax-rMin) * table.getRowHeight(); >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>??????? Rows can have different >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> height in the table. Could you >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> also >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> add a test for the this case too? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Added test for this case too. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please review this webrev: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.03/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>???? Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/4/2015 8:57 PM, Alexander >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? Could the clip.getLocation() be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> differ from them >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> visibleBounds.getLocation()? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/4/2015 3:32 PM, prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any reviewers for this please? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/2/2015 5:06 PM, prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Can this fix be reviewed? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 8/28/2015 4:48 PM, prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 8/26/2015 6:24 PM, Alexander >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 8/25/2015 1:51 PM, prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 8/25/2015 3:53 PM, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 8/24/2015 2:23 PM, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prasanta sadhukhan wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bug: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8081491 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This seems to be a hidden >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> JTable bug in which if the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not call pack() or set >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a ScrollPane() for JTable >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rather use JFrame.setSize() >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> smaller than table size >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> then it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was found that some of the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rows which cannot be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fitted in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1st page cannot get printed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on 2nd and subsequent pages >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> resulting in blank cells to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be printed after 1st page. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It was found that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BasicTableUI checks for table >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bounds to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fall within the clip and if >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> they do not intersect, it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bails >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> out from painting the table >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cells. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>????? What is the reason that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the graphics clip does not >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> intersect the table bounds >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> during printing in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provided >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> test case? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The testcase does >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> table.setSize(600,800) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whereas frame >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> setSize is 400,600 . >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For 1st page, the clip was >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 0,0,384,752 and bounds was >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 0,0,384,562 so they intersect >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and there's no problem in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> printing the rows in 1st page. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> After the 1st page is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> printed, the clip is set to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 0,752,384,48 since we have >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> printed the rows that we can >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fit >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in 1st page and the next set >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of rows are to be printed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> while >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bounds remains at 0,0,384,562 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because JComponent >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> getBounds is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> returning the visible frame >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bounds which did not change. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>???? The >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> !bounds.intersects(clip) check >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prevents printing of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> table rows which are not >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> visible on the frame. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>???? It seems that the issue is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that extra rows which are >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> shown in the frame are printed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on the first page. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>???? It means that the printed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rows and columns should be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calculated for the table >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bounds and clip intersection. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>???? The test can be updated to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mention that only visible >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> part >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the table should be printed. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Have modified the code to print >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only the rows that are >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> displayed on console. Also >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> updated the test to mention the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same. Please review the updated >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> webrev. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8081491/webrev.01/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>??? Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please, also mention in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> email title JDK version for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which the fix is provided. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Done >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>??? Alexandr. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I devised a solution >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whereby it will not bail >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> out till >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> either rows or columns are >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> still left to be printed on >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subsequent pages . Please >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> review and let me know if >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it's ok. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Prasanta >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>>? >>>>>>>>>>>>>>>? >>>>>>>>>>>>>>? >>>>>>>>>>>>>? >>>>>>>>>>>>? >>>>>>>>>>>? >>>>>>>>>>? >>>>>>>>>? >>>>>>>>? >>>>>>>? >>>>>>? >>>>>? >>>>? >>>? >>? >? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Mon Nov 16 06:48:06 2015 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Mon, 16 Nov 2015 12:18:06 +0530 Subject: Review request for 7124218: Space should select cell in the JTable In-Reply-To: <564355A8.9090002@oracle.com> References: <706FBB8F-3206-4F11-B92E-C155BD2C2AE0@oracle.com> <564355A8.9090002@oracle.com> Message-ID: <9D982DDD-8AC0-4C9D-B2A1-9F764AF0794D@oracle.com> Hi All, The bug fix has been updated as per the comments. http://cr.openjdk.java.net/~rchamyal/avik/7124218/webrev.01/ With Regards, Avik Niyogi > On 11-Nov-2015, at 8:20 pm, Alexander Scherbatiy wrote: > > > - May be isMac() method can only check L&F because a L&F which contains Mac description usually implies that it is L&F designed for Mac OS X > - isMac(osName, lookAndFeel) check is used to do different actions but the only essential difference is in the provided key code. > it can be changed to keyTap(isMac(...) ? KeyEvent.VK_ENTER : KeyEvent.SPACE) > - The exception handling in the tryLookAndFeel() method is skipped. > What should be the test behavior in case if it is not possible to set a L&F? > - runTestCase() method should access JTable methods on EDT. > > Thanks, > Alexandr. > > On 11/3/2015 12:20 PM, Avik Niyogi wrote: >> Hi All, >> >> Kindly review the fix for JDK9. >> *Bug*: https://bugs.openjdk.java.net/browse/JDK-7124218 >> >> *Webrev*: http://cr.openjdk.java.net/~rchamyal/avik/7124218/webrev.00/ >> >> *Issue*: "Space should select cell in the JTable" is being expected for Look and Feels (and OS) >> where key-bindings are different. >> >> *Cause*: Keybindings expected in the test case are not taking native key-bindings into account. >> >> *Fix*: Recreated test case with appropriate cases for all required OS to account >> for supported native, non-native and cross-platform Look and Feels. >> >> With Regards, >> Avik Niyogi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From avik.niyogi at oracle.com Mon Nov 16 06:49:52 2015 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Mon, 16 Nov 2015 12:19:52 +0530 Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX In-Reply-To: <63A5405D-6251-4D5B-ADD2-F7DC03E90963@oracle.com> References: <63A5405D-6251-4D5B-ADD2-F7DC03E90963@oracle.com> Message-ID: <6DBB9881-799B-4822-9E4A-50B5AF973750@oracle.com> Hi All, The bug fix has been updated as per the comments. http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.01/ With Regards, Avik Niyogi > On 13-Nov-2015, at 9:46 am, Avik Niyogi wrote: > > Hi Rajeev, > > Will fix and create webrev.01 with inputs provided. Also, we have verified on Mac OS X, Windows and Ubuntu. > > With Regards, > Avik Niyogi > >> On 12-Nov-2015, at 4:52 pm, Rajeev Chamyal > wrote: >> >> Hello Avik, >> >> 1) In the tryLookAndFeel exception handling is skipped. createUI and other calls should be skipped in case of exception.. >> 2) What all platforms you have tested the bug? >> >> Regards, >> Rajeev Chamyal >> >> From: Avik Niyogi >> Sent: 04 November 2015 14:51 >> To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net >> Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX >> >> Hi All, >> >> Kindly review the fix for JDK9. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8132770 >> >> Webrev: http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.00/ >> >> Issue: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX where non-eligible Look and Feels are not taken into account. >> >> Cause: TestCase flow for non-Basic JRadioButton UI such as Aqua, Nimbus and GTK have different focus traversal track as compared to the rest and require different test case flow with regards to focus owner. >> >> Fix: Modified test case with appropriate deviant test case for Look and Feels which are not eligible for focus traversal as expected previously in test file. >> >> With Regards, >> Avik Niyogi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Nov 16 07:02:21 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 16 Nov 2015 12:32:21 +0530 Subject: Review request for JDK-6288609 JInternalFrame.setDefaultCloseOperation() interferes with "close" behavior In-Reply-To: <564472E0.6000009@oracle.com> References: <563CB511.70809@oracle.com> <9ada93ec-35ee-4434-adf1-b6348741dcf5@default> <564472E0.6000009@oracle.com> Message-ID: <56497F7D.4060201@oracle.com> Hi Rajeev, The fix looks ok to me. But, Don't we need to put this testcode in EDT? JInternalFrame internalFrame = desktopPane.getSelectedFrame(); 133 internalFrame.doDefaultCloseAction(); 134 internalFrame = desktopPane.getSelectedFrame(); Also, there are wildcard imports in test? Also, there is a repetition of code in lin119-130. Regards Prasanta On 11/12/2015 4:37 PM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 11/12/2015 12:05 PM, Rajeev Chamyal wrote: >> Hello Alexander, >> >> At all other places we call firePropertyChange(IS_CLOSED_PROPERTY, >> Boolean.FALSE,Boolean.TRUE); before calling dispose. Which will >> result in unselecting and closing the frame. >> If API user is extending the InternalFrameUI classes then they have >> to care of selection/deselection themselves. >> I have tested the fix with all look and feels on Windows and Ubuntu >> and on MAC with Aqua LAF as well. >> >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Alexander Scherbatiy >> Sent: 06 November 2015 19:41 >> To: Rajeev Chamyal >> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net >> Subject: Re: Review request for JDK-6288609 >> JInternalFrame.setDefaultCloseOperation() interferes with "close" >> behavior >> >> On 10/29/2015 10:41 AM, Rajeev Chamyal wrote: >>> Hello All, >>> >>> Please review the following fix for Jdk9: >>> *Bug*:https://bugs.openjdk.java.net/browse/JDK-6288609 >>> >>> *Webrev*:http://cr.openjdk.java.net/~rchamyal/6288609/webrev.00/ >>> >>> >>> *Issue*: On disposing the Top level JInternalFrame focus is not >>> shifting to the JInternalFrame below it. >>> >>> *Cause*: Dispose method is changing the selection of currently closing >>> frame and then it calls the DefaultDeskTopManager:closeFrame which >>> >>> finds the JInternalFrame below the closing frame based on selection of >>> the closing frame and then shifts the focus to frame below it. >>> >>> Since selection is already changed by dispose method >>> DefaultDeskTopManager:closeFrame is unable to find reference to >>> previous frame. >>> >>> *Fix*: Removed the selection change code from Dispose method. >> Are there any cases that the JInternalFrame is still selected >> after the IS_CLOSED_PROPERTY is fired in the dispose() method so it >> is still necessary to set the selection to false? >> >> Thanks, >> Alexandr. >> >>> Regards, >>> Rajeev Chamyal > From rajeev.chamyal at oracle.com Mon Nov 16 07:06:23 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Sun, 15 Nov 2015 23:06:23 -0800 (PST) Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX In-Reply-To: <6DBB9881-799B-4822-9E4A-50B5AF973750@oracle.com> References: <63A5405D-6251-4D5B-ADD2-F7DC03E90963@oracle.com> <6DBB9881-799B-4822-9E4A-50B5AF973750@oracle.com> Message-ID: <57809de9-a78f-47dc-86a0-727894ae84d9@default> Hello Avik, In case of test failure also frame should be disposed. Please add a dispose call before RuntimeException line 190. Regards, Rajeev Chamyal From: Avik Niyogi Sent: 16 November 2015 12:20 To: Rajeev Chamyal Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Re: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX Hi All, The bug fix has been updated as per the comments. http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.01/ With Regards, Avik Niyogi On 13-Nov-2015, at 9:46 am, Avik Niyogi wrote: Hi Rajeev, Will fix and create webrev.01 with inputs provided. Also, we have verified on Mac OS X, Windows and Ubuntu. With Regards, Avik Niyogi On 12-Nov-2015, at 4:52 pm, Rajeev Chamyal wrote: Hello Avik, 1) In the tryLookAndFeel exception handling is skipped. createUI and other calls should be skipped in case of exception.. 2) What all platforms you have tested the bug? Regards, Rajeev Chamyal From: Avik Niyogi Sent: 04 November 2015 14:51 To: Rajeev Chamyal; Alexander Scherbatiy; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8132770 Webrev: http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.00/ Issue: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX where non-eligible Look and Feels are not taken into account. Cause: TestCase flow for non-Basic JRadioButton UI such as Aqua, Nimbus and GTK have different focus traversal track as compared to the rest and require different test case flow with regards to focus owner. Fix: Modified test case with appropriate deviant test case for Look and Feels which are not eligible for focus traversal as expected previously in test file. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Mon Nov 16 08:54:01 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Mon, 16 Nov 2015 00:54:01 -0800 (PST) Subject: Review request for JDK-6288609 JInternalFrame.setDefaultCloseOperation() interferes with "close" behavior In-Reply-To: <56497F7D.4060201@oracle.com> References: <563CB511.70809@oracle.com> <9ada93ec-35ee-4434-adf1-b6348741dcf5@default> <564472E0.6000009@oracle.com> <56497F7D.4060201@oracle.com> Message-ID: <6e1f6822-109d-4d1f-9020-4edc782857eb@default> Hello Prasanta, Please review the updated webrev. I have updated it as per review comments. http://cr.openjdk.java.net/~rchamyal/6288609/webrev.01 Regards, Rajeev Chamyal -----Original Message----- From: prasanta sadhukhan Sent: 16 November 2015 12:32 To: Rajeev Chamyal Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Re: Review request for JDK-6288609 JInternalFrame.setDefaultCloseOperation() interferes with "close" behavior Hi Rajeev, The fix looks ok to me. But, Don't we need to put this testcode in EDT? JInternalFrame internalFrame = desktopPane.getSelectedFrame(); 133 internalFrame.doDefaultCloseAction(); 134 internalFrame = desktopPane.getSelectedFrame(); Also, there are wildcard imports in test? Also, there is a repetition of code in lin119-130. Regards Prasanta On 11/12/2015 4:37 PM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 11/12/2015 12:05 PM, Rajeev Chamyal wrote: >> Hello Alexander, >> >> At all other places we call firePropertyChange(IS_CLOSED_PROPERTY, >> Boolean.FALSE,Boolean.TRUE); before calling dispose. Which will >> result in unselecting and closing the frame. >> If API user is extending the InternalFrameUI classes then they have >> to care of selection/deselection themselves. >> I have tested the fix with all look and feels on Windows and Ubuntu >> and on MAC with Aqua LAF as well. >> >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Alexander Scherbatiy >> Sent: 06 November 2015 19:41 >> To: Rajeev Chamyal >> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net >> Subject: Re: Review request for JDK-6288609 >> JInternalFrame.setDefaultCloseOperation() interferes with "close" >> behavior >> >> On 10/29/2015 10:41 AM, Rajeev Chamyal wrote: >>> Hello All, >>> >>> Please review the following fix for Jdk9: >>> *Bug*:https://bugs.openjdk.java.net/browse/JDK-6288609 >>> >>> *Webrev*:http://cr.openjdk.java.net/~rchamyal/6288609/webrev.00/ >>> >>> >>> *Issue*: On disposing the Top level JInternalFrame focus is not >>> shifting to the JInternalFrame below it. >>> >>> *Cause*: Dispose method is changing the selection of currently >>> closing frame and then it calls the DefaultDeskTopManager:closeFrame >>> which >>> >>> finds the JInternalFrame below the closing frame based on selection >>> of the closing frame and then shifts the focus to frame below it. >>> >>> Since selection is already changed by dispose method >>> DefaultDeskTopManager:closeFrame is unable to find reference to >>> previous frame. >>> >>> *Fix*: Removed the selection change code from Dispose method. >> Are there any cases that the JInternalFrame is still selected >> after the IS_CLOSED_PROPERTY is fired in the dispose() method so it >> is still necessary to set the selection to false? >> >> Thanks, >> Alexandr. >> >>> Regards, >>> Rajeev Chamyal > From prasanta.sadhukhan at oracle.com Mon Nov 16 09:11:57 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 16 Nov 2015 14:41:57 +0530 Subject: Review request for JDK-6288609 JInternalFrame.setDefaultCloseOperation() interferes with "close" behavior In-Reply-To: <6e1f6822-109d-4d1f-9020-4edc782857eb@default> References: <563CB511.70809@oracle.com> <9ada93ec-35ee-4434-adf1-b6348741dcf5@default> <564472E0.6000009@oracle.com> <56497F7D.4060201@oracle.com> <6e1f6822-109d-4d1f-9020-4edc782857eb@default> Message-ID: <56499DDD.5000408@oracle.com> Looks ok to me. Regards Prasanta On 11/16/2015 2:24 PM, Rajeev Chamyal wrote: > Hello Prasanta, > > Please review the updated webrev. I have updated it as per review comments. > http://cr.openjdk.java.net/~rchamyal/6288609/webrev.01 > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: prasanta sadhukhan > Sent: 16 November 2015 12:32 > To: Rajeev Chamyal > Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net > Subject: Re: Review request for JDK-6288609 JInternalFrame.setDefaultCloseOperation() interferes with "close" behavior > > Hi Rajeev, > > The fix looks ok to me. > But, Don't we need to put this testcode in EDT? > > JInternalFrame internalFrame = desktopPane.getSelectedFrame(); > 133 internalFrame.doDefaultCloseAction(); > 134 internalFrame = desktopPane.getSelectedFrame(); > > Also, there are wildcard imports in test? > Also, there is a repetition of code in lin119-130. > > Regards > Prasanta > On 11/12/2015 4:37 PM, Alexander Scherbatiy wrote: >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 11/12/2015 12:05 PM, Rajeev Chamyal wrote: >>> Hello Alexander, >>> >>> At all other places we call firePropertyChange(IS_CLOSED_PROPERTY, >>> Boolean.FALSE,Boolean.TRUE); before calling dispose. Which will >>> result in unselecting and closing the frame. >>> If API user is extending the InternalFrameUI classes then they have >>> to care of selection/deselection themselves. >>> I have tested the fix with all look and feels on Windows and Ubuntu >>> and on MAC with Aqua LAF as well. >>> >>> Regards, >>> Rajeev Chamyal >>> >>> -----Original Message----- >>> From: Alexander Scherbatiy >>> Sent: 06 November 2015 19:41 >>> To: Rajeev Chamyal >>> Cc: Sergey Bylokhov; swing-dev at openjdk.java.net >>> Subject: Re: Review request for JDK-6288609 >>> JInternalFrame.setDefaultCloseOperation() interferes with "close" >>> behavior >>> >>> On 10/29/2015 10:41 AM, Rajeev Chamyal wrote: >>>> Hello All, >>>> >>>> Please review the following fix for Jdk9: >>>> *Bug*:https://bugs.openjdk.java.net/browse/JDK-6288609 >>>> >>>> *Webrev*:http://cr.openjdk.java.net/~rchamyal/6288609/webrev.00/ >>>> >>>> >>>> *Issue*: On disposing the Top level JInternalFrame focus is not >>>> shifting to the JInternalFrame below it. >>>> >>>> *Cause*: Dispose method is changing the selection of currently >>>> closing frame and then it calls the DefaultDeskTopManager:closeFrame >>>> which >>>> >>>> finds the JInternalFrame below the closing frame based on selection >>>> of the closing frame and then shifts the focus to frame below it. >>>> >>>> Since selection is already changed by dispose method >>>> DefaultDeskTopManager:closeFrame is unable to find reference to >>>> previous frame. >>>> >>>> *Fix*: Removed the selection change code from Dispose method. >>> Are there any cases that the JInternalFrame is still selected >>> after the IS_CLOSED_PROPERTY is fired in the dispose() method so it >>> is still necessary to set the selection to false? >>> >>> Thanks, >>> Alexandr. >>> >>>> Regards, >>>> Rajeev Chamyal From philip.race at oracle.com Mon Nov 16 22:09:24 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 16 Nov 2015 14:09:24 -0800 Subject: Review request for JDK-8030099 Memory usage of java process increases after pressing start button in test window In-Reply-To: <7de228d8-fe4d-4d61-989e-8afd090281d7@default> References: <562565A7.6000701@oracle.com> <56256D75.9010003@oracle.com> <6937cb71-466b-4972-b12a-15c5d7607b28@default> <56313450.4010704@oracle.com> <56327601.40103@oracle.com> <24f6a8c3-6070-4f64-9128-fc45b562349d@default> <56446ABB.6050000@oracle.com> <7de228d8-fe4d-4d61-989e-8afd090281d7@default> Message-ID: <564A5414.2030707@oracle.com> By both I meant like this : @run main/timeout=400 ShellFolderMemoryLeak @run main/timeout=400 -XX:+UseParallelGC ShellFolderMemoryLeak but its up to you .. at least having the default is the best single option. Approved. -phil. On 11/15/2015 09:21 PM, Rajeev Chamyal wrote: > Hello Phil, > > I have updated the test case as per your review comments. > Could you please review it. > http://cr.openjdk.java.net/~rchamyal/8030099/webrev.02/ > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Sergey Bylokhov > Sent: 12 November 2015 16:02 > To: Rajeev Chamyal; Philip Race; Alexander Scherbatiy; swing-dev at openjdk.java.net > Subject: Re: Review request for JDK-8030099 Memory usage of java process increases after pressing start button in test window > > Still looks fine to me. > > On 02.11.15 19:19, Rajeev Chamyal wrote: >> Hello Phil, >> >> Please review the updated webrev. >> http://cr.openjdk.java.net/~rchamyal/8030099/webrev.02/ >> >> The test case has been updated as per review comments. Added tests for both Parallel and default collector. >> >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Phil Race >> Sent: 30 October 2015 01:10 >> To: Rajeev Chamyal >> Cc: Sergey Bylokhov; Alexander Scherbatiy; swing-dev at openjdk.java.net >> Subject: Re: Review request for JDK-8030099 Memory usage of java >> process increases after pressing start button in test window >> >> It is arguably most important to run this with the *default* collector. >> If that changes to G1 (I think it is at least temporarily so changed in JDK 9) then we will never see problems in the case people end up using. >> >> But you obviously also want to test the case that shows the bug. >> >> So I would say the best option is to test both : explicit parallel GC and again with default .. even if they are the same there should be no harm done. >> >> You may want to increase timeout if running twice but you will have to verify that. >> >> -phil. >> >> >> On 10/29/2015 05:48 AM, Rajeev Chamyal wrote: >>> Hello Sergey, >>> >>> Please review the updated test case. >>> Webrev : http://cr.openjdk.java.net/~rchamyal/8030099/webrev.01/ >>> >>> As this issue is reported for Parallel GC collector. So, I have added -XX:+UseParallelGC to child process VM arguments in test case. >>> >>> Regards, >>> Rajeev Chamyal >>> >>> -----Original Message----- >>> From: Sergey Bylokhov >>> Sent: 29 October 2015 02:17 >>> To: Rajeev Chamyal; Philip Race >>> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net >>> Subject: Re: Review request for JDK-8030099 Memory usage of java >>> process increases after pressing start button in test window >>> >>> Thanks for clarification. >>> The fix looks fine. >>> >>> On 20.10.15 11:49, Rajeev Chamyal wrote: >>>> Hello Sergey, >>>> >>>> I mentioned incorrectly that JDK8 is using CMS as default garbage collector. JDK 8 uses Parallel GC as default collector. >>>> >>>> Following are the results with Parallel GC as default collector in JDK9. >>>> >>>> Max java process size before fix while running test case(webrev) : 220MB (approx.) JDK version build 1.9.0-ea-b86. >>>> Max java process size after fix while running test case(webrev) : 130MB(approx.). JDK9 version 1.9.0-internal-_2015_10_15_21_12-b00. >>>> >>>> Regards, >>>> Rajeev Chamyal >>>> >>>> -----Original Message----- >>>> From: Rajeev Chamyal >>>> Sent: 20 October 2015 12:10 >>>> To: Sergey Bylokhov; Philip Race >>>> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net >>>> Subject: RE: Review request for JDK-8030099 Memory usage of java >>>> process increases after pressing start button in test window >>>> >>>> Hello Sergey, >>>> >>>> Below are my observation while testing the fix. >>>> >>>> Max java process size before fix while running test case(webrev) : 170MB (approx.) JDK version build 1.9.0-ea-b86. >>>> Max java process size after fix while running test case(webrev) : 165MB(approx.). JDK9 version 1.9.0-internal-_2015_10_15_21_12-b00. >>>> The results are not consistent always in both cases. >>>> >>>> We cannot compare these results with JDK8 because it uses CMS collector as default garbage collector while JDK9 is using G1 collector. >>>> G1 collector is giving better results because it does heap compaction as well. >>>> >>>> We are using different reference types in different files ( files registering instances with Disposer) e.g. StrikeCache uses SoftReferences. >>>> >>>> Regards, >>>> Rajeev Chamyal >>>> >>>> -----Original Message----- >>>> From: Sergey Bylokhov >>>> Sent: 20 October 2015 03:54 >>>> To: Philip Race; Rajeev Chamyal >>>> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net >>>> Subject: Re: Review request for JDK-8030099 Memory usage of java >>>> process increases after pressing start button in test window >>>> >>>> On 20.10.15 0:50, Philip Race wrote: >>>>> The code change looks fine. The test is delightfully complicated. >>>> I still have not got a benefit of weak references in this use case. Does it mean that weak are always better? If yes, then we should at some point change default policy for all other cases as well. >>>> >>>>> Did you run it under jtreg ? >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 10/19/15, 5:10 AM, Rajeev Chamyal wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the following fix for Jdk9: >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030099 >>>>>> >>>>>> Webrev:http://cr.openjdk.java.net/~rchamyal/8030099/webrev.00/ >>>>>> >>>>>> >>>>>> Issue: The memory usage of java process goes on increasing if we >>>>>> call ShellFolder:listFiles API >>>>>> >>>>>> aggressively on some folder with large number of files/folders. >>>>>> >>>>>> Cause: Win32ShellFolder class registers its instances and native >>>>>> data with sun.java2d.Disposer class for later disposal. >>>>>> Win32ShellFolder instances are getting registered as >>>>>> PhantomReferences with Disposer and are not getting cleared immediately. >>>>>> This leads to increase of memory usage by java process. >>>>>> Fix: Instead of registering the complete Win32ShellFolder object >>>>>> reference with disposer we are now adding only a sentinel object >>>>>> and also using sun.java2d.Disposer :: addObjectRecord API which >>>>>> adds the references as WeakReferences. >>>>>> Regards, >>>>>> Rajeev Chamyal >>>>>> >>>> -- >>>> Best regards, Sergey. >>>> >>> -- >>> Best regards, Sergey. > > -- > Best regards, Sergey. From avik.niyogi at oracle.com Tue Nov 17 05:46:20 2015 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Tue, 17 Nov 2015 11:16:20 +0530 Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX In-Reply-To: <57809de9-a78f-47dc-86a0-727894ae84d9@default> References: <63A5405D-6251-4D5B-ADD2-F7DC03E90963@oracle.com> <6DBB9881-799B-4822-9E4A-50B5AF973750@oracle.com> <57809de9-a78f-47dc-86a0-727894ae84d9@default> Message-ID: Hi All, The bug fix has been updated as per comments. http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.02/ With Regards, Avik Niyogi > On 16-Nov-2015, at 12:36 pm, Rajeev Chamyal wrote: > > Hello Avik, > > In case of test failure also frame should be disposed. Please add a dispose call before RuntimeException line 190. > > Regards, > Rajeev Chamyal > > From: Avik Niyogi > Sent: 16 November 2015 12:20 > To: Rajeev Chamyal > Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net > Subject: Re: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX > > Hi All, > > The bug fix has been updated as per the comments. > http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.01/ > > > With Regards, > Avik Niyogi > > On 13-Nov-2015, at 9:46 am, Avik Niyogi > wrote: > > Hi Rajeev, > > Will fix and create webrev.01 with inputs provided. Also, we have verified on Mac OS X, Windows and Ubuntu. > > With Regards, > Avik Niyogi > > On 12-Nov-2015, at 4:52 pm, Rajeev Chamyal > wrote: > > Hello Avik, > > 1) In the tryLookAndFeel exception handling is skipped. createUI and other calls should be skipped in case of exception.. > 2) What all platforms you have tested the bug? > > Regards, > Rajeev Chamyal > > From: Avik Niyogi > Sent: 04 November 2015 14:51 > To: Rajeev Chamyal; Alexander Scherbatiy; swing-dev at openjdk.java.net > Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX > > Hi All, > > Kindly review the fix for JDK9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8132770 > > Webrev: http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.00/ > > Issue: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX where non-eligible Look and Feels are not taken into account. > > Cause: TestCase flow for non-Basic JRadioButton UI such as Aqua, Nimbus and GTK have different focus traversal track as compared to the rest and require different test case flow with regards to focus owner. > > Fix: Modified test case with appropriate deviant test case for Look and Feels which are not eligible for focus traversal as expected previously in test file. > > With Regards, > Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Tue Nov 17 06:01:45 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Mon, 16 Nov 2015 22:01:45 -0800 (PST) Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX In-Reply-To: References: <63A5405D-6251-4D5B-ADD2-F7DC03E90963@oracle.com> <6DBB9881-799B-4822-9E4A-50B5AF973750@oracle.com> <57809de9-a78f-47dc-86a0-727894ae84d9@default> Message-ID: <1fd8da29-2e86-46e0-9781-4753609bd8a3@default> The fix looks good to me. Regards, Rajeev Chamyal From: Avik Niyogi Sent: 17 November 2015 11:16 To: Rajeev Chamyal Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net Subject: Re: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX Hi All, The bug fix has been updated as per comments. http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.02/ With Regards, Avik Niyogi On 16-Nov-2015, at 12:36 pm, Rajeev Chamyal wrote: Hello Avik, In case of test failure also frame should be disposed. Please add a dispose call before RuntimeException line 190. Regards, Rajeev Chamyal From: Avik Niyogi Sent: 16 November 2015 12:20 To: Rajeev Chamyal Cc: Alexander Scherbatiy; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Re: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX Hi All, The bug fix has been updated as per the comments. http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.01/ With Regards, Avik Niyogi On 13-Nov-2015, at 9:46 am, Avik Niyogi wrote: Hi Rajeev, Will fix and create webrev.01 with inputs provided. Also, we have verified on Mac OS X, Windows and Ubuntu. With Regards, Avik Niyogi On 12-Nov-2015, at 4:52 pm, Rajeev Chamyal wrote: Hello Avik, 1) In the tryLookAndFeel exception handling is skipped. createUI and other calls should be skipped in case of exception.. 2) What all platforms you have tested the bug? Regards, Rajeev Chamyal From: Avik Niyogi Sent: 04 November 2015 14:51 To: Rajeev Chamyal; Alexander Scherbatiy; HYPERLINK "mailto:swing-dev at openjdk.java.net"swing-dev at openjdk.java.net Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8132770 Webrev: http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.00/ Issue: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX where non-eligible Look and Feels are not taken into account. Cause: TestCase flow for non-Basic JRadioButton UI such as Aqua, Nimbus and GTK have different focus traversal track as compared to the rest and require different test case flow with regards to focus owner. Fix: Modified test case with appropriate deviant test case for Look and Feels which are not eligible for focus traversal as expected previously in test file. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Nov 17 10:02:02 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 17 Nov 2015 13:02:02 +0300 Subject: Review for 8132770: Test javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in MacOSX In-Reply-To: <1fd8da29-2e86-46e0-9781-4753609bd8a3@default> References: <63A5405D-6251-4D5B-ADD2-F7DC03E90963@oracle.com> <6DBB9881-799B-4822-9E4A-50B5AF973750@oracle.com> <57809de9-a78f-47dc-86a0-727894ae84d9@default> <1fd8da29-2e86-46e0-9781-4753609bd8a3@default> Message-ID: <564AFB1A.4070608@oracle.com> The fix looks good to me. Thanks, Alexandr. On 11/17/2015 9:01 AM, Rajeev Chamyal wrote: > > The fix looks good to me. > > Regards, > > Rajeev Chamyal > > *From:*Avik Niyogi > *Sent:* 17 November 2015 11:16 > *To:* Rajeev Chamyal > *Cc:* Alexander Scherbatiy; swing-dev at openjdk.java.net > *Subject:* Re: Review for 8132770: Test > javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails in > MacOSX > > Hi All, > > The bug fix has been updated as per comments. > > http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.02/ > > > With Regards, > > Avik Niyogi > > On 16-Nov-2015, at 12:36 pm, Rajeev Chamyal > > wrote: > > Hello Avik, > > In case of test failure also frame should be disposed. Please add > a dispose call before RuntimeException line 190. > > Regards, > > Rajeev Chamyal > > *From:*Avik Niyogi > *Sent:*16 November 2015 12:20 > *To:*Rajeev Chamyal > *Cc:*Alexander Scherbatiy; swing-dev at openjdk.java.net > > *Subject:*Re: Review for 8132770: Test > javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails > in MacOSX > > Hi All, > > The bug fix has been updated as per the comments. > > http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.01/ > > > With Regards, > > Avik Niyogi > > On 13-Nov-2015, at 9:46 am, Avik Niyogi > > wrote: > > Hi Rajeev, > > Will fix and create webrev.01 with inputs provided. Also, we > have verified on Mac OS X, Windows and Ubuntu. > > With Regards, > > Avik Niyogi > > On 12-Nov-2015, at 4:52 pm, Rajeev Chamyal > > wrote: > > Hello Avik, > > 1) In the tryLookAndFeel exception handling is skipped. createUI and other calls should be skipped in case of exception.. > > 2) What all platforms you have tested the bug? > > > > Regards, > > Rajeev Chamyal > > *From:*Avik Niyogi > *Sent:*04 November 2015 14:51 > *To:*Rajeev Chamyal; Alexander > Scherbatiy;swing-dev at openjdk.java.net > > *Subject:*Review for 8132770: Test > javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails > in MacOSX > > Hi All, > > Kindly review the fix for JDK9. > > *Bug*: https://bugs.openjdk.java.net/browse/JDK-8132770 > > *Webrev*: > http://cr.openjdk.java.net/~rchamyal/avik/8132770/webrev.00/ > > > *Issue*: Test > javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails > in MacOSX where non-eligible Look and Feels are not taken > into account. > > *Cause*: TestCase flow for non-Basic JRadioButton UI such > as Aqua, Nimbus and GTK have different focus traversal > track as compared to the rest and require different test > case flow with regards to focus owner. > > *Fix*: Modified test case with appropriate deviant test > case for Look and Feels which are not eligible for focus > traversal as expected previously in test file. > > With Regards, > > Avik Niyogi > From alexandr.scherbatiy at oracle.com Tue Nov 17 10:04:13 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 17 Nov 2015 13:04:13 +0300 Subject: Review request for 7124218: Space should select cell in the JTable In-Reply-To: <9D982DDD-8AC0-4C9D-B2A1-9F764AF0794D@oracle.com> References: <706FBB8F-3206-4F11-B92E-C155BD2C2AE0@oracle.com> <564355A8.9090002@oracle.com> <9D982DDD-8AC0-4C9D-B2A1-9F764AF0794D@oracle.com> Message-ID: <564AFB9D.5050508@oracle.com> The fix looks good to me. Thanks, Alexandr. On 11/16/2015 9:48 AM, Avik Niyogi wrote: > Hi All, > > The bug fix has been updated as per the comments. > http://cr.openjdk.java.net/~rchamyal/avik/7124218/webrev.01/ > > > > With Regards, > Avik Niyogi > >> On 11-Nov-2015, at 8:20 pm, Alexander Scherbatiy >> > > wrote: >> >> >> - May be isMac() method can only check L&F because a L&F which >> contains Mac description usually implies that it is L&F designed for >> Mac OS X >> - isMac(osName, lookAndFeel) check is used to do different actions >> but the only essential difference is in the provided key code. >> it can be changed to keyTap(isMac(...) ? KeyEvent.VK_ENTER : >> KeyEvent.SPACE) >> - The exception handling in the tryLookAndFeel() method is skipped. >> What should be the test behavior in case if it is not possible to >> set a L&F? >> - runTestCase() method should access JTable methods on EDT. >> >> Thanks, >> Alexandr. >> >> On 11/3/2015 12:20 PM, Avik Niyogi wrote: >>> Hi All, >>> >>> Kindly review the fix for JDK9. >>> *Bug*: https://bugs.openjdk.java.net/browse/JDK-7124218 >>> >>> *Webrev*: >>> http://cr.openjdk.java.net/~rchamyal/avik/7124218/webrev.00/ >>> >>> >>> >>> *Issue*: "Space should select cell in the JTable" is being expected >>> for Look and Feels (and OS) >>> where key-bindings are different. >>> >>> *Cause*: Keybindings expected in the test case are not taking native >>> key-bindings into account. >>> >>> *Fix*: Recreated test case with appropriate cases for all required >>> OS to account >>> for supported native, non-native and cross-platform Look and Feels. >>> >>> With Regards, >>> Avik Niyogi >> > From rajeev.chamyal at oracle.com Tue Nov 17 10:41:23 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Tue, 17 Nov 2015 02:41:23 -0800 (PST) Subject: Review request for 7124218: Space should select cell in the JTable In-Reply-To: <564AFB9D.5050508@oracle.com> References: <706FBB8F-3206-4F11-B92E-C155BD2C2AE0@oracle.com> <564355A8.9090002@oracle.com> <9D982DDD-8AC0-4C9D-B2A1-9F764AF0794D@oracle.com> <564AFB9D.5050508@oracle.com> Message-ID: <9eacdcf1-279a-45c7-bdbe-5e8fda1b519d@default> The fix looks good to me. Regards, Rajeev Chamyal -----Original Message----- From: Alexander Scherbatiy Sent: 17 November 2015 15:34 To: Avik Niyogi Cc: Rajeev Chamyal; swing-dev at openjdk.java.net Subject: Re: Review request for 7124218: Space should select cell in the JTable The fix looks good to me. Thanks, Alexandr. On 11/16/2015 9:48 AM, Avik Niyogi wrote: > Hi All, > > The bug fix has been updated as per the comments. > http://cr.openjdk.java.net/~rchamyal/avik/7124218/webrev.01/ > > > > With Regards, > Avik Niyogi > >> On 11-Nov-2015, at 8:20 pm, Alexander Scherbatiy >> > > wrote: >> >> >> - May be isMac() method can only check L&F because a L&F which >> contains Mac description usually implies that it is L&F designed for >> Mac OS X >> - isMac(osName, lookAndFeel) check is used to do different actions >> but the only essential difference is in the provided key code. >> it can be changed to keyTap(isMac(...) ? KeyEvent.VK_ENTER : >> KeyEvent.SPACE) >> - The exception handling in the tryLookAndFeel() method is skipped. >> What should be the test behavior in case if it is not possible to >> set a L&F? >> - runTestCase() method should access JTable methods on EDT. >> >> Thanks, >> Alexandr. >> >> On 11/3/2015 12:20 PM, Avik Niyogi wrote: >>> Hi All, >>> >>> Kindly review the fix for JDK9. >>> *Bug*: https://bugs.openjdk.java.net/browse/JDK-7124218 >>> >>> *Webrev*: >>> http://cr.openjdk.java.net/~rchamyal/avik/7124218/webrev.00/ >>> >>> >>> >>> *Issue*: "Space should select cell in the JTable" is being expected >>> for Look and Feels (and OS) where key-bindings are different. >>> >>> *Cause*: Keybindings expected in the test case are not taking native >>> key-bindings into account. >>> >>> *Fix*: Recreated test case with appropriate cases for all required >>> OS to account for supported native, non-native and cross-platform >>> Look and Feels. >>> >>> With Regards, >>> Avik Niyogi >> > From Sergey.Bylokhov at oracle.com Tue Nov 17 20:35:35 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 17 Nov 2015 23:35:35 +0300 Subject: design question regarding UI defaults and painting In-Reply-To: <950E0B0B-6F9D-4737-BAA0-150CEBA80456@cbfiddle.com> References: <950E0B0B-6F9D-4737-BAA0-150CEBA80456@cbfiddle.com> Message-ID: <564B8F97.5010009@oracle.com> On 13.11.15 0:41, Alan Snyder wrote: > I am curious about a design decision that was made in the implementation > of textured window backgrounds in the Aqua LAF/AWT. > > In a nutshell, a textured window background is an optional NSWindow > background style that involves gradients. Right. It is not necessary should be applied to all application windows. > > I am wondering why a more straightforward solution was not chosen -- > making isOpaque()==false and background==Color(0,0,0,0) the default for > all components that normally reveal the window background. > > (I tried this and it seems to work. I see various comments in the code > that there must be an opaque component at the top of the hierarchy, but > I have not found that to be true on OS X.) > > Is this a performance issue? A compatibility issue? An architectural issue? This solution was selected because it does not require the changes in the components or in the UI delegates and automatically applies to the most of our components. For example how you will handle the situation, when the component was created, but was not added to the window, what background it will have? and when it will be changed to 0,0,0,0? > > The components that would need to change are JPanel, JRootPane, > JLayeredPane, JOptionPane, JSplitPane, JToolBar. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Nov 18 20:49:50 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 18 Nov 2015 23:49:50 +0300 Subject: [9] Review Request: 8143256 The build is broken after JDK-8081411 Message-ID: <564CE46E.9020405@oracle.com> Hello. Please review the fix for jdk9. The build is broken after JDK-8081411. The code on unix is not updated to use interface SynthIcon instead of class. Bug: https://bugs.openjdk.java.net/browse/JDK-8143256 Webrev can be found at: http://cr.openjdk.java.net/~serb/8143256/webrev.01 -- Best regards, Sergey. From omajid at redhat.com Wed Nov 18 21:05:25 2015 From: omajid at redhat.com (Omair Majid) Date: Wed, 18 Nov 2015 16:05:25 -0500 Subject: [9] Review Request: 8143256 The build is broken after JDK-8081411 In-Reply-To: <564CE46E.9020405@oracle.com> References: <564CE46E.9020405@oracle.com> Message-ID: <20151118210524.GD2666@redhat.com> * Sergey Bylokhov [2015-11-18 15:50]: > Hello. > Please review the fix for jdk9. > The build is broken after JDK-8081411. The code on unix is not updated to > use interface SynthIcon instead of class. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143256 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8143256/webrev.01 I came up with a very similar fix that fixes the build for me: http://cr.openjdk.java.net/~omajid/webrevs/8143256-broken-build/00/ But you are much faster than me! I guess this counts as a +1 from me :) Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From rajeev.chamyal at oracle.com Thu Nov 19 10:09:11 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 19 Nov 2015 02:09:11 -0800 (PST) Subject: JDK9 Review Request for 8067660: JFileChooser create new folder fails silently Message-ID: Hello All, Please review the following fix for Jdk9: Bug: https://bugs.openjdk.java.net/browse/JDK-8067660 Webrev: http://cr.openjdk.java.net/~rchamyal/8067660/webrev.00/ Issue: jFileChooser create new folder fails silently on windows without any exception. Fix: Throwing an IOException from GenericFileSystemView:: createNewFolder, WindowsFileSystemView:: createNewFolder and UnixFileSystemView:: createNewFolder if mkdirs call returns false. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Nov 19 15:40:01 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 19 Nov 2015 18:40:01 +0300 Subject: Review request for 8133039 Provide public API to sun.swing.UIAction#isEnabled(Object) In-Reply-To: References: <5641D44C.5040902@oracle.com> <5643412D.70305@oracle.com> Message-ID: <564DED51.7030801@oracle.com> Probably we should strictly specify relationship between the accept and isEnabled? My assumption that the accept should always return false in case of disabled Action. And related issue after we open part of UIAction is that UIAction ignores the setEnabled() and actually contradicts the specification of the parent. SO this can mislead the user, that the accept can return true after setEnabled(false). On 11.11.15 16:59, Andrej Golovnin wrote: > Hi Alexander, > >> You are right. >> >> There is the updated fix there the sender type is Object: >> http://cr.openjdk.java.net/~alexsch/8133039/webrev.01 >> > > this one looks good for me. > > Best regards, > Andrej Golovnin > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri Nov 20 14:01:17 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 20 Nov 2015 17:01:17 +0300 Subject: Review request for 8133039 Provide public API to sun.swing.UIAction#isEnabled(Object) In-Reply-To: <564DED51.7030801@oracle.com> References: <5641D44C.5040902@oracle.com> <5643412D.70305@oracle.com> <564DED51.7030801@oracle.com> Message-ID: <564F27AD.8040609@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8133039/webrev.02/ The description that accept() method must return false for the disabled action is added. Thanks, Alexandr. On 11/19/2015 6:40 PM, Sergey Bylokhov wrote: > Probably we should strictly specify relationship between the accept > and isEnabled? > My assumption that the accept should always return false in case > of disabled Action. And related issue after we open part of UIAction > is that UIAction ignores the setEnabled() and actually contradicts the > specification of the parent. SO this can mislead the user, that the > accept can return true after setEnabled(false). > > On 11.11.15 16:59, Andrej Golovnin wrote: >> Hi Alexander, >> >>> You are right. >>> >>> There is the updated fix there the sender type is Object: >>> http://cr.openjdk.java.net/~alexsch/8133039/webrev.01 >>> >> >> this one looks good for me. >> >> Best regards, >> Andrej Golovnin >> > > From peter.brunet at oracle.com Fri Nov 20 17:24:47 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 20 Nov 2015 11:24:47 -0600 Subject: RfR JDK-8056925 Add jaccessinspector and jaccesswalker to the bin directory Message-ID: <564F575F.2090007@oracle.com> Please review: http://cr.openjdk.java.net/~ptbrunet/JDK-8056925/webrev.00/ From vivi.an at oracle.com Fri Nov 20 17:45:33 2015 From: vivi.an at oracle.com (Vivi An) Date: Fri, 20 Nov 2015 09:45:33 -0800 Subject: RfR JDK-8056925 Add jaccessinspector and jaccesswalker to the bin directory In-Reply-To: <564F575F.2090007@oracle.com> References: <564F575F.2090007@oracle.com> Message-ID: <564F5C3D.5080401@oracle.com> Looks good to me. Thanks Vivi On 11/20/2015 9:24 AM, Pete Brunet wrote: > Please review: > http://cr.openjdk.java.net/~ptbrunet/JDK-8056925/webrev.00/ From philip.race at oracle.com Fri Nov 20 21:07:49 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 20 Nov 2015 13:07:49 -0800 Subject: RfR JDK-8056925 Add jaccessinspector and jaccesswalker to the bin directory In-Reply-To: <564F575F.2090007@oracle.com> References: <564F575F.2090007@oracle.com> Message-ID: <564F8BA5.3030608@oracle.com> On 11/20/2015 09:24 AM, Pete Brunet wrote: > Please review: > http://cr.openjdk.java.net/~ptbrunet/JDK-8056925/webrev.00/ 42 char *printError(char *msg) { 43 LPVOID lpMsgBuf = NULL; 44 static char retbuf[256]; 45 46 if (msg != NULL) { 47 strncpy((char *)retbuf, msg, sizeof(retbuf)); 48 } If msg length >=256 chars you will not get a null terminated string. I don't see that happening anywhere but defensive coding is best. -phil. From peter.brunet at oracle.com Fri Nov 20 23:20:44 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 20 Nov 2015 17:20:44 -0600 Subject: RfR JDK-8056925 Add jaccessinspector and jaccesswalker to the bin directory In-Reply-To: <564F8BA5.3030608@oracle.com> References: <564F575F.2090007@oracle.com> <564F8BA5.3030608@oracle.com> Message-ID: <564FAACC.4070103@oracle.com> Thanks for looking at this Phil. How's this: http://cr.openjdk.java.net/~ptbrunet/JDK-8056925/webrev.01/ Pete On 11/20/15 3:07 PM, Phil Race wrote: > On 11/20/2015 09:24 AM, Pete Brunet wrote: >> Please review: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8056925/webrev.00/ > > 42 char *printError(char *msg) { > 43 LPVOID lpMsgBuf = NULL; > 44 static char retbuf[256]; > 45 > 46 if (msg != NULL) { > 47 strncpy((char *)retbuf, msg, sizeof(retbuf)); > 48 } > > If msg length >=256 chars you will not get a null terminated string. > I don't see that happening anywhere but defensive coding is best. > > -phil. > > From philip.race at oracle.com Fri Nov 20 23:22:01 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 20 Nov 2015 15:22:01 -0800 Subject: RfR JDK-8056925 Add jaccessinspector and jaccesswalker to the bin directory In-Reply-To: <564FAACC.4070103@oracle.com> References: <564F575F.2090007@oracle.com> <564F8BA5.3030608@oracle.com> <564FAACC.4070103@oracle.com> Message-ID: <564FAB19.4060305@oracle.com> looks good. -phil. On 11/20/2015 03:20 PM, Pete Brunet wrote: > Thanks for looking at this Phil. How's this: > http://cr.openjdk.java.net/~ptbrunet/JDK-8056925/webrev.01/ > > Pete > > On 11/20/15 3:07 PM, Phil Race wrote: >> On 11/20/2015 09:24 AM, Pete Brunet wrote: >>> Please review: >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8056925/webrev.00/ >> 42 char *printError(char *msg) { >> 43 LPVOID lpMsgBuf = NULL; >> 44 static char retbuf[256]; >> 45 >> 46 if (msg != NULL) { >> 47 strncpy((char *)retbuf, msg, sizeof(retbuf)); >> 48 } >> >> If msg length >=256 chars you will not get a null terminated string. >> I don't see that happening anywhere but defensive coding is best. >> >> -phil. >> >> From alexandr.scherbatiy at oracle.com Mon Nov 23 15:52:28 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 23 Nov 2015 18:52:28 +0300 Subject: [9] Review request for 8132119 Provide public API for text related methods in SwingUtilities2 In-Reply-To: <55F6DC3C.60809@oracle.com> References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com> <55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com> Message-ID: <5653363C.5030105@oracle.com> Hello, Could you review the updated fix? Thanks, Alexandr. On 9/14/2015 5:39 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/ > > I tried to use Utilities.drawStringUnderlineCharAt(...) with chars > that have > - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01) > The whole glyph is underlined. > - 2 characters: 1 glyph mapping (supplementary char U+10400) > > The char value specified the the underlined index should point to > the high-surrogate range of a supplementary character. > I updated the javadoc for the > Utilities.drawStringUnderlineCharAt(...) method to: > ----------------------------- > /** > * Draws the given string at the specified location underlining > * the specified character. > *

> * The underlined index refers to char values (Unicode code units). > * If the char value specified at the given underlined index is in > * the high-surrogate range and the char value at the following > index is in > * the low-surrogate range then the supplementary character > corresponding > * to this surrogate pair is underlined. > *

> * Nothing is drawn for null string. No character is underlined > for the > * index {@code < 0}, {@code >=} than the string width or if the > char value > * specified at the given index is in the low-surrogate range. > ----------------------------- > > Thanks, > Alexandr. > > On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote: >> On 9/2/2015 8:09 PM, Phil Race wrote: >>> I don't remember or know how Swing resolves this but the measurement >>> ones >>> are not reliable since they do not take a Graphics context, so you >>> cannot >>> measure the string properly. You need a FontRenderContext to measure. >> >> The provided methods use >> SwingUtilities2.getFontRenderContext(JComponent) method which returns >> the FontRenderContext associated with the component. >> >>> >>> So as it stands these APIs do not appear suitable to be made public >>> as they >>> are not reliable. >>> >>> Whilst I could look at the code, if I instead just look at the API, >>> I am scratching my >>> head over :- >>> >>> public static void drawString(JComponent c, Graphics g, String >>> text, int x, int y) >>> >>> Here you provide the Graphics *and* the Component. >>> And it says the JComponent may be null. >>> So I am supposing that there is optional information that may be >>> pulled from the >>> JComponent regarding rendering mode ? >> >> The optional information provided by the component is: >> - java.awt.font.NumericShaper >> - java.awt.font.FontRenderContext >> - antialiasing hints >> >>> >>> drawStringUnderlineCharAt(..) probably needs to explain if the index >>> is code point >>> or UTF16 char index and what happens if there is not 1:1 code >>> point:glyph mapping. >> I will update this. >>> >>> Are we sure that (any of) these really ought/need to be public - >>> particularly given the >>> resolution of https://bugs.openjdk.java.net/browse/JDK-6302464 >> >> These methods are used by JDK L&Fs to draw text. The initial >> request was to provide public methods that can be used by a custom >> L&F to draw strings consistently with other L&Fs. >> >> They are also designed to properly render text for printing. To do >> that they use call to internal ProxyPrintGraphics class to obtain the >> print graphics context. >> >> Even if printing staff will be public, these methods are just >> utility methods (in the same way as other text methods in the >> javax.swing.text.Utilities class) that help easily to draw and print >> text in the same way as JDK L&Fs do that. >> >> Thanks, >> Alexandr. >> >>> >>> -phil. >>> >>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8132119/webrev.00 >>>> >>>> The suggested drawString, drawStringUnderlineCharAt, >>>> clipStringIfNecessary, and stringWidth methods are >>>> added to the javax.swing.text.Utilities class. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >> > From semyon.sadetsky at oracle.com Tue Nov 24 10:01:41 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 24 Nov 2015 13:01:41 +0300 Subject: [9] Review Request for 8081722: Provide public API for file hierarchy provided by sun.awt.shell.ShellFolder In-Reply-To: <5637C2DD.6060801@oracle.com> References: <562E2FD1.1070301@oracle.com> <563265D5.8010205@oracle.com> <5637C2DD.6060801@oracle.com> Message-ID: <56543585.60401@oracle.com> On 11/2/2015 11:09 PM, Sergey Bylokhov wrote: > On 29.10.15 21:30, Phil Race wrote: >> We should specify what happens if you pass in to get(String) >> a) null >> b) an unrecognised name. >> >> Would it make sense to define string constants on FileSystemView >> as otherwise people have to spell these exactly right without compiler >> help ? >> >> Also I expect (hope!) that we do not assert any privileges here so there >> will be a SecurityException if the caller does not have the necessary >> permissions. >> That should be documented. >> >> I find it odd that isLink(File) catches FNFE and just returns "false" >> like this >> was a normal file. Why is that ? In fact I find it particularly odd >> since >> getLinkLocation() *does* throw FNFE if it does not exist. > > I guess the new code should follow the rules which are used by > other methods in the same class, most of them catch FNFE and return > some default value. Also most of them returns default value if the > passed File is null. Anyway I think that NPE is better than IAE. At > least we should discuss this. Could you explain why NPE is better? I supposed in case of an incorrect method usage IAE is more precise than generic NPE. The FNFE is used in some methods of the class. I think that is justified if the linked file is not found. In other cases it is caught. > > I am not sure why this methods are static unlike old/others methods(). I agree, we should be following the class "style", so I have removed static modifiers. The updated webrev: http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.02/ > > public static Object get(String key) {} > Probably this method too flexible? What kind of use case for this > method inside the users application? How the user will know which > parameters to use in a cross-platform manner? > > For example "fileChooserDefaultFolder" property already covered by > FileSystemView.getDefaultDirectory(), the "roots" is covered by > getRoots(). I don't think that we should elaborate a new Shell API in this fix, because we initially aimed to make the minimal change we can to support NetBeans ShellFolder extension. We did a poll on the public alias which showed nobody else need this API to be opened. > > >> >> Also the docs casually say >> "a shell interpreted link" and "platform shell" without explaining >> what they mean by a shell. Should this term be used at all or >> should the docs describe this in some other words ? >> >> getLinkLocation says >> >> "Returns a file linked to the specified file if the specified file" >> >> What that reads like to me is that you get back a link if >> you pass in a regular file, whereas (I believe) you mean >> the opposite. >> >> I think you mean : >> "Returns the regular file referenced by the specified link file" >> >> I also note that one of the uses we located was of >> ShellFolder.getShellFolder(File) >> That internal API returns a ShellFolder but it we expose that it would >> have to >> be the java.io.File superclass I expect. >> >> -phil. >> >> >> >> >> >> >> >> >> >> -phil. >> >> >> On 10/26/2015 06:51 AM, Semyon Sadetsky wrote: >>> Hello, >>> >>> Please review fix for JDK9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8081722 >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8081722/webrev.00 >>> >>> As the solution it is suggested to have 3 new static methods in the >>> javax.swing.filechooser.FileSystemView class. Those methods proxy >>> sun.awt.shell.ShellFolder calls and it is enough to cover NetBeans >>> request. getShellFolder() method is not added because it returns the >>> ShellFolder instance which is not for public use under the proposed >>> approach. >>> The CCC request will be rework when the fix is approved. >>> >>> --Semyon >> > > From andrej.golovnin at gmail.com Tue Nov 24 10:25:45 2015 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Tue, 24 Nov 2015 11:25:45 +0100 Subject: [9] Review request for 8132119 Provide public API for text related methods in SwingUtilities2 In-Reply-To: <5653363C.5030105@oracle.com> References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com> <55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com> <5653363C.5030105@oracle.com> Message-ID: Hi Alexander, >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/ >> in the JavaDocs of the methods #drawStringUnderlineCharAt and #getClippedString you put the @see tag before the parameters description, see lines 1125 and 1145. In the most cases the @see tag is placed after @param tags but before the @since tag. Otherwise looks good for me. But I'm not a reviewer. You will still need one. :-) Best regards, Andrej Golovnin From Sergey.Bylokhov at oracle.com Tue Nov 24 13:54:37 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Nov 2015 16:54:37 +0300 Subject: Review request for 8133039 Provide public API to sun.swing.UIAction#isEnabled(Object) In-Reply-To: <564F27AD.8040609@oracle.com> References: <5641D44C.5040902@oracle.com> <5643412D.70305@oracle.com> <564DED51.7030801@oracle.com> <564F27AD.8040609@oracle.com> Message-ID: <56546C1D.6060001@oracle.com> Looks fine. On 20.11.15 17:01, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8133039/webrev.02/ > > The description that accept() method must return false for the > disabled action is added. > > Thanks, > Alexandr. > > On 11/19/2015 6:40 PM, Sergey Bylokhov wrote: >> Probably we should strictly specify relationship between the accept >> and isEnabled? >> My assumption that the accept should always return false in case >> of disabled Action. And related issue after we open part of UIAction >> is that UIAction ignores the setEnabled() and actually contradicts the >> specification of the parent. SO this can mislead the user, that the >> accept can return true after setEnabled(false). >> >> On 11.11.15 16:59, Andrej Golovnin wrote: >>> Hi Alexander, >>> >>>> You are right. >>>> >>>> There is the updated fix there the sender type is Object: >>>> http://cr.openjdk.java.net/~alexsch/8133039/webrev.01 >>>> >>> >>> this one looks good for me. >>> >>> Best regards, >>> Andrej Golovnin >>> >> >> > -- Best regards, Sergey. From peter.brunet at oracle.com Wed Nov 25 04:23:28 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 24 Nov 2015 22:23:28 -0600 Subject: Tool to display Swing control hierarchy Message-ID: <565537C0.5030700@oracle.com> Is there a tool that will show me the control hierarchy of a Swing app? -Pete From peter.brunet at oracle.com Wed Nov 25 05:05:21 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 24 Nov 2015 23:05:21 -0600 Subject: Tool to display Swing control hierarchy In-Reply-To: <565537C0.5030700@oracle.com> References: <565537C0.5030700@oracle.com> Message-ID: <56554191.7090601@oracle.com> https://github.com/robotframework/swingexplorer On 11/24/15 10:23 PM, Pete Brunet wrote: > Is there a tool that will show me the control hierarchy of a Swing app? > -Pete From andrej.golovnin at gmail.com Wed Nov 25 07:03:32 2015 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Wed, 25 Nov 2015 08:03:32 +0100 Subject: Tool to display Swing control hierarchy In-Reply-To: <565537C0.5030700@oracle.com> References: <565537C0.5030700@oracle.com> Message-ID: Hi Pete, start your Swing application from the console. When you application is started and has focus, then press CTRL-SHIFT-F1. Now you should see the control hierarchy in the console. Best regards, Andrej Golovnin On Wed, Nov 25, 2015 at 5:23 AM, Pete Brunet wrote: > Is there a tool that will show me the control hierarchy of a Swing app? > -Pete From alexander.zvegintsev at oracle.com Wed Nov 25 13:23:07 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 25 Nov 2015 16:23:07 +0300 Subject: Review request for 8133039 Provide public API to sun.swing.UIAction#isEnabled(Object) In-Reply-To: <56546C1D.6060001@oracle.com> References: <5641D44C.5040902@oracle.com> <5643412D.70305@oracle.com> <564DED51.7030801@oracle.com> <564F27AD.8040609@oracle.com> <56546C1D.6060001@oracle.com> Message-ID: <5655B63B.4040800@oracle.com> +1 Thanks, Alexander. On 11/24/2015 04:54 PM, Sergey Bylokhov wrote: > Looks fine. > > On 20.11.15 17:01, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8133039/webrev.02/ >> >> The description that accept() method must return false for the >> disabled action is added. >> >> Thanks, >> Alexandr. >> >> On 11/19/2015 6:40 PM, Sergey Bylokhov wrote: >>> Probably we should strictly specify relationship between the accept >>> and isEnabled? >>> My assumption that the accept should always return false in case >>> of disabled Action. And related issue after we open part of UIAction >>> is that UIAction ignores the setEnabled() and actually contradicts the >>> specification of the parent. SO this can mislead the user, that the >>> accept can return true after setEnabled(false). >>> >>> On 11.11.15 16:59, Andrej Golovnin wrote: >>>> Hi Alexander, >>>> >>>>> You are right. >>>>> >>>>> There is the updated fix there the sender type is Object: >>>>> http://cr.openjdk.java.net/~alexsch/8133039/webrev.01 >>>>> >>>> >>>> this one looks good for me. >>>> >>>> Best regards, >>>> Andrej Golovnin >>>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Wed Nov 25 13:24:49 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 25 Nov 2015 16:24:49 +0300 Subject: Tool to display Swing control hierarchy In-Reply-To: References: <565537C0.5030700@oracle.com> Message-ID: <5655B6A1.6000703@oracle.com> Note that in jdk9 this option is disabled by default, to enable it you should pass -Dsun.awt.nativedebug=true to the java. On 25.11.15 10:03, Andrej Golovnin wrote: > Hi Pete, > > start your Swing application from the console. When you application is > started and has focus, then press CTRL-SHIFT-F1. Now you should see > the control hierarchy in the console. > > Best regards, > Andrej Golovnin > > On Wed, Nov 25, 2015 at 5:23 AM, Pete Brunet wrote: >> Is there a tool that will show me the control hierarchy of a Swing app? >> -Pete -- Best regards, Sergey. From andrej.golovnin at gmail.com Wed Nov 25 13:44:20 2015 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Wed, 25 Nov 2015 14:44:20 +0100 Subject: Tool to display Swing control hierarchy In-Reply-To: <5655B6A1.6000703@oracle.com> References: <565537C0.5030700@oracle.com> <5655B6A1.6000703@oracle.com> Message-ID: On Wed, Nov 25, 2015 at 2:24 PM, Sergey Bylokhov wrote: > Note that in jdk9 this option is disabled by default, to enable it you > should pass -Dsun.awt.nativedebug=true to the java. Sergey, thank you for the hint! I didn't know that. Best regards, Andrej Golovnin From alexandr.scherbatiy at oracle.com Wed Nov 25 15:28:43 2015 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 25 Nov 2015 18:28:43 +0300 Subject: [9] Review request for 8132119 Provide public API for text related methods in SwingUtilities2 In-Reply-To: <55F6DC3C.60809@oracle.com> References: <55E715A1.3090008@oracle.com> <55E72D3A.60807@oracle.com> <55ED586F.5070509@oracle.com> <55F6DC3C.60809@oracle.com> Message-ID: <5655D3AB.9050503@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8132119/webrev.02 The javadoc references for the #drawStringUnderlineCharAt and #getClippedString methods are moved after parameters description. Thanks, Alexandr. 14.09.2015 17:39, Alexander Scherbatiy ?????: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8132119/webrev.01/ > > I tried to use Utilities.drawStringUnderlineCharAt(...) with chars > that have > - 1 character:2 glyphs mapping (U+00E1) and ligature (U+FB01) > The whole glyph is underlined. > - 2 characters: 1 glyph mapping (supplementary char U+10400) > > The char value specified the the underlined index should point to the > high-surrogate range of a supplementary character. > I updated the javadoc for the Utilities.drawStringUnderlineCharAt(...) > method to: > ----------------------------- > /** > * Draws the given string at the specified location underlining > * the specified character. > *

> * The underlined index refers to char values (Unicode code units). > * If the char value specified at the given underlined index is in > * the high-surrogate range and the char value at the following index > is in > * the low-surrogate range then the supplementary character corresponding > * to this surrogate pair is underlined. > *

> * Nothing is drawn for null string. No character is underlined for the > * index {@code < 0}, {@code >=} than the string width or if the char > value > * specified at the given index is in the low-surrogate range. > ----------------------------- > > Thanks, > Alexandr. > > On 9/7/2015 12:27 PM, Alexander Scherbatiy wrote: >> On 9/2/2015 8:09 PM, Phil Race wrote: >>> I don't remember or know how Swing resolves this but the measurement >>> ones >>> are not reliable since they do not take a Graphics context, so you >>> cannot >>> measure the string properly. You need a FontRenderContext to measure. >> >> The provided methods use >> SwingUtilities2.getFontRenderContext(JComponent) method which returns >> the FontRenderContext associated with the component. >> >>> >>> So as it stands these APIs do not appear suitable to be made public >>> as they >>> are not reliable. >>> >>> Whilst I could look at the code, if I instead just look at the API, >>> I am scratching my >>> head over :- >>> >>> public static void drawString(JComponent c, Graphics g, String text, >>> int x, int y) >>> >>> Here you provide the Graphics *and* the Component. >>> And it says the JComponent may be null. >>> So I am supposing that there is optional information that may be >>> pulled from the >>> JComponent regarding rendering mode ? >> >> The optional information provided by the component is: >> - java.awt.font.NumericShaper >> - java.awt.font.FontRenderContext >> - antialiasing hints >> >>> >>> drawStringUnderlineCharAt(..) probably needs to explain if the index >>> is code point >>> or UTF16 char index and what happens if there is not 1:1 code >>> point:glyph mapping. >> I will update this. >>> >>> Are we sure that (any of) these really ought/need to be public - >>> particularly given the >>> resolution of https://bugs.openjdk.java.net/browse/JDK-6302464 >> >> These methods are used by JDK L&Fs to draw text. The initial request >> was to provide public methods that can be used by a custom L&F to >> draw strings consistently with other L&Fs. >> >> They are also designed to properly render text for printing. To do >> that they use call to internal ProxyPrintGraphics class to obtain the >> print graphics context. >> >> Even if printing staff will be public, these methods are just utility >> methods (in the same way as other text methods in the >> javax.swing.text.Utilities class) that help easily to draw and print >> text in the same way as JDK L&Fs do that. >> >> Thanks, >> Alexandr. >> >>> >>> -phil. >>> >>> On 09/02/2015 08:28 AM, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132119 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8132119/webrev.00 >>>> >>>> The suggested drawString, drawStringUnderlineCharAt, >>>> clipStringIfNecessary, and stringWidth methods are >>>> added to the javax.swing.text.Utilities class. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >> > From alexandr.scherbatiy at oracle.com Wed Nov 25 15:59:48 2015 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 25 Nov 2015 18:59:48 +0300 Subject: JDK9 Review Request for 8067660: JFileChooser create new folder fails silently In-Reply-To: References: Message-ID: <5655DAF4.50400@oracle.com> 19.11.2015 13:09, Rajeev Chamyal ?????: > Hello All, > > Please review the following fix for Jdk9: > > Bug:https://bugs.openjdk.java.net/browse/JDK-8067660 > > Webrev:http://cr.openjdk.java.net/~rchamyal/8067660/webrev.00/ > > > Issue: jFileChooser create new folder fails silently on windows > without any exception. > > Fix: Throwing an IOException from > GenericFileSystemView::createNewFolder,WindowsFileSystemView::createNewFolder > andUnixFileSystemView::createNewFolder if mkdirs call returns false. > The exception message in the fix is: "Access denied". Are there other reasons for which the File.mkdirs() can return false? Thanks, Alexandr. > > Regards, > Rajeev Chamyal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Wed Nov 25 17:37:07 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Wed, 25 Nov 2015 09:37:07 -0800 (PST) Subject: JDK9 Review Request for 8067660: JFileChooser create new folder fails silently In-Reply-To: <5655DAF4.50400@oracle.com> References: <5655DAF4.50400@oracle.com> Message-ID: <27d23000-c0bb-48a2-af87-b5297d7329ca@default> ? Hello Alexandr, ? Thanks for the review. I think other reason apart from access denied could be lack of space on device/drive. The API documentation for File.mkdirs is not very clear on reasons when the method will return false. Returns: true if and only if the directory was created, along with all necessary parent directories; false otherwise. Please let me know if your inputs on this. ? Regards, Rajeev Chamyal ? From: Alexandr Scherbatiy Sent: 25 November 2015 21:30 To: Rajeev Chamyal Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net Subject: Re: JDK9 Review Request for 8067660: JFileChooser create new folder fails silently ? 19.11.2015 13:09, Rajeev Chamyal ?????: Hello All, ? Please review the following fix for Jdk9: ? Bug: https://bugs.openjdk.java.net/browse/JDK-8067660 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8067660/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8067660/webrev.00/ Issue: jFileChooser create new folder fails silently on windows without any exception. Fix: Throwing an IOException from GenericFileSystemView:: createNewFolder, WindowsFileSystemView:: createNewFolder and UnixFileSystemView:: createNewFolder if mkdirs call returns false. ??? The exception message in the fix is: "Access denied".? Are there other reasons for which the File.mkdirs() can return false? ??? Thanks, ??? Alexandr. Regards, Rajeev Chamyal ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Thu Nov 26 08:36:31 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 26 Nov 2015 00:36:31 -0800 (PST) Subject: JDK9 Review Request for JDK-7104635 HTMLEditorKit fails to write down some html files Message-ID: Hello All, Please review the following fix for Jdk9: Bug: https://bugs.openjdk.java.net/browse/JDK-7104635 Webrev: http://cr.openjdk.java.net/~rchamyal/7104635/webrev.00/ Issue: If the minimized HTML has spaces the writing is failing with index out of bounds exception. Cause: The AbstractWriter::indent method is passing negative length of indentChars to writer. Fix: Added checks for negative value while decrementing the AbstractWriter::indentlevel. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Nov 26 10:47:59 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 26 Nov 2015 13:47:59 +0300 Subject: JDK9 Review Request for 8067660: JFileChooser create new folder fails silently In-Reply-To: <27d23000-c0bb-48a2-af87-b5297d7329ca@default> References: <5655DAF4.50400@oracle.com> <27d23000-c0bb-48a2-af87-b5297d7329ca@default> Message-ID: <5656E35E.2060409@oracle.com> On 11/25/2015 8:37 PM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. > > I think other reason apart from access denied could be lack of space > on device/drive. > > The API documentation for File.mkdirs is not very clear on reasons > when the method will return false. > > Returns: > > trueif and only if the directory was created, along with all necessary > parent directories; falseotherwise. > > Please let me know if your inputs on this. > In this case may be it is better to make the exception message more general to cover other failing reasons too? Thanks, Alexandr. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 25 November 2015 21:30 > *To:* Rajeev Chamyal > *Cc:* Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net > *Subject:* Re: JDK9 Review Request for 8067660: > JFileChooser create new folder fails silently > > > 19.11.2015 13:09, Rajeev Chamyal ?????: > > Hello All, > > Please review the following fix for Jdk9: > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8067660 > > Webrev:http://cr.openjdk.java.net/~rchamyal/8067660/webrev.00/ > > > Issue: jFileChooser create new folder fails silently on windows > without any exception. > > Fix: Throwing an IOException from > GenericFileSystemView::createNewFolder,WindowsFileSystemView::createNewFolder > andUnixFileSystemView::createNewFolder if mkdirs call returns false. > > > The exception message in the fix is: "Access denied". Are there > other reasons for which the File.mkdirs() can return false? > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > From rajeev.chamyal at oracle.com Fri Nov 27 10:45:12 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Fri, 27 Nov 2015 02:45:12 -0800 (PST) Subject: JDK9 Review Request for 8067660: JFileChooser create new folder fails silently In-Reply-To: <5656E35E.2060409@oracle.com> References: <5655DAF4.50400@oracle.com> <27d23000-c0bb-48a2-af87-b5297d7329ca@default> <5656E35E.2060409@oracle.com> Message-ID: <58e48b06-a3d4-469a-a224-1d50690a5bdc@default> Hello Alexandr, I have updated the webrev as per review comments. http://cr.openjdk.java.net/~rchamyal/8067660/webrev.01/ Attached image shows the error message. Regards, Rajeev Chamyal -----Original Message----- From: Alexander Scherbatiy Sent: 26 November 2015 16:18 To: Rajeev Chamyal Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net Subject: Re: JDK9 Review Request for 8067660: JFileChooser create new folder fails silently On 11/25/2015 8:37 PM, Rajeev Chamyal wrote: > > Hello Alexandr, > > Thanks for the review. > > I think other reason apart from access denied could be lack of space > on device/drive. > > The API documentation for File.mkdirs is not very clear on reasons > when the method will return false. > > Returns: > > trueif and only if the directory was created, along with all necessary > parent directories; falseotherwise. > > Please let me know if your inputs on this. > In this case may be it is better to make the exception message more general to cover other failing reasons too? Thanks, Alexandr. > > Regards, > > Rajeev Chamyal > > *From:*Alexandr Scherbatiy > *Sent:* 25 November 2015 21:30 > *To:* Rajeev Chamyal > *Cc:* Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net > *Subject:* Re: JDK9 Review Request for 8067660: > JFileChooser create new folder fails silently > > > 19.11.2015 13:09, Rajeev Chamyal ?????: > > Hello All, > > Please review the following fix for Jdk9: > > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8067660 > > Webrev:http://cr.openjdk.java.net/~rchamyal/8067660/webrev.00/ > > > Issue: jFileChooser create new folder fails silently on windows > without any exception. > > Fix: Throwing an IOException from > GenericFileSystemView::createNewFolder,WindowsFileSystemView::createNewFolder > andUnixFileSystemView::createNewFolder if mkdirs call returns false. > > > The exception message in the fix is: "Access denied". Are there > other reasons for which the File.mkdirs() can return false? > > Thanks, > Alexandr. > > Regards, > > Rajeev Chamyal > -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture.JPG Type: image/jpeg Size: 21585 bytes Desc: not available URL: From alexandr.scherbatiy at oracle.com Fri Nov 27 13:50:39 2015 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Fri, 27 Nov 2015 16:50:39 +0300 Subject: JDK9 Review Request for 8067660: JFileChooser create new folder fails silently In-Reply-To: <58e48b06-a3d4-469a-a224-1d50690a5bdc@default> References: <5655DAF4.50400@oracle.com> <27d23000-c0bb-48a2-af87-b5297d7329ca@default> <5656E35E.2060409@oracle.com> <58e48b06-a3d4-469a-a224-1d50690a5bdc@default> Message-ID: <56585FAF.6000706@oracle.com> 27.11.2015 13:45, Rajeev Chamyal ?????: > Hello Alexandr, > > I have updated the webrev as per review comments. > http://cr.openjdk.java.net/~rchamyal/8067660/webrev.01/ > > Attached image shows the error message. Thank you. I have only a comment about the test. It is defined only for Windows. Is it possible that the requested folder can't be created for example on Linux? Thanks, Alexandr. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexander Scherbatiy > Sent: 26 November 2015 16:18 > To: Rajeev Chamyal > Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: JDK9 Review Request for 8067660: JFileChooser create new folder fails silently > > On 11/25/2015 8:37 PM, Rajeev Chamyal wrote: >> Hello Alexandr, >> >> Thanks for the review. >> >> I think other reason apart from access denied could be lack of space >> on device/drive. >> >> The API documentation for File.mkdirs is not very clear on reasons >> when the method will return false. >> >> Returns: >> >> trueif and only if the directory was created, along with all necessary >> parent directories; falseotherwise. >> >> Please let me know if your inputs on this. >> > In this case may be it is better to make the exception message more general to cover other failing reasons too? > > Thanks, > Alexandr. >> Regards, >> >> Rajeev Chamyal >> >> *From:*Alexandr Scherbatiy >> *Sent:* 25 November 2015 21:30 >> *To:* Rajeev Chamyal >> *Cc:* Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net >> *Subject:* Re: JDK9 Review Request for 8067660: >> JFileChooser create new folder fails silently >> >> >> 19.11.2015 13:09, Rajeev Chamyal ?????: >> >> Hello All, >> >> Please review the following fix for Jdk9: >> >> >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8067660 >> >> Webrev:http://cr.openjdk.java.net/~rchamyal/8067660/webrev.00/ >> >> >> Issue: jFileChooser create new folder fails silently on windows >> without any exception. >> >> Fix: Throwing an IOException from >> GenericFileSystemView::createNewFolder,WindowsFileSystemView::createNewFolder >> andUnixFileSystemView::createNewFolder if mkdirs call returns false. >> >> >> The exception message in the fix is: "Access denied". Are there >> other reasons for which the File.mkdirs() can return false? >> >> Thanks, >> Alexandr. >> >> Regards, >> >> Rajeev Chamyal >> From rajeev.chamyal at oracle.com Mon Nov 30 07:02:58 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Sun, 29 Nov 2015 23:02:58 -0800 (PST) Subject: JDK9 Review Request for 8067660: JFileChooser create new folder fails silently In-Reply-To: <56585FAF.6000706@oracle.com> References: <5655DAF4.50400@oracle.com> <27d23000-c0bb-48a2-af87-b5297d7329ca@default> <5656E35E.2060409@oracle.com> <58e48b06-a3d4-469a-a224-1d50690a5bdc@default> <56585FAF.6000706@oracle.com> Message-ID: <89400bc2-7051-4a3f-9890-59697c23aeee@default> Hello Alexandr, This issue is reproducible only on windows. On Linux and MAC "Create new Folder" icon is disabled if user is not having write access to folder. On windows the File API File.canWrite always return true if file is a directory. As a result the create new folder icon is not disabled on windows. Regards, Rajeev Chamyal -----Original Message----- From: Alexandr Scherbatiy Sent: 27 November 2015 19:21 To: Rajeev Chamyal Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net Subject: Re: JDK9 Review Request for 8067660: JFileChooser create new folder fails silently 27.11.2015 13:45, Rajeev Chamyal ?????: > Hello Alexandr, > > I have updated the webrev as per review comments. > http://cr.openjdk.java.net/~rchamyal/8067660/webrev.01/ > > Attached image shows the error message. Thank you. I have only a comment about the test. It is defined only for Windows. Is it possible that the requested folder can't be created for example on Linux? Thanks, Alexandr. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexander Scherbatiy > Sent: 26 November 2015 16:18 > To: Rajeev Chamyal > Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: JDK9 Review Request for 8067660: JFileChooser > create new folder fails silently > > On 11/25/2015 8:37 PM, Rajeev Chamyal wrote: >> Hello Alexandr, >> >> Thanks for the review. >> >> I think other reason apart from access denied could be lack of space >> on device/drive. >> >> The API documentation for File.mkdirs is not very clear on reasons >> when the method will return false. >> >> Returns: >> >> trueif and only if the directory was created, along with all >> necessary parent directories; falseotherwise. >> >> Please let me know if your inputs on this. >> > In this case may be it is better to make the exception message more general to cover other failing reasons too? > > Thanks, > Alexandr. >> Regards, >> >> Rajeev Chamyal >> >> *From:*Alexandr Scherbatiy >> *Sent:* 25 November 2015 21:30 >> *To:* Rajeev Chamyal >> *Cc:* Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net >> *Subject:* Re: JDK9 Review Request for 8067660: >> JFileChooser create new folder fails silently >> >> >> 19.11.2015 13:09, Rajeev Chamyal ?????: >> >> Hello All, >> >> Please review the following fix for Jdk9: >> >> >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8067660 >> >> Webrev:http://cr.openjdk.java.net/~rchamyal/8067660/webrev.00/ >> >> >> Issue: jFileChooser create new folder fails silently on windows >> without any exception. >> >> Fix: Throwing an IOException from >> GenericFileSystemView::createNewFolder,WindowsFileSystemView::createNewFolder >> andUnixFileSystemView::createNewFolder if mkdirs call returns false. >> >> >> The exception message in the fix is: "Access denied". Are there >> other reasons for which the File.mkdirs() can return false? >> >> Thanks, >> Alexandr. >> >> Regards, >> >> Rajeev Chamyal >> From alexandr.scherbatiy at oracle.com Mon Nov 30 09:46:47 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 30 Nov 2015 13:46:47 +0400 Subject: JDK9 Review Request for 8067660: JFileChooser create new folder fails silently In-Reply-To: <89400bc2-7051-4a3f-9890-59697c23aeee@default> References: <5655DAF4.50400@oracle.com> <27d23000-c0bb-48a2-af87-b5297d7329ca@default> <5656E35E.2060409@oracle.com> <58e48b06-a3d4-469a-a224-1d50690a5bdc@default> <56585FAF.6000706@oracle.com> <89400bc2-7051-4a3f-9890-59697c23aeee@default> Message-ID: <565C1B07.8040705@oracle.com> The fix looks good to me. Thanks, Alexandr. On 30/11/15 11:02, Rajeev Chamyal wrote: > Hello Alexandr, > > This issue is reproducible only on windows. On Linux and MAC "Create new Folder" icon is disabled if user is not having write access to folder. > On windows the File API File.canWrite always return true if file is a directory. As a result the create new folder icon is not disabled on windows. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexandr Scherbatiy > Sent: 27 November 2015 19:21 > To: Rajeev Chamyal > Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: JDK9 Review Request for 8067660: JFileChooser create new folder fails silently > > 27.11.2015 13:45, Rajeev Chamyal ?????: >> Hello Alexandr, >> >> I have updated the webrev as per review comments. >> http://cr.openjdk.java.net/~rchamyal/8067660/webrev.01/ >> >> Attached image shows the error message. > Thank you. > > I have only a comment about the test. It is defined only for Windows. > Is it possible that the requested folder can't be created for example on Linux? > > Thanks, > Alexandr. > >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Alexander Scherbatiy >> Sent: 26 November 2015 16:18 >> To: Rajeev Chamyal >> Cc: Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net >> Subject: Re: JDK9 Review Request for 8067660: JFileChooser >> create new folder fails silently >> >> On 11/25/2015 8:37 PM, Rajeev Chamyal wrote: >>> Hello Alexandr, >>> >>> Thanks for the review. >>> >>> I think other reason apart from access denied could be lack of space >>> on device/drive. >>> >>> The API documentation for File.mkdirs is not very clear on reasons >>> when the method will return false. >>> >>> Returns: >>> >>> trueif and only if the directory was created, along with all >>> necessary parent directories; falseotherwise. >>> >>> Please let me know if your inputs on this. >>> >> In this case may be it is better to make the exception message more general to cover other failing reasons too? >> >> Thanks, >> Alexandr. >>> Regards, >>> >>> Rajeev Chamyal >>> >>> *From:*Alexandr Scherbatiy >>> *Sent:* 25 November 2015 21:30 >>> *To:* Rajeev Chamyal >>> *Cc:* Prasanta Sadhukhan; Sergey Bylokhov; swing-dev at openjdk.java.net >>> *Subject:* Re: JDK9 Review Request for 8067660: >>> JFileChooser create new folder fails silently >>> >>> >>> 19.11.2015 13:09, Rajeev Chamyal ?????: >>> >>> Hello All, >>> >>> Please review the following fix for Jdk9: >>> >>> >>> >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8067660 >>> >>> Webrev:http://cr.openjdk.java.net/~rchamyal/8067660/webrev.00/ >>> >>> >>> Issue: jFileChooser create new folder fails silently on windows >>> without any exception. >>> >>> Fix: Throwing an IOException from >>> GenericFileSystemView::createNewFolder,WindowsFileSystemView::createNewFolder >>> andUnixFileSystemView::createNewFolder if mkdirs call returns false. >>> >>> >>> The exception message in the fix is: "Access denied". Are there >>> other reasons for which the File.mkdirs() can return false? >>> >>> Thanks, >>> Alexandr. >>> >>> Regards, >>> >>> Rajeev Chamyal >>> From avik.niyogi at oracle.com Mon Nov 30 11:51:46 2015 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Mon, 30 Nov 2015 17:21:46 +0530 Subject: Review Request for 8139169: Action registered for keyboard shortcut is called twice Message-ID: <5C0CB2B4-1BDF-48C7-86E2-66597FE03C07@oracle.com> Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8139169 Webrev: http://cr.openjdk.java.net/~aniyogi/8139169/webrev.00/ Issue: Swing action with an accelerator like "meta shift COMMA?. It is put in the component's action map, when it is invoked, the action is called twice. Cause: Incorrect implementation within CMenuItem.m Fix:Added logic to sense all modifiers including ?shift? in CMenuItem which did not exist before. With Regards, Avik Niyogi -------------- next part -------------- An HTML attachment was scrubbed... URL: