From javalists at cbfiddle.com Sun Aug 2 14:29:36 2015 From: javalists at cbfiddle.com (Alan Snyder) Date: Sun, 2 Aug 2015 07:29:36 -0700 Subject: JTable layout problem Message-ID: <9B10F7CE-66F4-4104-8D89-A2DBB82C92AB@cbfiddle.com> I would like to raise awareness of bug JDK-5108458 (from 2004), similar to JDK-4514643 (from 2001). In a nutshell, the bug affects the layout of the table body when the table has RTL orientation and the columns do not fill the width of the table. JTableHeader correctly determines the locations of the columns in this case, but JTable does not. The fix should be simple but apparently the problem is viewed as too obscure to be worth fixing, or else it has just been forgotten. I encountered this bug when trying to create a table with alternating row background colors that fills a window or scroll pane. Just because the window can be made very wide does not mean that the columns should expand to arbitrarily large widths. An example of this kind of table is the iTunes browser view. The column widths are fixed, but the striped background fills the window no matter how wide it gets. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Aug 3 11:22:27 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 03 Aug 2015 14:22:27 +0300 Subject: Public API for internal Swing classes. In-Reply-To: <01A824C2-C046-4B29-B8E3-D98A6D980EE0@esko.com> References: <55B6244C.8040002@oracle.com> <01A824C2-C046-4B29-B8E3-D98A6D980EE0@esko.com> Message-ID: <55BF4EF3.9040900@oracle.com> Hello Koen, Are you using the isEnabled(Object sender) method just to separate a logic that checks that an action needs to be executed from the action execution in the same way as it it done in the UIAction? Could you file an enhancement on it and provide a simple use case: http://bugreport.java.com/bugreport Thanks, Alexandr. On 7/27/2015 4:13 PM, Van Den Borre, Koen wrote: > Hey, > > We are using sun.swing.UIAction in a custom ListUI where we override the following method and use the sender object: > > @Override > public boolean isEnabled(Object sender) > > Regards, > > Koen > > > On 27 Jul 2015, at 14:30, Alexander Scherbatiy wrote: > >> According to the JEP 200: The Modular JDK (see http://openjdk.java.net/jeps/200) >> we expect that the standard Java SE modules will not export any internal packages. >> >> It means that classes from internal packages (like sun.swing) will not be accessible. >> >> For example: >> sun.swing.FilePane >> sun.swing.SwingUtilities2 >> sun.swing.sun.swing.plaf.synth.SynthIcon >> and others. >> >> >> Please, let us known if you are using the internal Swing API and it is not possible to replace it by public API. >> >> There are some known requests: >> >> JDK-8132119 Provide public API for text related methods in SwingUtilities2 >> https://bugs.openjdk.java.net/browse/JDK-8132119 >> >> JDK-8132120 Provide public API for screen menu bar support on MacOS >> https://bugs.openjdk.java.net/browse/JDK-8132120 >> >> JDK-6274842 RFE: Provide a means for a custom look and feel to use desktop font antialiasing settings. >> https://bugs.openjdk.java.net/browse/JDK-6274842 >> >> >> If you don't know if you use these types (because you use 3rd party jars) >> you can use the JDK 8 "jdeps" tool to find such dependencies :- >> >> ~/jdk1.8/bin/jdeps >> Usage: jdeps >> where can be a pathname to a .class file, a directory, a JAR >> file, or a fully-qualified class name >> >> Thanks, >> Alexandr. >> From alexandr.scherbatiy at oracle.com Mon Aug 3 11:27:48 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 03 Aug 2015 14:27:48 +0300 Subject: [9] Review Request for 8132136: [PIT] RTL orientation in JEditorPane is broken In-Reply-To: <55BB77A3.50909@oracle.com> References: <55B1F094.1000700@oracle.com> <55B266B6.8040007@oracle.com> <55B9E497.9070204@oracle.com> <55BB77A3.50909@oracle.com> Message-ID: <55BF5034.1020707@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/31/2015 4:26 PM, Sergey Bylokhov wrote: > Looks fine, thanks. > > On 30.07.15 11:47, Semyon Sadetsky wrote: >> I have added test case. >> >> http://cr.openjdk.java.net/~ssadetsky/8132136/webrev.01/ >> >> --Semyon >> >> On 7/24/2015 7:24 PM, Sergey Bylokhov wrote: >>> The fix looks fine. But please provide the test case for it. The >>> test which found the bug compare screenshots between the base and >>> tested jdk. And the bug can be skipped in case of wrong base build >>> selection. I guess small test unit will better cover the issue. >>> >>> On 24.07.15 11:00, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Please review fix for JDK9: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132136 >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8132136/webrev.00/ >>>> >>>> A regression from JDK-8076164. GlyphView should be unrealizable by >>>> default not only for JTextFiled i18n view (as it was assumed in >>>> 8076164 fix). >>>> So the solution is to remove the specific BasicTextFieldUI and make >>>> GlyphView.getMinimumSize() returns non-resizeable value by default. >>>> >>>> --Semyon >>>> >>>> >>> >>> >> > > From alexandr.scherbatiy at oracle.com Mon Aug 3 12:02:32 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 03 Aug 2015 15:02:32 +0300 Subject: [9] Review Request for 8130892: Test javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java fails in Solaris Sparcv9 In-Reply-To: <55B63302.4030600@oracle.com> References: <55A91209.2000504@oracle.com> <55AF788F.9000805@oracle.com> <55AF7E55.70806@oracle.com> <55AF8F33.5030506@oracle.com> <55B08813.6060709@oracle.com> <55B0CAD1.3090207@oracle.com> <55B0E6F1.2080709@oracle.com> <55B2631E.7060807@oracle.com> <55B5D613.20805@oracle.com> <55B60A0B.8090308@oracle.com> <55B617B5.9010805@oracle.com> <55B61B7F.9060608@oracle.com> <55B63302.4030600@oracle.com> Message-ID: <55BF5858.9080703@oracle.com> The fix looks good to me. Thanks, Alexandr. On 7/27/2015 4:32 PM, Semyon Sadetsky wrote: > Alexander, > you can run the next test on Windows which sets the right frame size > and see that it fails because of the negative size. > > import javax.swing.*; > import javax.swing.border.EmptyBorder; > import java.awt.*; > > public class bug8001470 { > > private static JFrame frame; > private static JTextField textField1; > private static JTextField textField2; > > public static void main(String[] args) throws Exception { > SwingUtilities.invokeAndWait(new Runnable() { > @Override > public void run() { > frame = new JFrame("JTextField Test"); > frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > > JPanel container = (JPanel) frame.getContentPane(); > container.setLayout(new GridLayout(2,1)); > > textField1 = new JTextField("\u0e01"); > textField2 = new JTextField("\u0c01"); > JPanel panel = new JPanel(); > BorderLayout mgr = new BorderLayout(); > panel.setLayout(mgr); > container.add(panel); > panel.setBorder(new EmptyBorder(100, 100, 100, 100)); > panel.add(textField1); > panel.add(textField2); > frame.setVisible(true); > frame.pack(); > } > }); > if( textField1.getHeight() < 10 || textField2.getHeight() < 10 ) > throw new Exception("Wrong field height"); > System.out.println("ok"); > SwingUtilities.invokeLater(new Runnable() { > @Override > public void run() { > frame.dispose(); > } > }); > } > } > > --Semyon > > > On 7/27/2015 2:52 PM, Semyon Sadetsky wrote: >> -Alexander Yarmoliskiy >> +Alexander Zvegintsev >> >> On 7/27/2015 2:36 PM, Semyon Sadetsky wrote: >>> It is probably an issue, but even if fix it we cannot guarantee that >>> insets will be always less then the resulting frame size. Method >>> guessInsets() which obtains insets in frame's peer is hinting. >>> And again layout manager is able to apply negative size to container >>> regardless the frame size. >>> >>> --Semyon >>> >>> On 7/27/2015 1:38 PM, Alexander Scherbatiy wrote: >>>> >>>> I see that sun.awt.X11.WindowDimensions class takes insets into >>>> account and sets window size bigger than insets size. It looks like >>>> difference between windows size and insets should be positive in >>>> this case. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 7/27/2015 9:56 AM, Semyon Sadetsky wrote: >>>>> Your expectation is not correct because if insets are set for a >>>>> container then its child components can receive negative size even >>>>> if the parent size is positive. >>>>> >>>>> --Semyon >>>>> >>>>> On 7/24/2015 7:09 PM, Sergey Bylokhov wrote: >>>>>> On 23.07.15 16:06, Semyon Sadetsky wrote: >>>>>>> Peer validation doesn't make any sense until layout manager may >>>>>>> easily set negative size for any component using >>>>>>> Component.setBounds(). That happens this issue particularly. >>>>>> In your first request you mention that the problem occurs when >>>>>> "On Linux and Solaris platforms the initial frame window width >>>>>> and height can be negative". >>>>>> My expectation is that: if the window size if >=0 then none of >>>>>> the layout managers should set negative value for width/height, no? >>>>>> >>>>>>> So we need either to introduce the size constraint and fix the >>>>>>> general issue either make UI to be prepared to get negative size >>>>>>> occasionally i.e. fix the particular case (what is done in the >>>>>>> solution). >>>>>>> Which option are you suggesting? >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> On 7/23/2015 2:06 PM, Sergey Bylokhov wrote: >>>>>>>> On 23.07.15 9:22, Semyon Sadetsky wrote: >>>>>>>>> O.K. It sounds like a generic rule. Can I add this constant to >>>>>>>>> the Component.reshape()? >>>>>>>> Historically our components have a lack of any data validation >>>>>>>> because the user was able to call peers methods directly. I >>>>>>>> assume that such validation should exists already in the peers >>>>>>>> classes(like XBaseWindow.xSetBounds()). >>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> On 7/22/2015 3:40 PM, Sergey Bylokhov wrote: >>>>>>>>>> It seems that the bug is in fact that the size of the window >>>>>>>>>> is negative. In a lot of place we assume that it should be >=0. >>>>>>>>>> >>>>>>>>>> On 22.07.15 14:28, Semyon Sadetsky wrote: >>>>>>>>>>> In setVisible(true) if size is not specified and pack has >>>>>>>>>>> not been called yet frame get some initial size depending on >>>>>>>>>>> the platform. >>>>>>>>>>> That is the purpose of the test : to call pack() after >>>>>>>>>>> setVisible(). >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>> On 7/22/2015 2:03 PM, Alexander Scherbatiy wrote: >>>>>>>>>>>> On 7/17/2015 5:32 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8130892 >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8130892/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> On Linux and Solaris platforms the initial frame window >>>>>>>>>>>>> width and height can be negative. So the root view is >>>>>>>>>>>>> initialization trigger was updated to take negative values >>>>>>>>>>>>> into account. The fix was tested on Ubuntu 12, OEL7 and >>>>>>>>>>>>> Solaris 11. >>>>>>>>>>>> It looks strange that the test which does not set >>>>>>>>>>>> explicit bounds and calls frame.pack() encounters into >>>>>>>>>>>> negative sizes. >>>>>>>>>>>> In which place does the frame window obtain negative >>>>>>>>>>>> width and height? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Mon Aug 3 12:12:16 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 03 Aug 2015 15:12:16 +0300 Subject: [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager In-Reply-To: <55BB194C.50105@oracle.com> References: <55B7BAEB.5050501@oracle.com> <55BA17E3.7020701@oracle.com> <55BA1B7A.7010502@oracle.com> <55BA3448.2040801@oracle.com> <55BB194C.50105@oracle.com> Message-ID: <55BF5AA0.4060703@oracle.com> On 7/31/2015 9:44 AM, Semyon Sadetsky wrote: > Good question. But I did not add a concrete class. > The problem is that UndoManager provided by JDK wants to be serialized > but undoable objects knows nothing about that. The contract between > UndoManager and undoable is UndoableEditListener which only notifies > UndoManager to add a new edit. AbstractDocument does not care about > the specific UndoManager implementation and it can contain plenty > different UndoableEditListener. That is the current API approach. > If our specific UndoManager wants to be serialized it should also take > into account that the undoable it controls may require serialization. > For that it needs undoable's synchronization monitor and > AbstractDocument can provide it using writeLock()/writeUnlock() > methods. I assumed that in the first turn UndoManger should work well > with JDK undoables than to serve as a general implementation. Also I > tried to preserve the current API. > And your suggestion is to change the existing UndoableEditListener API > by introducing synchronization methods in it. Am I correctly > understand you? What I said is that UndoManager can be used not only by AbstractDocument but also in other classes which can have the same synchronization problems. There should be a way to solve these problems without storing links of external classes inside the UndoManager. 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 semyon.sadetsky at oracle.com Mon Aug 3 13:19:08 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 03 Aug 2015 16:19:08 +0300 Subject: [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager In-Reply-To: <55BF5AA0.4060703@oracle.com> References: <55B7BAEB.5050501@oracle.com> <55BA17E3.7020701@oracle.com> <55BA1B7A.7010502@oracle.com> <55BA3448.2040801@oracle.com> <55BB194C.50105@oracle.com> <55BF5AA0.4060703@oracle.com> Message-ID: <55BF6A4C.8080007@oracle.com> On 8/3/2015 3:12 PM, Alexander Scherbatiy wrote: > On 7/31/2015 9:44 AM, Semyon Sadetsky wrote: >> Good question. But I did not add a concrete class. >> The problem is that UndoManager provided by JDK wants to be >> serialized but undoable objects knows nothing about that. The >> contract between UndoManager and undoable is UndoableEditListener >> which only notifies UndoManager to add a new edit. AbstractDocument >> does not care about the specific UndoManager implementation and it >> can contain plenty different UndoableEditListener. That is the >> current API approach. >> If our specific UndoManager wants to be serialized it should also >> take into account that the undoable it controls may require >> serialization. For that it needs undoable's synchronization monitor >> and AbstractDocument can provide it using writeLock()/writeUnlock() >> methods. I assumed that in the first turn UndoManger should work well >> with JDK undoables than to serve as a general implementation. Also I >> tried to preserve the current API. >> And your suggestion is to change the existing UndoableEditListener >> API by introducing synchronization methods in it. Am I correctly >> understand you? > > What I said is that UndoManager can be used not only by > AbstractDocument but also in other classes which can have the same > synchronization problems. > There should be a way to solve these problems without storing links > of external classes inside the UndoManager. > As well as AbstractDocument can use another undo managers. It can be addressed to both parties. They need each others locks to serialize changes without deadlock. AbstarctDocument is related to UndoableEditListener as one to many that means a lock should be taken for each undo manager before the document change. Undo manager does not have any methods to get its lock because it is an UndoableEditListener implementation. AbstarctDocument has API to receive its lock. Do you still propose to fix the issue on AbstractDocument side? Could you clarify how do you see such fix? --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 Sergey.Bylokhov at oracle.com Mon Aug 3 13:23:09 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 3 Aug 2015 16:23:09 +0300 Subject: [9] Review Request for 8130892: Test javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java fails in Solaris Sparcv9 In-Reply-To: <55B63302.4030600@oracle.com> References: <55A91209.2000504@oracle.com> <55AF788F.9000805@oracle.com> <55AF7E55.70806@oracle.com> <55AF8F33.5030506@oracle.com> <55B08813.6060709@oracle.com> <55B0CAD1.3090207@oracle.com> <55B0E6F1.2080709@oracle.com> <55B2631E.7060807@oracle.com> <55B5D613.20805@oracle.com> <55B60A0B.8090308@oracle.com> <55B617B5.9010805@oracle.com> <55B61B7F.9060608@oracle.com> <55B63302.4030600@oracle.com> Message-ID: <55BF6B3D.6060202@oracle.com> On 27.07.15 16:32, Semyon Sadetsky wrote: > Alexander, > you can run the next test on Windows which sets the right frame size > and see that it fails because of the negative size. This test always fail on macosx even after the fix(the hight is zero), It fails even if I change the component to JButton. So does the actual problem in the BasicTextUI? Interesting is that in both cases the components are painted correctly, but the getHeight return incorrect value. > > import javax.swing.*; > import javax.swing.border.EmptyBorder; > import java.awt.*; > > public class bug8001470 { > > private static JFrame frame; > private static JTextField textField1; > private static JTextField textField2; > > public static void main(String[] args) throws Exception { > SwingUtilities.invokeAndWait(new Runnable() { > @Override > public void run() { > frame = new JFrame("JTextField Test"); > frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > > JPanel container = (JPanel) frame.getContentPane(); > container.setLayout(new GridLayout(2,1)); > > textField1 = new JTextField("\u0e01"); > textField2 = new JTextField("\u0c01"); > JPanel panel = new JPanel(); > BorderLayout mgr = new BorderLayout(); > panel.setLayout(mgr); > container.add(panel); > panel.setBorder(new EmptyBorder(100, 100, 100, 100)); > panel.add(textField1); > panel.add(textField2); > frame.setVisible(true); > frame.pack(); > } > }); > if( textField1.getHeight() < 10 || textField2.getHeight() < 10 ) > throw new Exception("Wrong field height"); > System.out.println("ok"); > SwingUtilities.invokeLater(new Runnable() { > @Override > public void run() { > frame.dispose(); > } > }); > } > } > > --Semyon > > > On 7/27/2015 2:52 PM, Semyon Sadetsky wrote: >> -Alexander Yarmoliskiy >> +Alexander Zvegintsev >> >> On 7/27/2015 2:36 PM, Semyon Sadetsky wrote: >>> It is probably an issue, but even if fix it we cannot guarantee that >>> insets will be always less then the resulting frame size. Method >>> guessInsets() which obtains insets in frame's peer is hinting. >>> And again layout manager is able to apply negative size to container >>> regardless the frame size. >>> >>> --Semyon >>> >>> On 7/27/2015 1:38 PM, Alexander Scherbatiy wrote: >>>> >>>> I see that sun.awt.X11.WindowDimensions class takes insets into >>>> account and sets window size bigger than insets size. It looks like >>>> difference between windows size and insets should be positive in >>>> this case. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 7/27/2015 9:56 AM, Semyon Sadetsky wrote: >>>>> Your expectation is not correct because if insets are set for a >>>>> container then its child components can receive negative size even >>>>> if the parent size is positive. >>>>> >>>>> --Semyon >>>>> >>>>> On 7/24/2015 7:09 PM, Sergey Bylokhov wrote: >>>>>> On 23.07.15 16:06, Semyon Sadetsky wrote: >>>>>>> Peer validation doesn't make any sense until layout manager may >>>>>>> easily set negative size for any component using >>>>>>> Component.setBounds(). That happens this issue particularly. >>>>>> In your first request you mention that the problem occurs when >>>>>> "On Linux and Solaris platforms the initial frame window width >>>>>> and height can be negative". >>>>>> My expectation is that: if the window size if >=0 then none of >>>>>> the layout managers should set negative value for width/height, no? >>>>>> >>>>>>> So we need either to introduce the size constraint and fix the >>>>>>> general issue either make UI to be prepared to get negative size >>>>>>> occasionally i.e. fix the particular case (what is done in the >>>>>>> solution). >>>>>>> Which option are you suggesting? >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> On 7/23/2015 2:06 PM, Sergey Bylokhov wrote: >>>>>>>> On 23.07.15 9:22, Semyon Sadetsky wrote: >>>>>>>>> O.K. It sounds like a generic rule. Can I add this constant to >>>>>>>>> the Component.reshape()? >>>>>>>> Historically our components have a lack of any data validation >>>>>>>> because the user was able to call peers methods directly. I >>>>>>>> assume that such validation should exists already in the peers >>>>>>>> classes(like XBaseWindow.xSetBounds()). >>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> On 7/22/2015 3:40 PM, Sergey Bylokhov wrote: >>>>>>>>>> It seems that the bug is in fact that the size of the window >>>>>>>>>> is negative. In a lot of place we assume that it should be >=0. >>>>>>>>>> >>>>>>>>>> On 22.07.15 14:28, Semyon Sadetsky wrote: >>>>>>>>>>> In setVisible(true) if size is not specified and pack has >>>>>>>>>>> not been called yet frame get some initial size depending on >>>>>>>>>>> the platform. >>>>>>>>>>> That is the purpose of the test : to call pack() after >>>>>>>>>>> setVisible(). >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>> On 7/22/2015 2:03 PM, Alexander Scherbatiy wrote: >>>>>>>>>>>> On 7/17/2015 5:32 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8130892 >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8130892/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> On Linux and Solaris platforms the initial frame window >>>>>>>>>>>>> width and height can be negative. So the root view is >>>>>>>>>>>>> initialization trigger was updated to take negative values >>>>>>>>>>>>> into account. The fix was tested on Ubuntu 12, OEL7 and >>>>>>>>>>>>> Solaris 11. >>>>>>>>>>>> It looks strange that the test which does not set >>>>>>>>>>>> explicit bounds and calls frame.pack() encounters into >>>>>>>>>>>> negative sizes. >>>>>>>>>>>> In which place does the frame window obtain negative >>>>>>>>>>>> width and height? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Mon Aug 3 13:58:27 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 03 Aug 2015 16:58:27 +0300 Subject: [9] Review Request for 8130892: Test javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java fails in Solaris Sparcv9 In-Reply-To: <55BF6B3D.6060202@oracle.com> References: <55A91209.2000504@oracle.com> <55AF788F.9000805@oracle.com> <55AF7E55.70806@oracle.com> <55AF8F33.5030506@oracle.com> <55B08813.6060709@oracle.com> <55B0CAD1.3090207@oracle.com> <55B0E6F1.2080709@oracle.com> <55B2631E.7060807@oracle.com> <55B5D613.20805@oracle.com> <55B60A0B.8090308@oracle.com> <55B617B5.9010805@oracle.com> <55B61B7F.9060608@oracle.com> <55B63302.4030600@oracle.com> <55BF6B3D.6060202@oracle.com> Message-ID: <55BF7383.8090108@oracle.com> The bug's test case passes OSX even without this fix. The test I sent here just for indication that negative size problem is more general and does not related to the specific XWindow frame peer. If you read this thread from beginning, in his review Alexander suggested to use very exact frame size for the initial frame layouting, but it cannot be predicted with 100% probability because it is set by WM. --Semyon On 8/3/2015 4:23 PM, Sergey Bylokhov wrote: > On 27.07.15 16:32, Semyon Sadetsky wrote: >> Alexander, >> you can run the next test on Windows which sets the right frame size >> and see that it fails because of the negative size. > This test always fail on macosx even after the fix(the hight is zero), > It fails even if I change the component to JButton. So does the actual > problem in the BasicTextUI? Interesting is that in both cases the > components are painted correctly, but the getHeight return incorrect > value. >> >> import javax.swing.*; >> import javax.swing.border.EmptyBorder; >> import java.awt.*; >> >> public class bug8001470 { >> >> private static JFrame frame; >> private static JTextField textField1; >> private static JTextField textField2; >> >> public static void main(String[] args) throws Exception { >> SwingUtilities.invokeAndWait(new Runnable() { >> @Override >> public void run() { >> frame = new JFrame("JTextField Test"); >> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> >> JPanel container = (JPanel) frame.getContentPane(); >> container.setLayout(new GridLayout(2,1)); >> >> textField1 = new JTextField("\u0e01"); >> textField2 = new JTextField("\u0c01"); >> JPanel panel = new JPanel(); >> BorderLayout mgr = new BorderLayout(); >> panel.setLayout(mgr); >> container.add(panel); >> panel.setBorder(new EmptyBorder(100, 100, 100, 100)); >> panel.add(textField1); >> panel.add(textField2); >> frame.setVisible(true); >> frame.pack(); >> } >> }); >> if( textField1.getHeight() < 10 || textField2.getHeight() < 10 ) >> throw new Exception("Wrong field height"); >> System.out.println("ok"); >> SwingUtilities.invokeLater(new Runnable() { >> @Override >> public void run() { >> frame.dispose(); >> } >> }); >> } >> } >> >> --Semyon >> >> >> On 7/27/2015 2:52 PM, Semyon Sadetsky wrote: >>> -Alexander Yarmoliskiy >>> +Alexander Zvegintsev >>> >>> On 7/27/2015 2:36 PM, Semyon Sadetsky wrote: >>>> It is probably an issue, but even if fix it we cannot guarantee >>>> that insets will be always less then the resulting frame size. >>>> Method guessInsets() which obtains insets in frame's peer is hinting. >>>> And again layout manager is able to apply negative size to >>>> container regardless the frame size. >>>> >>>> --Semyon >>>> >>>> On 7/27/2015 1:38 PM, Alexander Scherbatiy wrote: >>>>> >>>>> I see that sun.awt.X11.WindowDimensions class takes insets into >>>>> account and sets window size bigger than insets size. It looks >>>>> like difference between windows size and insets should be positive >>>>> in this case. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 7/27/2015 9:56 AM, Semyon Sadetsky wrote: >>>>>> Your expectation is not correct because if insets are set for a >>>>>> container then its child components can receive negative size >>>>>> even if the parent size is positive. >>>>>> >>>>>> --Semyon >>>>>> >>>>>> On 7/24/2015 7:09 PM, Sergey Bylokhov wrote: >>>>>>> On 23.07.15 16:06, Semyon Sadetsky wrote: >>>>>>>> Peer validation doesn't make any sense until layout manager may >>>>>>>> easily set negative size for any component using >>>>>>>> Component.setBounds(). That happens this issue particularly. >>>>>>> In your first request you mention that the problem occurs when >>>>>>> "On Linux and Solaris platforms the initial frame window width >>>>>>> and height can be negative". >>>>>>> My expectation is that: if the window size if >=0 then none of >>>>>>> the layout managers should set negative value for width/height, no? >>>>>>> >>>>>>>> So we need either to introduce the size constraint and fix the >>>>>>>> general issue either make UI to be prepared to get negative >>>>>>>> size occasionally i.e. fix the particular case (what is done in >>>>>>>> the solution). >>>>>>>> Which option are you suggesting? >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> On 7/23/2015 2:06 PM, Sergey Bylokhov wrote: >>>>>>>>> On 23.07.15 9:22, Semyon Sadetsky wrote: >>>>>>>>>> O.K. It sounds like a generic rule. Can I add this constant >>>>>>>>>> to the Component.reshape()? >>>>>>>>> Historically our components have a lack of any data validation >>>>>>>>> because the user was able to call peers methods directly. I >>>>>>>>> assume that such validation should exists already in the peers >>>>>>>>> classes(like XBaseWindow.xSetBounds()). >>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> On 7/22/2015 3:40 PM, Sergey Bylokhov wrote: >>>>>>>>>>> It seems that the bug is in fact that the size of the window >>>>>>>>>>> is negative. In a lot of place we assume that it should be >=0. >>>>>>>>>>> >>>>>>>>>>> On 22.07.15 14:28, Semyon Sadetsky wrote: >>>>>>>>>>>> In setVisible(true) if size is not specified and pack has >>>>>>>>>>>> not been called yet frame get some initial size depending >>>>>>>>>>>> on the platform. >>>>>>>>>>>> That is the purpose of the test : to call pack() after >>>>>>>>>>>> setVisible(). >>>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>>> On 7/22/2015 2:03 PM, Alexander Scherbatiy wrote: >>>>>>>>>>>>> On 7/17/2015 5:32 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>>> >>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8130892 >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8130892/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Linux and Solaris platforms the initial frame window >>>>>>>>>>>>>> width and height can be negative. So the root view is >>>>>>>>>>>>>> initialization trigger was updated to take negative >>>>>>>>>>>>>> values into account. The fix was tested on Ubuntu 12, >>>>>>>>>>>>>> OEL7 and Solaris 11. >>>>>>>>>>>>> It looks strange that the test which does not set >>>>>>>>>>>>> explicit bounds and calls frame.pack() encounters into >>>>>>>>>>>>> negative sizes. >>>>>>>>>>>>> In which place does the frame window obtain negative >>>>>>>>>>>>> width and height? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Aug 3 14:19:34 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 3 Aug 2015 17:19:34 +0300 Subject: [9] Review Request for 8130892: Test javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java fails in Solaris Sparcv9 In-Reply-To: <55BF7383.8090108@oracle.com> References: <55A91209.2000504@oracle.com> <55AF788F.9000805@oracle.com> <55AF7E55.70806@oracle.com> <55AF8F33.5030506@oracle.com> <55B08813.6060709@oracle.com> <55B0CAD1.3090207@oracle.com> <55B0E6F1.2080709@oracle.com> <55B2631E.7060807@oracle.com> <55B5D613.20805@oracle.com> <55B60A0B.8090308@oracle.com> <55B617B5.9010805@oracle.com> <55B61B7F.9060608@oracle.com> <55B63302.4030600@oracle.com> <55BF6B3D.6060202@oracle.com> <55BF7383.8090108@oracle.com> Message-ID: <55BF7876.1080400@oracle.com> Right, this is what I talk about, the problem is general and seems reproduced by your test on all platforms and components. More interesting is that it paints correctly but returns incorrect size(at lest on mac). On 03.08.15 16:58, Semyon Sadetsky wrote: > The bug's test case passes OSX even without this fix. > The test I sent here just for indication that negative size problem is > more general and does not related to the specific XWindow frame peer. > If you read this thread from beginning, in his review Alexander > suggested to use very exact frame size for the initial frame > layouting, but it cannot be predicted with 100% probability because it > is set by WM. > > --Semyon > > On 8/3/2015 4:23 PM, Sergey Bylokhov wrote: >> On 27.07.15 16:32, Semyon Sadetsky wrote: >>> Alexander, >>> you can run the next test on Windows which sets the right frame size >>> and see that it fails because of the negative size. >> This test always fail on macosx even after the fix(the hight is >> zero), It fails even if I change the component to JButton. So does >> the actual problem in the BasicTextUI? Interesting is that in both >> cases the components are painted correctly, but the getHeight return >> incorrect value. >>> >>> import javax.swing.*; >>> import javax.swing.border.EmptyBorder; >>> import java.awt.*; >>> >>> public class bug8001470 { >>> >>> private static JFrame frame; >>> private static JTextField textField1; >>> private static JTextField textField2; >>> >>> public static void main(String[] args) throws Exception { >>> SwingUtilities.invokeAndWait(new Runnable() { >>> @Override >>> public void run() { >>> frame = new JFrame("JTextField Test"); >>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>> >>> JPanel container = (JPanel) frame.getContentPane(); >>> container.setLayout(new GridLayout(2,1)); >>> >>> textField1 = new JTextField("\u0e01"); >>> textField2 = new JTextField("\u0c01"); >>> JPanel panel = new JPanel(); >>> BorderLayout mgr = new BorderLayout(); >>> panel.setLayout(mgr); >>> container.add(panel); >>> panel.setBorder(new EmptyBorder(100, 100, 100, 100)); >>> panel.add(textField1); >>> panel.add(textField2); >>> frame.setVisible(true); >>> frame.pack(); >>> } >>> }); >>> if( textField1.getHeight() < 10 || textField2.getHeight() < 10 ) >>> throw new Exception("Wrong field height"); >>> System.out.println("ok"); >>> SwingUtilities.invokeLater(new Runnable() { >>> @Override >>> public void run() { >>> frame.dispose(); >>> } >>> }); >>> } >>> } >>> >>> --Semyon >>> >>> >>> On 7/27/2015 2:52 PM, Semyon Sadetsky wrote: >>>> -Alexander Yarmoliskiy >>>> +Alexander Zvegintsev >>>> >>>> On 7/27/2015 2:36 PM, Semyon Sadetsky wrote: >>>>> It is probably an issue, but even if fix it we cannot guarantee >>>>> that insets will be always less then the resulting frame size. >>>>> Method guessInsets() which obtains insets in frame's peer is hinting. >>>>> And again layout manager is able to apply negative size to >>>>> container regardless the frame size. >>>>> >>>>> --Semyon >>>>> >>>>> On 7/27/2015 1:38 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> I see that sun.awt.X11.WindowDimensions class takes insets >>>>>> into account and sets window size bigger than insets size. It >>>>>> looks like difference between windows size and insets should be >>>>>> positive in this case. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> On 7/27/2015 9:56 AM, Semyon Sadetsky wrote: >>>>>>> Your expectation is not correct because if insets are set for a >>>>>>> container then its child components can receive negative size >>>>>>> even if the parent size is positive. >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> On 7/24/2015 7:09 PM, Sergey Bylokhov wrote: >>>>>>>> On 23.07.15 16:06, Semyon Sadetsky wrote: >>>>>>>>> Peer validation doesn't make any sense until layout manager >>>>>>>>> may easily set negative size for any component using >>>>>>>>> Component.setBounds(). That happens this issue particularly. >>>>>>>> In your first request you mention that the problem occurs when >>>>>>>> "On Linux and Solaris platforms the initial frame window width >>>>>>>> and height can be negative". >>>>>>>> My expectation is that: if the window size if >=0 then none of >>>>>>>> the layout managers should set negative value for width/height, >>>>>>>> no? >>>>>>>> >>>>>>>>> So we need either to introduce the size constraint and fix the >>>>>>>>> general issue either make UI to be prepared to get negative >>>>>>>>> size occasionally i.e. fix the particular case (what is done >>>>>>>>> in the solution). >>>>>>>>> Which option are you suggesting? >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> On 7/23/2015 2:06 PM, Sergey Bylokhov wrote: >>>>>>>>>> On 23.07.15 9:22, Semyon Sadetsky wrote: >>>>>>>>>>> O.K. It sounds like a generic rule. Can I add this constant >>>>>>>>>>> to the Component.reshape()? >>>>>>>>>> Historically our components have a lack of any data >>>>>>>>>> validation because the user was able to call peers methods >>>>>>>>>> directly. I assume that such validation should exists already >>>>>>>>>> in the peers classes(like XBaseWindow.xSetBounds()). >>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>> On 7/22/2015 3:40 PM, Sergey Bylokhov wrote: >>>>>>>>>>>> It seems that the bug is in fact that the size of the >>>>>>>>>>>> window is negative. In a lot of place we assume that it >>>>>>>>>>>> should be >=0. >>>>>>>>>>>> >>>>>>>>>>>> On 22.07.15 14:28, Semyon Sadetsky wrote: >>>>>>>>>>>>> In setVisible(true) if size is not specified and pack has >>>>>>>>>>>>> not been called yet frame get some initial size depending >>>>>>>>>>>>> on the platform. >>>>>>>>>>>>> That is the purpose of the test : to call pack() after >>>>>>>>>>>>> setVisible(). >>>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>>> >>>>>>>>>>>>> On 7/22/2015 2:03 PM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>> On 7/17/2015 5:32 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8130892 >>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8130892/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Linux and Solaris platforms the initial frame window >>>>>>>>>>>>>>> width and height can be negative. So the root view is >>>>>>>>>>>>>>> initialization trigger was updated to take negative >>>>>>>>>>>>>>> values into account. The fix was tested on Ubuntu 12, >>>>>>>>>>>>>>> OEL7 and Solaris 11. >>>>>>>>>>>>>> It looks strange that the test which does not set >>>>>>>>>>>>>> explicit bounds and calls frame.pack() encounters into >>>>>>>>>>>>>> negative sizes. >>>>>>>>>>>>>> In which place does the frame window obtain negative >>>>>>>>>>>>>> width and height? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Mon Aug 3 14:37:03 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 03 Aug 2015 17:37:03 +0300 Subject: [9] Review Request for 8130892: Test javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java fails in Solaris Sparcv9 In-Reply-To: <55BF7876.1080400@oracle.com> References: <55A91209.2000504@oracle.com> <55AF788F.9000805@oracle.com> <55AF7E55.70806@oracle.com> <55AF8F33.5030506@oracle.com> <55B08813.6060709@oracle.com> <55B0CAD1.3090207@oracle.com> <55B0E6F1.2080709@oracle.com> <55B2631E.7060807@oracle.com> <55B5D613.20805@oracle.com> <55B60A0B.8090308@oracle.com> <55B617B5.9010805@oracle.com> <55B61B7F.9060608@oracle.com> <55B63302.4030600@oracle.com> <55BF6B3D.6060202@oracle.com> <55BF7383.8090108@oracle.com> <55BF7876.1080400@oracle.com> Message-ID: <55BF7C8F.7010808@oracle.com> But we already told about that a dozen iterations ago. I would suggest to address the negative component size question to a newly created bug and this specific case can be fixed as proposed. --Semyon On 8/3/2015 5:19 PM, Sergey Bylokhov wrote: > Right, this is what I talk about, the problem is general and seems > reproduced by your test on all platforms and components. More > interesting is that it paints correctly but returns incorrect size(at > lest on mac). > > On 03.08.15 16:58, Semyon Sadetsky wrote: >> The bug's test case passes OSX even without this fix. >> The test I sent here just for indication that negative size problem >> is more general and does not related to the specific XWindow frame peer. >> If you read this thread from beginning, in his review Alexander >> suggested to use very exact frame size for the initial frame >> layouting, but it cannot be predicted with 100% probability because >> it is set by WM. >> >> --Semyon >> >> On 8/3/2015 4:23 PM, Sergey Bylokhov wrote: >>> On 27.07.15 16:32, Semyon Sadetsky wrote: >>>> Alexander, >>>> you can run the next test on Windows which sets the right frame >>>> size and see that it fails because of the negative size. >>> This test always fail on macosx even after the fix(the hight is >>> zero), It fails even if I change the component to JButton. So does >>> the actual problem in the BasicTextUI? Interesting is that in both >>> cases the components are painted correctly, but the getHeight return >>> incorrect value. >>>> >>>> import javax.swing.*; >>>> import javax.swing.border.EmptyBorder; >>>> import java.awt.*; >>>> >>>> public class bug8001470 { >>>> >>>> private static JFrame frame; >>>> private static JTextField textField1; >>>> private static JTextField textField2; >>>> >>>> public static void main(String[] args) throws Exception { >>>> SwingUtilities.invokeAndWait(new Runnable() { >>>> @Override >>>> public void run() { >>>> frame = new JFrame("JTextField Test"); >>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>> >>>> JPanel container = (JPanel) frame.getContentPane(); >>>> container.setLayout(new GridLayout(2,1)); >>>> >>>> textField1 = new JTextField("\u0e01"); >>>> textField2 = new JTextField("\u0c01"); >>>> JPanel panel = new JPanel(); >>>> BorderLayout mgr = new BorderLayout(); >>>> panel.setLayout(mgr); >>>> container.add(panel); >>>> panel.setBorder(new EmptyBorder(100, 100, 100, 100)); >>>> panel.add(textField1); >>>> panel.add(textField2); >>>> frame.setVisible(true); >>>> frame.pack(); >>>> } >>>> }); >>>> if( textField1.getHeight() < 10 || textField2.getHeight() < >>>> 10 ) >>>> throw new Exception("Wrong field height"); >>>> System.out.println("ok"); >>>> SwingUtilities.invokeLater(new Runnable() { >>>> @Override >>>> public void run() { >>>> frame.dispose(); >>>> } >>>> }); >>>> } >>>> } >>>> >>>> --Semyon >>>> >>>> >>>> On 7/27/2015 2:52 PM, Semyon Sadetsky wrote: >>>>> -Alexander Yarmoliskiy >>>>> +Alexander Zvegintsev >>>>> >>>>> On 7/27/2015 2:36 PM, Semyon Sadetsky wrote: >>>>>> It is probably an issue, but even if fix it we cannot guarantee >>>>>> that insets will be always less then the resulting frame size. >>>>>> Method guessInsets() which obtains insets in frame's peer is >>>>>> hinting. >>>>>> And again layout manager is able to apply negative size to >>>>>> container regardless the frame size. >>>>>> >>>>>> --Semyon >>>>>> >>>>>> On 7/27/2015 1:38 PM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> I see that sun.awt.X11.WindowDimensions class takes insets >>>>>>> into account and sets window size bigger than insets size. It >>>>>>> looks like difference between windows size and insets should be >>>>>>> positive in this case. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> On 7/27/2015 9:56 AM, Semyon Sadetsky wrote: >>>>>>>> Your expectation is not correct because if insets are set for a >>>>>>>> container then its child components can receive negative size >>>>>>>> even if the parent size is positive. >>>>>>>> >>>>>>>> --Semyon >>>>>>>> >>>>>>>> On 7/24/2015 7:09 PM, Sergey Bylokhov wrote: >>>>>>>>> On 23.07.15 16:06, Semyon Sadetsky wrote: >>>>>>>>>> Peer validation doesn't make any sense until layout manager >>>>>>>>>> may easily set negative size for any component using >>>>>>>>>> Component.setBounds(). That happens this issue particularly. >>>>>>>>> In your first request you mention that the problem occurs when >>>>>>>>> "On Linux and Solaris platforms the initial frame window width >>>>>>>>> and height can be negative". >>>>>>>>> My expectation is that: if the window size if >=0 then none of >>>>>>>>> the layout managers should set negative value for >>>>>>>>> width/height, no? >>>>>>>>> >>>>>>>>>> So we need either to introduce the size constraint and fix >>>>>>>>>> the general issue either make UI to be prepared to get >>>>>>>>>> negative size occasionally i.e. fix the particular case (what >>>>>>>>>> is done in the solution). >>>>>>>>>> Which option are you suggesting? >>>>>>>>>> >>>>>>>>>> --Semyon >>>>>>>>>> >>>>>>>>>> On 7/23/2015 2:06 PM, Sergey Bylokhov wrote: >>>>>>>>>>> On 23.07.15 9:22, Semyon Sadetsky wrote: >>>>>>>>>>>> O.K. It sounds like a generic rule. Can I add this constant >>>>>>>>>>>> to the Component.reshape()? >>>>>>>>>>> Historically our components have a lack of any data >>>>>>>>>>> validation because the user was able to call peers methods >>>>>>>>>>> directly. I assume that such validation should exists >>>>>>>>>>> already in the peers classes(like XBaseWindow.xSetBounds()). >>>>>>>>>>> >>>>>>>>>>>> --Semyon >>>>>>>>>>>> >>>>>>>>>>>> On 7/22/2015 3:40 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>> It seems that the bug is in fact that the size of the >>>>>>>>>>>>> window is negative. In a lot of place we assume that it >>>>>>>>>>>>> should be >=0. >>>>>>>>>>>>> >>>>>>>>>>>>> On 22.07.15 14:28, Semyon Sadetsky wrote: >>>>>>>>>>>>>> In setVisible(true) if size is not specified and pack has >>>>>>>>>>>>>> not been called yet frame get some initial size depending >>>>>>>>>>>>>> on the platform. >>>>>>>>>>>>>> That is the purpose of the test : to call pack() after >>>>>>>>>>>>>> setVisible(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 7/22/2015 2:03 PM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>> On 7/17/2015 5:32 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8130892 >>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8130892/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Linux and Solaris platforms the initial frame window >>>>>>>>>>>>>>>> width and height can be negative. So the root view is >>>>>>>>>>>>>>>> initialization trigger was updated to take negative >>>>>>>>>>>>>>>> values into account. The fix was tested on Ubuntu 12, >>>>>>>>>>>>>>>> OEL7 and Solaris 11. >>>>>>>>>>>>>>> It looks strange that the test which does not set >>>>>>>>>>>>>>> explicit bounds and calls frame.pack() encounters into >>>>>>>>>>>>>>> negative sizes. >>>>>>>>>>>>>>> In which place does the frame window obtain negative >>>>>>>>>>>>>>> width and height? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Aug 3 14:59:32 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 3 Aug 2015 17:59:32 +0300 Subject: [9] Review Request for 8130892: Test javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java fails in Solaris Sparcv9 In-Reply-To: <55BF7C8F.7010808@oracle.com> References: <55A91209.2000504@oracle.com> <55AF788F.9000805@oracle.com> <55AF7E55.70806@oracle.com> <55AF8F33.5030506@oracle.com> <55B08813.6060709@oracle.com> <55B0CAD1.3090207@oracle.com> <55B0E6F1.2080709@oracle.com> <55B2631E.7060807@oracle.com> <55B5D613.20805@oracle.com> <55B60A0B.8090308@oracle.com> <55B617B5.9010805@oracle.com> <55B61B7F.9060608@oracle.com> <55B63302.4030600@oracle.com> <55BF6B3D.6060202@oracle.com> <55BF7383.8090108@oracle.com> <55BF7876.1080400@oracle.com> <55BF7C8F.7010808@oracle.com> Message-ID: <55BF81D4.2010508@oracle.com> It seems I missed this suggestion, sorry. Then this fix looks fine. Please file a separate issues for x11 on why it can have negative size, and on the layout on why it does not work in some cases. On 03.08.15 17:37, Semyon Sadetsky wrote: > But we already told about that a dozen iterations ago. > I would suggest to address the negative component size question to a > newly created bug and this specific case can be fixed as proposed. > > --Semyon > > On 8/3/2015 5:19 PM, Sergey Bylokhov wrote: >> Right, this is what I talk about, the problem is general and seems >> reproduced by your test on all platforms and components. More >> interesting is that it paints correctly but returns incorrect size(at >> lest on mac). >> >> On 03.08.15 16:58, Semyon Sadetsky wrote: >>> The bug's test case passes OSX even without this fix. >>> The test I sent here just for indication that negative size problem >>> is more general and does not related to the specific XWindow frame >>> peer. >>> If you read this thread from beginning, in his review Alexander >>> suggested to use very exact frame size for the initial frame >>> layouting, but it cannot be predicted with 100% probability because >>> it is set by WM. >>> >>> --Semyon >>> >>> On 8/3/2015 4:23 PM, Sergey Bylokhov wrote: >>>> On 27.07.15 16:32, Semyon Sadetsky wrote: >>>>> Alexander, >>>>> you can run the next test on Windows which sets the right frame >>>>> size and see that it fails because of the negative size. >>>> This test always fail on macosx even after the fix(the hight is >>>> zero), It fails even if I change the component to JButton. So does >>>> the actual problem in the BasicTextUI? Interesting is that in both >>>> cases the components are painted correctly, but the getHeight >>>> return incorrect value. >>>>> >>>>> import javax.swing.*; >>>>> import javax.swing.border.EmptyBorder; >>>>> import java.awt.*; >>>>> >>>>> public class bug8001470 { >>>>> >>>>> private static JFrame frame; >>>>> private static JTextField textField1; >>>>> private static JTextField textField2; >>>>> >>>>> public static void main(String[] args) throws Exception { >>>>> SwingUtilities.invokeAndWait(new Runnable() { >>>>> @Override >>>>> public void run() { >>>>> frame = new JFrame("JTextField Test"); >>>>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>>>> >>>>> JPanel container = (JPanel) frame.getContentPane(); >>>>> container.setLayout(new GridLayout(2,1)); >>>>> >>>>> textField1 = new JTextField("\u0e01"); >>>>> textField2 = new JTextField("\u0c01"); >>>>> JPanel panel = new JPanel(); >>>>> BorderLayout mgr = new BorderLayout(); >>>>> panel.setLayout(mgr); >>>>> container.add(panel); >>>>> panel.setBorder(new EmptyBorder(100, 100, 100, 100)); >>>>> panel.add(textField1); >>>>> panel.add(textField2); >>>>> frame.setVisible(true); >>>>> frame.pack(); >>>>> } >>>>> }); >>>>> if( textField1.getHeight() < 10 || textField2.getHeight() >>>>> < 10 ) >>>>> throw new Exception("Wrong field height"); >>>>> System.out.println("ok"); >>>>> SwingUtilities.invokeLater(new Runnable() { >>>>> @Override >>>>> public void run() { >>>>> frame.dispose(); >>>>> } >>>>> }); >>>>> } >>>>> } >>>>> >>>>> --Semyon >>>>> >>>>> >>>>> On 7/27/2015 2:52 PM, Semyon Sadetsky wrote: >>>>>> -Alexander Yarmoliskiy >>>>>> +Alexander Zvegintsev >>>>>> >>>>>> On 7/27/2015 2:36 PM, Semyon Sadetsky wrote: >>>>>>> It is probably an issue, but even if fix it we cannot guarantee >>>>>>> that insets will be always less then the resulting frame size. >>>>>>> Method guessInsets() which obtains insets in frame's peer is >>>>>>> hinting. >>>>>>> And again layout manager is able to apply negative size to >>>>>>> container regardless the frame size. >>>>>>> >>>>>>> --Semyon >>>>>>> >>>>>>> On 7/27/2015 1:38 PM, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> I see that sun.awt.X11.WindowDimensions class takes insets >>>>>>>> into account and sets window size bigger than insets size. It >>>>>>>> looks like difference between windows size and insets should be >>>>>>>> positive in this case. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> On 7/27/2015 9:56 AM, Semyon Sadetsky wrote: >>>>>>>>> Your expectation is not correct because if insets are set for >>>>>>>>> a container then its child components can receive negative >>>>>>>>> size even if the parent size is positive. >>>>>>>>> >>>>>>>>> --Semyon >>>>>>>>> >>>>>>>>> On 7/24/2015 7:09 PM, Sergey Bylokhov wrote: >>>>>>>>>> On 23.07.15 16:06, Semyon Sadetsky wrote: >>>>>>>>>>> Peer validation doesn't make any sense until layout manager >>>>>>>>>>> may easily set negative size for any component using >>>>>>>>>>> Component.setBounds(). That happens this issue particularly. >>>>>>>>>> In your first request you mention that the problem occurs >>>>>>>>>> when "On Linux and Solaris platforms the initial frame window >>>>>>>>>> width and height can be negative". >>>>>>>>>> My expectation is that: if the window size if >=0 then none >>>>>>>>>> of the layout managers should set negative value for >>>>>>>>>> width/height, no? >>>>>>>>>> >>>>>>>>>>> So we need either to introduce the size constraint and fix >>>>>>>>>>> the general issue either make UI to be prepared to get >>>>>>>>>>> negative size occasionally i.e. fix the particular case >>>>>>>>>>> (what is done in the solution). >>>>>>>>>>> Which option are you suggesting? >>>>>>>>>>> >>>>>>>>>>> --Semyon >>>>>>>>>>> >>>>>>>>>>> On 7/23/2015 2:06 PM, Sergey Bylokhov wrote: >>>>>>>>>>>> On 23.07.15 9:22, Semyon Sadetsky wrote: >>>>>>>>>>>>> O.K. It sounds like a generic rule. Can I add this >>>>>>>>>>>>> constant to the Component.reshape()? >>>>>>>>>>>> Historically our components have a lack of any data >>>>>>>>>>>> validation because the user was able to call peers methods >>>>>>>>>>>> directly. I assume that such validation should exists >>>>>>>>>>>> already in the peers classes(like XBaseWindow.xSetBounds()). >>>>>>>>>>>> >>>>>>>>>>>>> --Semyon >>>>>>>>>>>>> >>>>>>>>>>>>> On 7/22/2015 3:40 PM, Sergey Bylokhov wrote: >>>>>>>>>>>>>> It seems that the bug is in fact that the size of the >>>>>>>>>>>>>> window is negative. In a lot of place we assume that it >>>>>>>>>>>>>> should be >=0. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 22.07.15 14:28, Semyon Sadetsky wrote: >>>>>>>>>>>>>>> In setVisible(true) if size is not specified and pack >>>>>>>>>>>>>>> has not been called yet frame get some initial size >>>>>>>>>>>>>>> depending on the platform. >>>>>>>>>>>>>>> That is the purpose of the test : to call pack() after >>>>>>>>>>>>>>> setVisible(). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 7/22/2015 2:03 PM, Alexander Scherbatiy wrote: >>>>>>>>>>>>>>>> On 7/17/2015 5:32 PM, Semyon Sadetsky wrote: >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please review fix for JDK9: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8130892 >>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8130892/webrev.00/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Linux and Solaris platforms the initial frame >>>>>>>>>>>>>>>>> window width and height can be negative. So the root >>>>>>>>>>>>>>>>> view is initialization trigger was updated to take >>>>>>>>>>>>>>>>> negative values into account. The fix was tested on >>>>>>>>>>>>>>>>> Ubuntu 12, OEL7 and Solaris 11. >>>>>>>>>>>>>>>> It looks strange that the test which does not set >>>>>>>>>>>>>>>> explicit bounds and calls frame.pack() encounters into >>>>>>>>>>>>>>>> negative sizes. >>>>>>>>>>>>>>>> In which place does the frame window obtain negative >>>>>>>>>>>>>>>> width and height? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Alexandr. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --Semyon >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, Sergey. >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From WLaan at costengineering.eu Tue Aug 4 07:50:51 2015 From: WLaan at costengineering.eu (Walter Laan) Date: Tue, 4 Aug 2015 07:50:51 +0000 Subject: Public API for internal Swing classes. In-Reply-To: <55BF4EF3.9040900@oracle.com> References: <55B6244C.8040002@oracle.com> <01A824C2-C046-4B29-B8E3-D98A6D980EE0@esko.com> <55BF4EF3.9040900@oracle.com> Message-ID: <59CA7531B79CD24C9220F8C952EF389E18E257AC@EXCH2010.ce.local> Below a use case where I had to cast to sun.swing.UIAction to correctly check if it is enabled or not. Let me know if I need to make the bug report or if you can add it as a comment to any existing issue. The issue with sun.swing.UIAction is as follows: It does not return the correct value from #isEnabled(), so you need to cast and call #isEnabled(Object) instead (check argument). This is because a single instance of UIAction is shared between all components with the same UI class, I assume originally for performance reasons. If you just want to perform the action when really enabled, you can use SwingUtilities#notifyAction(Action, KeyStroke, KeyEvent, Object, int) where the Object is the 'sender' (the action event source component) which is passed to UIAction#isEnabled(Object). It is technically possible to work around it with current public API, but that means not using any of the Swing UI classes at all and rewrite them without using UIAction. Solutions: 1) Fix UIAction by removing #isEnabled(Object) and have an instance per component Lots of work and large impact. Swing API users can remove references to UIAction and just call Action#isEnabled() 2) Make UIAction public API (move to javax.swing.plaf?) Simple refactor but lots of files changed Swing API users only need to update their imports 3) Do nothing and force Swing API to do point 1 themselves by re-implementing the components and UI classes using only public API Even more work than first solution but only for Swing API users Or they can access through reflection if that is not blocked by the module system? It will probably depend on the SecurityManager I guess. 4) Provide boolean SwingUtilities.canNotifyAction(Action, Object) which returns true if #notifyAction(Action, KeyStroke, KeyEvent, Object, int) would call action performed Minimal work and minimal impact Swing API users need to change code from ((sun.swing.UIAction) action).isEnabled(component) to SwingUtilities.canNotifyAction(component, action) 5) Something else? My preference would be solution 4 due to minimal impact - solution 2 also has not much impact but then you have public API which does not implement the Action interface correctly. Solution 1 would be the correct one but a lot of work. A simple test case: import java.awt.EventQueue; import javax.swing.Action; import javax.swing.JTable; import javax.swing.table.DefaultTableModel; public class TestUIAction { public static void main(String[] args) { EventQueue.invokeLater(new Runnable() { @Override public void run() { JTable table = new JTable(new DefaultTableModel(1, 1)); Action action = table.getActionMap().get("cancel"); System.out.println("JTable#isEditing() = " + table.isEditing()); System.out.println("Action#isEnabled() = " + action.isEnabled() + " but should be false!"); System.out.println("UIAction#isEnabled(Object) = " + ((sun.swing.UIAction) action).isEnabled(table)); table.editCellAt(0, 0); System.out.println("JTable#isEditing() = " + table.isEditing()); System.out.println("Action#isEnabled() = " + action.isEnabled()); System.out.println("UIAction#isEnabled(Object) = " + ((sun.swing.UIAction) action).isEnabled(table)); } }); } } Output: JTable#isEditing() = false Action#isEnabled() = true but should be false! UIAction#isEnabled(Object) = false JTable#isEditing() = true Action#isEnabled() = true UIAction#isEnabled(Object) = true Below a (quite long) scenario is which I had to use it: Using Jidesoft HierarchicalTable (see http://www.jidesoft.com/images/hierarchicaltable.png) which has (multiple) JTables as child components of a JTable. Their implementation has a work around to avoid keystrokes from being processed by the parent table if the focus is in a child component table. They do this by placing a JPanel between the parent and child table which registers a no-op action for each action in the JTable Input/ActionMap. For example: -top row is selected in the focused child table -users presses up arrow -child table up action is not enabled (since top row selection cannot move up) -key press goes up to the inserted panel and is consumed (action performed that does nothing) -parent table up arrow action does not get executed so its row selection is not changed As mentioned this is a workaround to avoid the parent component handling the key input, but a 'correct' solution would require re-writing BasicTableUI (and all the sub-classes for all the look and feels) for their HierarchicalTable instead of re-using the JTable UI. To improve the hack in the case of the escape key, which I want to use to close a JDialog the HierarchicalTable (skip the parent table actions instead of consuming it before gets there), I changed the no-op action to be only enabled if the original action is enabled in the parent table. For example: -child table is focused and not cell editing -user presses escape -child table 'cancel cell edit action' does not get notified because is not enabled -key press goes up the inserted panel but does not consume the action because the parent table 'cancel cell edit' action is also not enabled -parent table 'cancel cell edit action' does not get notified because is not enabled -eventually key press comes to the JDialog root pane and executes the close dialog action But since the 'cancel cell edit action' is an sun.swing.UIAction, to check if it is really enabled, I need to cast to the interal API and call #isEnabled(parentTable): /** * 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) { return ((sun.swing.UIAction) action).isEnabled(sender); } else { return action.isEnabled(); } } } Kind regards, Walter Laan Cost Engineering Consultancy -----Original Message----- From: swing-dev [mailto:swing-dev-bounces at openjdk.java.net] On Behalf Of Alexander Scherbatiy Sent: maandag 3 augustus 2015 13:22 To: Van Den Borre, Koen Cc: swing-dev at openjdk.java.net; macosx-port-dev at openjdk.java.net Subject: Re: Public API for internal Swing classes. Hello Koen, Are you using the isEnabled(Object sender) method just to separate a logic that checks that an action needs to be executed from the action execution in the same way as it it done in the UIAction? Could you file an enhancement on it and provide a simple use case: http://bugreport.java.com/bugreport Thanks, Alexandr. On 7/27/2015 4:13 PM, Van Den Borre, Koen wrote: > Hey, > > We are using sun.swing.UIAction in a custom ListUI where we override the following method and use the sender object: > > @Override > public boolean isEnabled(Object sender) > > Regards, > > Koen > > > On 27 Jul 2015, at 14:30, Alexander Scherbatiy wrote: > >> According to the JEP 200: The Modular JDK (see >> http://openjdk.java.net/jeps/200) we expect that the standard Java SE modules will not export any internal packages. >> >> It means that classes from internal packages (like sun.swing) will not be accessible. >> >> For example: >> sun.swing.FilePane >> sun.swing.SwingUtilities2 >> sun.swing.sun.swing.plaf.synth.SynthIcon >> and others. >> >> >> Please, let us known if you are using the internal Swing API and it is not possible to replace it by public API. >> >> There are some known requests: >> >> JDK-8132119 Provide public API for text related methods in SwingUtilities2 >> https://bugs.openjdk.java.net/browse/JDK-8132119 >> >> JDK-8132120 Provide public API for screen menu bar support on MacOS >> https://bugs.openjdk.java.net/browse/JDK-8132120 >> >> JDK-6274842 RFE: Provide a means for a custom look and feel to use desktop font antialiasing settings. >> https://bugs.openjdk.java.net/browse/JDK-6274842 >> >> >> If you don't know if you use these types (because you use 3rd party >> jars) you can use the JDK 8 "jdeps" tool to find such dependencies :- >> >> ~/jdk1.8/bin/jdeps >> Usage: jdeps >> where can be a pathname to a .class file, a directory, a >> JAR file, or a fully-qualified class name >> >> Thanks, >> Alexandr. >> From alexandr.scherbatiy at oracle.com Tue Aug 4 08:47:00 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 04 Aug 2015 11:47:00 +0300 Subject: [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager In-Reply-To: <55BF6A4C.8080007@oracle.com> References: <55B7BAEB.5050501@oracle.com> <55BA17E3.7020701@oracle.com> <55BA1B7A.7010502@oracle.com> <55BA3448.2040801@oracle.com> <55BB194C.50105@oracle.com> <55BF5AA0.4060703@oracle.com> <55BF6A4C.8080007@oracle.com> Message-ID: <55C07C04.6000301@oracle.com> On 8/3/2015 4:19 PM, Semyon Sadetsky wrote: > On 8/3/2015 3:12 PM, Alexander Scherbatiy wrote: >> On 7/31/2015 9:44 AM, Semyon Sadetsky wrote: >>> Good question. But I did not add a concrete class. >>> The problem is that UndoManager provided by JDK wants to be >>> serialized but undoable objects knows nothing about that. The >>> contract between UndoManager and undoable is UndoableEditListener >>> which only notifies UndoManager to add a new edit. AbstractDocument >>> does not care about the specific UndoManager implementation and it >>> can contain plenty different UndoableEditListener. That is the >>> current API approach. >>> If our specific UndoManager wants to be serialized it should also >>> take into account that the undoable it controls may require >>> serialization. For that it needs undoable's synchronization monitor >>> and AbstractDocument can provide it using writeLock()/writeUnlock() >>> methods. I assumed that in the first turn UndoManger should work >>> well with JDK undoables than to serve as a general implementation. >>> Also I tried to preserve the current API. >>> And your suggestion is to change the existing UndoableEditListener >>> API by introducing synchronization methods in it. Am I correctly >>> understand you? >> >> What I said is that UndoManager can be used not only by >> AbstractDocument but also in other classes which can have the same >> synchronization problems. >> There should be a way to solve these problems without storing >> links of external classes inside the UndoManager. >> > > As well as AbstractDocument can use another undo managers. It can be > addressed to both parties. They need each others locks to serialize > changes without deadlock. > AbstarctDocument is related to UndoableEditListener as one to many > that means a lock should be taken for each undo manager before the > document change. > Undo manager does not have any methods to get its lock because it is > an UndoableEditListener implementation. AbstarctDocument has API to > receive its lock. > Do you still propose to fix the issue on AbstractDocument side? Yes. > Could you clarify how do you see such fix? Put an UndoableEdit/UndoableEditEvent/necessary information to a queue instead of firing the undoable edit event under the write lock. Do not read the queue under the write lock. The queue allows to preserve the order of UndoableEdit's adding to an UndoManager. 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 semyon.sadetsky at oracle.com Tue Aug 4 09:32:29 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 04 Aug 2015 12:32:29 +0300 Subject: [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager In-Reply-To: <55C07C04.6000301@oracle.com> References: <55B7BAEB.5050501@oracle.com> <55BA17E3.7020701@oracle.com> <55BA1B7A.7010502@oracle.com> <55BA3448.2040801@oracle.com> <55BB194C.50105@oracle.com> <55BF5AA0.4060703@oracle.com> <55BF6A4C.8080007@oracle.com> <55C07C04.6000301@oracle.com> Message-ID: <55C086AD.2070709@oracle.com> On 8/4/2015 11:47 AM, Alexander Scherbatiy wrote: > On 8/3/2015 4:19 PM, Semyon Sadetsky wrote: >> On 8/3/2015 3:12 PM, Alexander Scherbatiy wrote: >>> On 7/31/2015 9:44 AM, Semyon Sadetsky wrote: >>>> Good question. But I did not add a concrete class. >>>> The problem is that UndoManager provided by JDK wants to be >>>> serialized but undoable objects knows nothing about that. The >>>> contract between UndoManager and undoable is UndoableEditListener >>>> which only notifies UndoManager to add a new edit. AbstractDocument >>>> does not care about the specific UndoManager implementation and it >>>> can contain plenty different UndoableEditListener. That is the >>>> current API approach. >>>> If our specific UndoManager wants to be serialized it should also >>>> take into account that the undoable it controls may require >>>> serialization. For that it needs undoable's synchronization monitor >>>> and AbstractDocument can provide it using writeLock()/writeUnlock() >>>> methods. I assumed that in the first turn UndoManger should work >>>> well with JDK undoables than to serve as a general implementation. >>>> Also I tried to preserve the current API. >>>> And your suggestion is to change the existing UndoableEditListener >>>> API by introducing synchronization methods in it. Am I correctly >>>> understand you? >>> >>> What I said is that UndoManager can be used not only by >>> AbstractDocument but also in other classes which can have the same >>> synchronization problems. >>> There should be a way to solve these problems without storing >>> links of external classes inside the UndoManager. >>> >> >> As well as AbstractDocument can use another undo managers. It can be >> addressed to both parties. They need each others locks to serialize >> changes without deadlock. >> AbstarctDocument is related to UndoableEditListener as one to many >> that means a lock should be taken for each undo manager before the >> document change. >> Undo manager does not have any methods to get its lock because it is >> an UndoableEditListener implementation. AbstarctDocument has API to >> receive its lock. >> Do you still propose to fix the issue on AbstractDocument side? > Yes. >> Could you clarify how do you see such fix? > > Put an UndoableEdit/UndoableEditEvent/necessary information to a > queue instead of firing the undoable edit event under the write lock. > Do not read the queue under the write lock. The queue allows to > preserve the order of UndoableEdit's adding to an UndoManager. > Is not it the same as the previous attempt to fix this issue (see 8030118 )? Document change event need to be fired under write lock because the change to the document should be atomic. Queue of changes is undo manager's responsibility not the document. And such queue in the AbstractDocument would require complex coordination with all its undo managers queues. What if undo called on undo manager during the doc's queue processing? The right undo/redo requests and edit events order need to be preserved in this case and it would be too complex or we would have to change the concept and make AbstractDocument to maintain its undo/redo history internally instead of external undo managers. 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. 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. > 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 Aug 4 10:29:36 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 04 Aug 2015 13:29:36 +0300 Subject: Public API for internal Swing classes. In-Reply-To: <59CA7531B79CD24C9220F8C952EF389E18E257AC@EXCH2010.ce.local> References: <55B6244C.8040002@oracle.com> <01A824C2-C046-4B29-B8E3-D98A6D980EE0@esko.com> <55BF4EF3.9040900@oracle.com> <59CA7531B79CD24C9220F8C952EF389E18E257AC@EXCH2010.ce.local> Message-ID: <55C09410.5010700@oracle.com> On 8/4/2015 10:50 AM, Walter Laan wrote: > Below a use case where I had to cast to sun.swing.UIAction to correctly check if it is enabled or not. > Let me know if I need to make the bug report or if you can add it as a comment to any existing issue. Thank you for the report. Yes, please, file an enhancement on it. Thanks, Alexandr. > > The issue with sun.swing.UIAction is as follows: > > It does not return the correct value from #isEnabled(), so you need to cast and call #isEnabled(Object) instead (check argument). This is because a single instance of UIAction is shared between all components with the same UI class, I assume originally for performance reasons. > If you just want to perform the action when really enabled, you can use SwingUtilities#notifyAction(Action, KeyStroke, KeyEvent, Object, int) where the Object is the 'sender' (the action event source component) which is passed to UIAction#isEnabled(Object). > It is technically possible to work around it with current public API, but that means not using any of the Swing UI classes at all and rewrite them without using UIAction. > > Solutions: > 1) Fix UIAction by removing #isEnabled(Object) and have an instance per component > Lots of work and large impact. > Swing API users can remove references to UIAction and just call Action#isEnabled() > > 2) Make UIAction public API (move to javax.swing.plaf?) > Simple refactor but lots of files changed > Swing API users only need to update their imports > > 3) Do nothing and force Swing API to do point 1 themselves by re-implementing the components and UI classes using only public API > Even more work than first solution but only for Swing API users > Or they can access through reflection if that is not blocked by the module system? It will probably depend on the SecurityManager I guess. > > 4) Provide boolean SwingUtilities.canNotifyAction(Action, Object) which returns true if #notifyAction(Action, KeyStroke, KeyEvent, Object, int) would call action performed > Minimal work and minimal impact > Swing API users need to change code from ((sun.swing.UIAction) action).isEnabled(component) to SwingUtilities.canNotifyAction(component, action) > > 5) Something else? > > My preference would be solution 4 due to minimal impact - solution 2 also has not much impact but then you have public API which does not implement the Action interface correctly. Solution 1 would be the correct one but a lot of work. > > A simple test case: > > import java.awt.EventQueue; > > import javax.swing.Action; > import javax.swing.JTable; > import javax.swing.table.DefaultTableModel; > > public class TestUIAction { > > public static void main(String[] args) { > EventQueue.invokeLater(new Runnable() { > > @Override > public void run() { > JTable table = new JTable(new DefaultTableModel(1, 1)); > > Action action = table.getActionMap().get("cancel"); > System.out.println("JTable#isEditing() = " + table.isEditing()); > System.out.println("Action#isEnabled() = " + action.isEnabled() + " but should be false!"); System.out.println("UIAction#isEnabled(Object) = " + ((sun.swing.UIAction) action).isEnabled(table)); > > table.editCellAt(0, 0); > > System.out.println("JTable#isEditing() = " + table.isEditing()); > System.out.println("Action#isEnabled() = " + action.isEnabled()); System.out.println("UIAction#isEnabled(Object) = " + ((sun.swing.UIAction) action).isEnabled(table)); > } > }); > } > } > > Output: > JTable#isEditing() = false > Action#isEnabled() = true but should be false! > UIAction#isEnabled(Object) = false > > JTable#isEditing() = true > Action#isEnabled() = true > UIAction#isEnabled(Object) = true > > > Below a (quite long) scenario is which I had to use it: > > Using Jidesoft HierarchicalTable (see http://www.jidesoft.com/images/hierarchicaltable.png) which has (multiple) JTables as child components of a JTable. Their implementation has a work around to avoid keystrokes from being processed by the parent table if the focus is in a child component table. They do this by placing a JPanel between the parent and child table which registers a no-op action for each action in the JTable Input/ActionMap. > > For example: > -top row is selected in the focused child table > -users presses up arrow > -child table up action is not enabled (since top row selection cannot move up) > -key press goes up to the inserted panel and is consumed (action performed that does nothing) > -parent table up arrow action does not get executed so its row selection is not changed > > As mentioned this is a workaround to avoid the parent component handling the key input, but a 'correct' solution would require re-writing BasicTableUI (and all the sub-classes for all the look and feels) for their HierarchicalTable instead of re-using the JTable UI. > To improve the hack in the case of the escape key, which I want to use to close a JDialog the HierarchicalTable (skip the parent table actions instead of consuming it before gets there), I changed the no-op action to be only enabled if the original action is enabled in the parent table. > > For example: > -child table is focused and not cell editing > -user presses escape > -child table 'cancel cell edit action' does not get notified because is not enabled > -key press goes up the inserted panel but does not consume the action because the parent table 'cancel cell edit' action is also not enabled > -parent table 'cancel cell edit action' does not get notified because is not enabled > -eventually key press comes to the JDialog root pane and executes the close dialog action > > But since the 'cancel cell edit action' is an sun.swing.UIAction, to check if it is really enabled, I need to cast to the interal API and call #isEnabled(parentTable): > > /** > * 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) { > return ((sun.swing.UIAction) action).isEnabled(sender); > } > else { > return action.isEnabled(); > } > } > } > > > Kind regards, > Walter Laan > Cost Engineering Consultancy > > -----Original Message----- > From: swing-dev [mailto:swing-dev-bounces at openjdk.java.net] On Behalf Of Alexander Scherbatiy > Sent: maandag 3 augustus 2015 13:22 > To: Van Den Borre, Koen > Cc: swing-dev at openjdk.java.net; macosx-port-dev at openjdk.java.net > Subject: Re: Public API for internal Swing classes. > > > > Hello Koen, > > Are you using the isEnabled(Object sender) method just to separate a logic that checks that an action needs to be executed from the action execution in the same way as it it done in the UIAction? > > Could you file an enhancement on it and provide a simple use case: > http://bugreport.java.com/bugreport > > Thanks, > Alexandr. > > > On 7/27/2015 4:13 PM, Van Den Borre, Koen wrote: >> Hey, >> >> We are using sun.swing.UIAction in a custom ListUI where we override the following method and use the sender object: >> >> @Override >> public boolean isEnabled(Object sender) >> >> Regards, >> >> Koen >> >> >> On 27 Jul 2015, at 14:30, Alexander Scherbatiy wrote: >> >>> According to the JEP 200: The Modular JDK (see >>> http://openjdk.java.net/jeps/200) we expect that the standard Java SE modules will not export any internal packages. >>> >>> It means that classes from internal packages (like sun.swing) will not be accessible. >>> >>> For example: >>> sun.swing.FilePane >>> sun.swing.SwingUtilities2 >>> sun.swing.sun.swing.plaf.synth.SynthIcon >>> and others. >>> >>> >>> Please, let us known if you are using the internal Swing API and it is not possible to replace it by public API. >>> >>> There are some known requests: >>> >>> JDK-8132119 Provide public API for text related methods in SwingUtilities2 >>> https://bugs.openjdk.java.net/browse/JDK-8132119 >>> >>> JDK-8132120 Provide public API for screen menu bar support on MacOS >>> https://bugs.openjdk.java.net/browse/JDK-8132120 >>> >>> JDK-6274842 RFE: Provide a means for a custom look and feel to use desktop font antialiasing settings. >>> https://bugs.openjdk.java.net/browse/JDK-6274842 >>> >>> >>> If you don't know if you use these types (because you use 3rd party >>> jars) you can use the JDK 8 "jdeps" tool to find such dependencies :- >>> >>> ~/jdk1.8/bin/jdeps >>> Usage: jdeps >>> where can be a pathname to a .class file, a directory, a >>> JAR file, or a fully-qualified class name >>> >>> Thanks, >>> Alexandr. >>> From alexandr.scherbatiy at oracle.com Tue Aug 4 11:03:50 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 04 Aug 2015 14:03:50 +0300 Subject: [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager In-Reply-To: <55C086AD.2070709@oracle.com> References: <55B7BAEB.5050501@oracle.com> <55BA17E3.7020701@oracle.com> <55BA1B7A.7010502@oracle.com> <55BA3448.2040801@oracle.com> <55BB194C.50105@oracle.com> <55BF5AA0.4060703@oracle.com> <55BF6A4C.8080007@oracle.com> <55C07C04.6000301@oracle.com> <55C086AD.2070709@oracle.com> Message-ID: <55C09C16.1040907@oracle.com> On 8/4/2015 12:32 PM, Semyon Sadetsky wrote: > > > On 8/4/2015 11:47 AM, Alexander Scherbatiy wrote: >> On 8/3/2015 4:19 PM, Semyon Sadetsky wrote: >>> On 8/3/2015 3:12 PM, Alexander Scherbatiy wrote: >>>> On 7/31/2015 9:44 AM, Semyon Sadetsky wrote: >>>>> Good question. But I did not add a concrete class. >>>>> The problem is that UndoManager provided by JDK wants to be >>>>> serialized but undoable objects knows nothing about that. The >>>>> contract between UndoManager and undoable is UndoableEditListener >>>>> which only notifies UndoManager to add a new edit. >>>>> AbstractDocument does not care about the specific UndoManager >>>>> implementation and it can contain plenty different >>>>> UndoableEditListener. That is the current API approach. >>>>> If our specific UndoManager wants to be serialized it should also >>>>> take into account that the undoable it controls may require >>>>> serialization. For that it needs undoable's synchronization >>>>> monitor and AbstractDocument can provide it using >>>>> writeLock()/writeUnlock() methods. I assumed that in the first >>>>> turn UndoManger should work well with JDK undoables than to serve >>>>> as a general implementation. Also I tried to preserve the current >>>>> API. >>>>> And your suggestion is to change the existing UndoableEditListener >>>>> API by introducing synchronization methods in it. Am I correctly >>>>> understand you? >>>> >>>> What I said is that UndoManager can be used not only by >>>> AbstractDocument but also in other classes which can have the same >>>> synchronization problems. >>>> There should be a way to solve these problems without storing >>>> links of external classes inside the UndoManager. >>>> >>> >>> As well as AbstractDocument can use another undo managers. It can be >>> addressed to both parties. They need each others locks to serialize >>> changes without deadlock. >>> AbstarctDocument is related to UndoableEditListener as one to many >>> that means a lock should be taken for each undo manager before the >>> document change. >>> Undo manager does not have any methods to get its lock because it is >>> an UndoableEditListener implementation. AbstarctDocument has API to >>> receive its lock. >>> Do you still propose to fix the issue on AbstractDocument side? >> Yes. >>> Could you clarify how do you see such fix? >> >> Put an UndoableEdit/UndoableEditEvent/necessary information to a >> queue instead of firing the undoable edit event under the write lock. >> Do not read the queue under the write lock. The queue allows to >> preserve the order of UndoableEdit's adding to an UndoManager. >> > Is not it the same as the previous attempt to fix this issue (see > 8030118 )? 8030118 fix does a strange thing like firing InsertUpdate document event out of the lock. Do not do that. > Document change event need to be fired under write lock because the > change to the document should be atomic. Queue of changes is undo > manager's responsibility not the document. > And such queue in the AbstractDocument would require complex > coordination with all its undo managers queues. What if undo called on > undo manager during the doc's queue processing? The right undo/redo > requests and edit events order need to be preserved in this case and > it would be too complex or we would have to change the concept and > make AbstractDocument to maintain its undo/redo history internally > instead of external undo managers. It only needs to pass undoable edits in the right order from abstract document to the UndoManager. > 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. > 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. 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 semyon.sadetsky at oracle.com Tue Aug 4 12:13:57 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 04 Aug 2015 15:13:57 +0300 Subject: [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager In-Reply-To: <55C09C16.1040907@oracle.com> References: <55B7BAEB.5050501@oracle.com> <55BA17E3.7020701@oracle.com> <55BA1B7A.7010502@oracle.com> <55BA3448.2040801@oracle.com> <55BB194C.50105@oracle.com> <55BF5AA0.4060703@oracle.com> <55BF6A4C.8080007@oracle.com> <55C07C04.6000301@oracle.com> <55C086AD.2070709@oracle.com> <55C09C16.1040907@oracle.com> Message-ID: <55C0AC85.4010402@oracle.com> On 8/4/2015 2:03 PM, Alexander Scherbatiy wrote: > On 8/4/2015 12:32 PM, Semyon Sadetsky wrote: >> >> >> On 8/4/2015 11:47 AM, Alexander Scherbatiy wrote: >>> On 8/3/2015 4:19 PM, Semyon Sadetsky wrote: >>>> On 8/3/2015 3:12 PM, Alexander Scherbatiy wrote: >>>>> On 7/31/2015 9:44 AM, Semyon Sadetsky wrote: >>>>>> Good question. But I did not add a concrete class. >>>>>> The problem is that UndoManager provided by JDK wants to be >>>>>> serialized but undoable objects knows nothing about that. The >>>>>> contract between UndoManager and undoable is UndoableEditListener >>>>>> which only notifies UndoManager to add a new edit. >>>>>> AbstractDocument does not care about the specific UndoManager >>>>>> implementation and it can contain plenty different >>>>>> UndoableEditListener. That is the current API approach. >>>>>> If our specific UndoManager wants to be serialized it should also >>>>>> take into account that the undoable it controls may require >>>>>> serialization. For that it needs undoable's synchronization >>>>>> monitor and AbstractDocument can provide it using >>>>>> writeLock()/writeUnlock() methods. I assumed that in the first >>>>>> turn UndoManger should work well with JDK undoables than to serve >>>>>> as a general implementation. Also I tried to preserve the >>>>>> current API. >>>>>> And your suggestion is to change the existing >>>>>> UndoableEditListener API by introducing synchronization methods >>>>>> in it. Am I correctly understand you? >>>>> >>>>> What I said is that UndoManager can be used not only by >>>>> AbstractDocument but also in other classes which can have the same >>>>> synchronization problems. >>>>> There should be a way to solve these problems without storing >>>>> links of external classes inside the UndoManager. >>>>> >>>> >>>> As well as AbstractDocument can use another undo managers. It can >>>> be addressed to both parties. They need each others locks to >>>> serialize changes without deadlock. >>>> AbstarctDocument is related to UndoableEditListener as one to many >>>> that means a lock should be taken for each undo manager before the >>>> document change. >>>> Undo manager does not have any methods to get its lock because it >>>> is an UndoableEditListener implementation. AbstarctDocument has API >>>> to receive its lock. >>>> Do you still propose to fix the issue on AbstractDocument side? >>> Yes. >>>> Could you clarify how do you see such fix? >>> >>> Put an UndoableEdit/UndoableEditEvent/necessary information to a >>> queue instead of firing the undoable edit event under the write >>> lock. Do not read the queue under the write lock. The queue allows >>> to preserve the order of UndoableEdit's adding to an UndoManager. >>> >> Is not it the same as the previous attempt to fix this issue (see >> 8030118 )? > 8030118 fix does a strange thing like firing InsertUpdate > document event out of the lock. Do not do that. >> Document change event need to be fired under write lock because the >> change to the document should be atomic. Queue of changes is undo >> manager's responsibility not the document. >> And such queue in the AbstractDocument would require complex >> coordination with all its undo managers queues. What if undo called >> on undo manager during the doc's queue processing? The right >> undo/redo requests and edit events order need to be preserved in this >> case and it would be too complex or we would have to change the >> concept and make AbstractDocument to maintain its undo/redo history >> internally instead of external undo managers. > It only needs to pass undoable edits in the right order from > abstract document to the UndoManager. Consider the scenario: UndoManager executes undo/redo before it receives the undoable edits. As result it will undo not the last edit but intermediate and it will crash because the document state is changed and intermediate the undoable edit cannot be applied to the final document state. > >> 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? >> 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. > 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 nadeesh.tv at oracle.com Tue Aug 4 12:21:29 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 04 Aug 2015 17:51:29 +0530 Subject: [Reminder] Re: [RFR: JDK-8028618 ] [TEST BUG] javax/swing/JScrollBar/bug4202954/bug4202954.java fails In-Reply-To: <55AF4B20.4000208@oracle.com> References: <55AF4B20.4000208@oracle.com> Message-ID: <55C0AE49.1000201@oracle.com> -------- Original Message -------- Subject: Re: [RFR: JDK-8028618 ] [TEST BUG] javax/swing/JScrollBar/bug4202954/bug4202954.java fails Date: Wed, 22 Jul 2015 10:49:52 +0300 From: Alexander Scherbatiy To: nadeesh tv CC: swing-dev at openjdk.java.net The fix looks good to me. Thanks, Alexandr. On 7/16/2015 10:00 AM, nadeesh tv wrote: > > |Hi all,| > |Please review a ||*Test **bu**g *fix ||for| |the issue > > | > JDK-8028618:[TEST BUG] > javax/swing/JScrollBar/bug4202954/bug4202954.java fails > > | > | > |Bug link : https://bugs.openjdk.java.net/browse/JDK-8028618 > ||| > |Webrev link: http://cr.openjdk.java.net/~sgupta/8028618/webrev.00/||| > > ws used : http://hg.openjdk.java.net/jdk9/client/jdk > > > -- > Thanks and Regards, > Nadeesh TV > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Tue Aug 4 12:47:56 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 04 Aug 2015 15:47:56 +0300 Subject: [RFR: JDK-8028618 ] [TEST BUG] javax/swing/JScrollBar/bug4202954/bug4202954.java fails In-Reply-To: <55AF4B20.4000208@oracle.com> References: <55A756A4.5010106@oracle.com> <55AF4B20.4000208@oracle.com> Message-ID: <55C0B47C.3010801@oracle.com> +1 Thanks, Alexander. On 07/22/2015 10:49 AM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > > Thanks, > Alexandr. > > On 7/16/2015 10:00 AM, nadeesh tv wrote: >> >> |Hi all,| >> |Please review a ||*Test **bu**g *fix ||for| |the issue >> >> | >> JDK-8028618:[TEST BUG] >> javax/swing/JScrollBar/bug4202954/bug4202954.java fails >> >> | >> | >> |Bug link : https://bugs.openjdk.java.net/browse/JDK-8028618 >> ||| >> |Webrev link: http://cr.openjdk.java.net/~sgupta/8028618/webrev.00/||| >> >> ws used : http://hg.openjdk.java.net/jdk9/client/jdk >> >> >> -- >> Thanks and Regards, >> Nadeesh TV >> > From alexandr.scherbatiy at oracle.com Tue Aug 4 15:17:18 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 04 Aug 2015 18:17:18 +0300 Subject: [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager In-Reply-To: <55C0AC85.4010402@oracle.com> References: <55B7BAEB.5050501@oracle.com> <55BA17E3.7020701@oracle.com> <55BA1B7A.7010502@oracle.com> <55BA3448.2040801@oracle.com> <55BB194C.50105@oracle.com> <55BF5AA0.4060703@oracle.com> <55BF6A4C.8080007@oracle.com> <55C07C04.6000301@oracle.com> <55C086AD.2070709@oracle.com> <55C09C16.1040907@oracle.com> <55C0AC85.4010402@oracle.com> Message-ID: <55C0D77E.2030907@oracle.com> On 8/4/2015 3:13 PM, Semyon Sadetsky wrote: > > > On 8/4/2015 2:03 PM, Alexander Scherbatiy wrote: >> On 8/4/2015 12:32 PM, Semyon Sadetsky wrote: >>> >>> >>> On 8/4/2015 11:47 AM, Alexander Scherbatiy wrote: >>>> On 8/3/2015 4:19 PM, Semyon Sadetsky wrote: >>>>> On 8/3/2015 3:12 PM, Alexander Scherbatiy wrote: >>>>>> On 7/31/2015 9:44 AM, Semyon Sadetsky wrote: >>>>>>> Good question. But I did not add a concrete class. >>>>>>> The problem is that UndoManager provided by JDK wants to be >>>>>>> serialized but undoable objects knows nothing about that. The >>>>>>> contract between UndoManager and undoable is >>>>>>> UndoableEditListener which only notifies UndoManager to add a >>>>>>> new edit. AbstractDocument does not care about the specific >>>>>>> UndoManager implementation and it can contain plenty different >>>>>>> UndoableEditListener. That is the current API approach. >>>>>>> If our specific UndoManager wants to be serialized it should >>>>>>> also take into account that the undoable it controls may require >>>>>>> serialization. For that it needs undoable's synchronization >>>>>>> monitor and AbstractDocument can provide it using >>>>>>> writeLock()/writeUnlock() methods. I assumed that in the first >>>>>>> turn UndoManger should work well with JDK undoables than to >>>>>>> serve as a general implementation. Also I tried to preserve the >>>>>>> current API. >>>>>>> And your suggestion is to change the existing >>>>>>> UndoableEditListener API by introducing synchronization methods >>>>>>> in it. Am I correctly understand you? >>>>>> >>>>>> What I said is that UndoManager can be used not only by >>>>>> AbstractDocument but also in other classes which can have the >>>>>> same synchronization problems. >>>>>> There should be a way to solve these problems without storing >>>>>> links of external classes inside the UndoManager. >>>>>> >>>>> >>>>> As well as AbstractDocument can use another undo managers. It can >>>>> be addressed to both parties. They need each others locks to >>>>> serialize changes without deadlock. >>>>> AbstarctDocument is related to UndoableEditListener as one to many >>>>> that means a lock should be taken for each undo manager before the >>>>> document change. >>>>> Undo manager does not have any methods to get its lock because it >>>>> is an UndoableEditListener implementation. AbstarctDocument has >>>>> API to receive its lock. >>>>> Do you still propose to fix the issue on AbstractDocument side? >>>> Yes. >>>>> Could you clarify how do you see such fix? >>>> >>>> Put an UndoableEdit/UndoableEditEvent/necessary information to >>>> a queue instead of firing the undoable edit event under the write >>>> lock. Do not read the queue under the write lock. The queue allows >>>> to preserve the order of UndoableEdit's adding to an UndoManager. >>>> >>> Is not it the same as the previous attempt to fix this issue (see >>> 8030118 )? >> 8030118 fix does a strange thing like firing InsertUpdate >> document event out of the lock. Do not do that. >>> Document change event need to be fired under write lock because the >>> change to the document should be atomic. Queue of changes is undo >>> manager's responsibility not the document. >>> And such queue in the AbstractDocument would require complex >>> coordination with all its undo managers queues. What if undo called >>> on undo manager during the doc's queue processing? The right >>> undo/redo requests and edit events order need to be preserved in >>> this case and it would be too complex or we would have to change the >>> concept and make AbstractDocument to maintain its undo/redo history >>> internally instead of external undo managers. >> It only needs to pass undoable edits in the right order from >> abstract document to the UndoManager. > > Consider the scenario: UndoManager executes undo/redo before it > receives the undoable edits. As result it will undo not the last edit > but intermediate and it will crash because the document state is > changed and intermediate the undoable edit cannot be applied to the > final document state. This is a good point. But this does not work neither with the current behavior nor with your proposed fix. Consider the following scenario: ----------------------- document.insertString("AAA") // "AAA" UndoableEdit is added to the UndoManager document.insertString("BBB") writeLock(); handleInsertString(); // a user press undo, the "AAA" UndoableEdit is selected in UndoManager but not executed, because of the write lock fireUndoableEditUpdate("BBB") // UndoManager is waiting for the "AAA" UndoableEdit execution writeUnlock() // "AAA" UndoableEdit is executed instead of "BBB" // "BBB" UndoableEdit is added to the UndoManager ----------------------- > >> >>> 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. > >>> 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? --------------- 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 semyon.sadetsky at oracle.com Tue Aug 4 17:13:42 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 04 Aug 2015 20:13:42 +0300 Subject: [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager In-Reply-To: <55C0D77E.2030907@oracle.com> References: <55B7BAEB.5050501@oracle.com> <55BA17E3.7020701@oracle.com> <55BA1B7A.7010502@oracle.com> <55BA3448.2040801@oracle.com> <55BB194C.50105@oracle.com> <55BF5AA0.4060703@oracle.com> <55BF6A4C.8080007@oracle.com> <55C07C04.6000301@oracle.com> <55C086AD.2070709@oracle.com> <55C09C16.1040907@oracle.com> <55C0AC85.4010402@oracle.com> <55C0D77E.2030907@oracle.com> Message-ID: <55C0F2C6.5000509@oracle.com> On 8/4/2015 6:17 PM, Alexander Scherbatiy wrote: > On 8/4/2015 3:13 PM, Semyon Sadetsky wrote: >> >> >> On 8/4/2015 2:03 PM, Alexander Scherbatiy wrote: >>> On 8/4/2015 12:32 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> On 8/4/2015 11:47 AM, Alexander Scherbatiy wrote: >>>>> On 8/3/2015 4:19 PM, Semyon Sadetsky wrote: >>>>>> On 8/3/2015 3:12 PM, Alexander Scherbatiy wrote: >>>>>>> On 7/31/2015 9:44 AM, Semyon Sadetsky wrote: >>>>>>>> Good question. But I did not add a concrete class. >>>>>>>> The problem is that UndoManager provided by JDK wants to be >>>>>>>> serialized but undoable objects knows nothing about that. The >>>>>>>> contract between UndoManager and undoable is >>>>>>>> UndoableEditListener which only notifies UndoManager to add a >>>>>>>> new edit. AbstractDocument does not care about the specific >>>>>>>> UndoManager implementation and it can contain plenty different >>>>>>>> UndoableEditListener. That is the current API approach. >>>>>>>> If our specific UndoManager wants to be serialized it should >>>>>>>> also take into account that the undoable it controls may >>>>>>>> require serialization. For that it needs undoable's >>>>>>>> synchronization monitor and AbstractDocument can provide it >>>>>>>> using writeLock()/writeUnlock() methods. I assumed that in the >>>>>>>> first turn UndoManger should work well with JDK undoables than >>>>>>>> to serve as a general implementation. Also I tried to preserve >>>>>>>> the current API. >>>>>>>> And your suggestion is to change the existing >>>>>>>> UndoableEditListener API by introducing synchronization methods >>>>>>>> in it. Am I correctly understand you? >>>>>>> >>>>>>> What I said is that UndoManager can be used not only by >>>>>>> AbstractDocument but also in other classes which can have the >>>>>>> same synchronization problems. >>>>>>> There should be a way to solve these problems without storing >>>>>>> links of external classes inside the UndoManager. >>>>>>> >>>>>> >>>>>> As well as AbstractDocument can use another undo managers. It can >>>>>> be addressed to both parties. They need each others locks to >>>>>> serialize changes without deadlock. >>>>>> AbstarctDocument is related to UndoableEditListener as one to >>>>>> many that means a lock should be taken for each undo manager >>>>>> before the document change. >>>>>> Undo manager does not have any methods to get its lock because it >>>>>> is an UndoableEditListener implementation. AbstarctDocument has >>>>>> API to receive its lock. >>>>>> Do you still propose to fix the issue on AbstractDocument side? >>>>> Yes. >>>>>> Could you clarify how do you see such fix? >>>>> >>>>> Put an UndoableEdit/UndoableEditEvent/necessary information to >>>>> a queue instead of firing the undoable edit event under the write >>>>> lock. Do not read the queue under the write lock. The queue allows >>>>> to preserve the order of UndoableEdit's adding to an UndoManager. >>>>> >>>> Is not it the same as the previous attempt to fix this issue (see >>>> 8030118 )? >>> 8030118 fix does a strange thing like firing InsertUpdate >>> document event out of the lock. Do not do that. >>>> Document change event need to be fired under write lock because the >>>> change to the document should be atomic. Queue of changes is undo >>>> manager's responsibility not the document. >>>> And such queue in the AbstractDocument would require complex >>>> coordination with all its undo managers queues. What if undo called >>>> on undo manager during the doc's queue processing? The right >>>> undo/redo requests and edit events order need to be preserved in >>>> this case and it would be too complex or we would have to change >>>> the concept and make AbstractDocument to maintain its undo/redo >>>> history internally instead of external undo managers. >>> It only needs to pass undoable edits in the right order from >>> abstract document to the UndoManager. >> >> Consider the scenario: UndoManager executes undo/redo before it >> receives the undoable edits. As result it will undo not the last edit >> but intermediate and it will crash because the document state is >> changed and intermediate the undoable edit cannot be applied to the >> final document state. > > This is a good point. But this does not work neither with the > current behavior nor with your proposed fix. > Consider the following scenario: > ----------------------- > document.insertString("AAA") // "AAA" UndoableEdit is added to > the UndoManager > document.insertString("BBB") > writeLock(); > handleInsertString(); > // a user press undo, the "AAA" UndoableEdit is selected in > UndoManager but not executed, because of the write lock > fireUndoableEditUpdate("BBB") // UndoManager is waiting for > the "AAA" UndoableEdit execution > writeUnlock() // "AAA" UndoableEdit is executed instead of > "BBB" > // "BBB" UndoableEdit is added to > the UndoManager > ----------------------- It will work after the fix. When undo() method is called it will be blocked on the document lock until the edit is done in another thread. Then undo() will acquire the document lock and call editToBeUndone() method which will return the actual last edit added with addEdit() during the undoable callback execution. 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. >> >>>> 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. 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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From WLaan at costengineering.eu Wed Aug 5 06:59:17 2015 From: WLaan at costengineering.eu (Walter Laan) Date: Wed, 5 Aug 2015 06:59:17 +0000 Subject: Public API for internal Swing classes. In-Reply-To: <55C09410.5010700@oracle.com> References: <55B6244C.8040002@oracle.com> <01A824C2-C046-4B29-B8E3-D98A6D980EE0@esko.com> <55BF4EF3.9040900@oracle.com> <59CA7531B79CD24C9220F8C952EF389E18E257AC@EXCH2010.ce.local> <55C09410.5010700@oracle.com> Message-ID: <59CA7531B79CD24C9220F8C952EF389E18E268E8@EXCH2010.ce.local> Done, the Review ID: JI-9023048 -----Original Message----- From: Alexander Scherbatiy [mailto:alexandr.scherbatiy at oracle.com] Sent: dinsdag 4 augustus 2015 12:30 To: Walter Laan Cc: Van Den Borre, Koen ; swing-dev at openjdk.java.net Subject: Re: Public API for internal Swing classes. On 8/4/2015 10:50 AM, Walter Laan wrote: > Below a use case where I had to cast to sun.swing.UIAction to correctly check if it is enabled or not. > Let me know if I need to make the bug report or if you can add it as a comment to any existing issue. Thank you for the report. Yes, please, file an enhancement on it. Thanks, Alexandr. From pooja.chopra at oracle.com Wed Aug 5 07:31:00 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Wed, 05 Aug 2015 13:01:00 +0530 Subject: < Swing Dev> [9] Review Request:JDK-8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java failed with UnsupportedOperation exception In-Reply-To: <55B8AC53.3070103@oracle.com> References: <55A62E46.3020504@oracle.com> <55A630DE.4080500@oracle.com> <55A6AE5A.3060408@oracle.com> <55B86ECA.20306@oracle.com> <55B8AC53.3070103@oracle.com> Message-ID: <55C1BBB4.3010801@oracle.com> Hi Alexandr, Please review update webrev link :- The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.03/ Regards, Pooja On 7/29/2015 4:04 PM, Alexander Scherbatiy wrote: > On 7/29/2015 9:12 AM, pooja chopra wrote: >> Hello Sergey , >> Please review update webrev link below :- >> >> The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.02/ > > After the SystemTray.isSupported() is checked it is not expected > that the UnsupportedOperationException is thrown. The test should fail > in this case. > > Thanks, > Alexandr. > >> >> Regards, >> Pooja >> On 7/16/2015 12:32 AM, Sergey Bylokhov wrote: >>> Hello, >>> I suggest to check support of systemTray at the beginning of the test. >>> >>> On 15.07.15 13:07, pooja chopra wrote: >>>> Hello , >>>> >>>> Corrected the webrev link below . Please review. >>>> >>>> Regards, >>>> Pooja >>>> On 7/15/2015 3:26 PM, pooja chopra wrote: >>>>> Hello, >>>>> >>>>> Please review a fix for issue :- >>>>> >>>>> 8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java >>>>> failed with UnsupportedOperation exception >>>>> Test bug fix. >>>>> https://bugs.openjdk.java.net/browse/JDK-8130481 >>>>> The webrev is : >>>>> http://cr.openjdk.java.net/~pchopra/8130481/webrev.01/ >>>>> >>>>> Regards, >>>>> Pooja >>>>> >>>> >>> >>> >> > From alexandr.scherbatiy at oracle.com Wed Aug 5 09:16:19 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 05 Aug 2015 12:16:19 +0300 Subject: < Swing Dev> [9] Review Request:JDK-8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java failed with UnsupportedOperation exception In-Reply-To: <55C1BBB4.3010801@oracle.com> References: <55A62E46.3020504@oracle.com> <55A630DE.4080500@oracle.com> <55A6AE5A.3060408@oracle.com> <55B86ECA.20306@oracle.com> <55B8AC53.3070103@oracle.com> <55C1BBB4.3010801@oracle.com> Message-ID: <55C1D463.3090407@oracle.com> On 8/5/2015 10:31 AM, pooja chopra wrote: > Hi Alexandr, > > Please review update webrev link :- > > The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.03/ This looks better. There are just minor issues: - run swing components on EDT like: menu.show(frame, 0, 0) - format the code in 'if' block or check the mercurial settings in .hgrc file like diff = -w // ignore white space when comparing lines Thanks, Alexandr. > > Regards, > Pooja > On 7/29/2015 4:04 PM, Alexander Scherbatiy wrote: >> On 7/29/2015 9:12 AM, pooja chopra wrote: >>> Hello Sergey , >>> Please review update webrev link below :- >>> >>> The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.02/ >> >> After the SystemTray.isSupported() is checked it is not expected >> that the UnsupportedOperationException is thrown. The test should >> fail in this case. >> >> Thanks, >> Alexandr. >> >>> >>> Regards, >>> Pooja >>> On 7/16/2015 12:32 AM, Sergey Bylokhov wrote: >>>> Hello, >>>> I suggest to check support of systemTray at the beginning of the test. >>>> >>>> On 15.07.15 13:07, pooja chopra wrote: >>>>> Hello , >>>>> >>>>> Corrected the webrev link below . Please review. >>>>> >>>>> Regards, >>>>> Pooja >>>>> On 7/15/2015 3:26 PM, pooja chopra wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a fix for issue :- >>>>>> >>>>>> 8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java >>>>>> failed with UnsupportedOperation exception >>>>>> Test bug fix. >>>>>> https://bugs.openjdk.java.net/browse/JDK-8130481 >>>>>> The webrev is : >>>>>> http://cr.openjdk.java.net/~pchopra/8130481/webrev.01/ >>>>>> >>>>>> Regards, >>>>>> Pooja >>>>>> >>>>> >>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Wed Aug 5 10:04:53 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 05 Aug 2015 13:04:53 +0300 Subject: [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager In-Reply-To: <55C0F2C6.5000509@oracle.com> References: <55B7BAEB.5050501@oracle.com> <55BA17E3.7020701@oracle.com> <55BA1B7A.7010502@oracle.com> <55BA3448.2040801@oracle.com> <55BB194C.50105@oracle.com> <55BF5AA0.4060703@oracle.com> <55BF6A4C.8080007@oracle.com> <55C07C04.6000301@oracle.com> <55C086AD.2070709@oracle.com> <55C09C16.1040907@oracle.com> <55C0AC85.4010402@oracle.com> <55C0D77E.2030907@oracle.com> <55C0F2C6.5000509@oracle.com> Message-ID: <55C1DFC5.8000007@oracle.com> On 8/4/2015 8:13 PM, Semyon Sadetsky wrote: > > > On 8/4/2015 6:17 PM, Alexander Scherbatiy wrote: >> On 8/4/2015 3:13 PM, Semyon Sadetsky wrote: >>> >>> >>> On 8/4/2015 2:03 PM, Alexander Scherbatiy wrote: >>>> On 8/4/2015 12:32 PM, Semyon Sadetsky wrote: >>>>> >>>>> >>>>> On 8/4/2015 11:47 AM, Alexander Scherbatiy wrote: >>>>>> On 8/3/2015 4:19 PM, Semyon Sadetsky wrote: >>>>>>> On 8/3/2015 3:12 PM, Alexander Scherbatiy wrote: >>>>>>>> On 7/31/2015 9:44 AM, Semyon Sadetsky wrote: >>>>>>>>> Good question. But I did not add a concrete class. >>>>>>>>> The problem is that UndoManager provided by JDK wants to be >>>>>>>>> serialized but undoable objects knows nothing about that. The >>>>>>>>> contract between UndoManager and undoable is >>>>>>>>> UndoableEditListener which only notifies UndoManager to add a >>>>>>>>> new edit. AbstractDocument does not care about the specific >>>>>>>>> UndoManager implementation and it can contain plenty different >>>>>>>>> UndoableEditListener. That is the current API approach. >>>>>>>>> If our specific UndoManager wants to be serialized it should >>>>>>>>> also take into account that the undoable it controls may >>>>>>>>> require serialization. For that it needs undoable's >>>>>>>>> synchronization monitor and AbstractDocument can provide it >>>>>>>>> using writeLock()/writeUnlock() methods. I assumed that in the >>>>>>>>> first turn UndoManger should work well with JDK undoables than >>>>>>>>> to serve as a general implementation. Also I tried to >>>>>>>>> preserve the current API. >>>>>>>>> And your suggestion is to change the existing >>>>>>>>> UndoableEditListener API by introducing synchronization >>>>>>>>> methods in it. Am I correctly understand you? >>>>>>>> >>>>>>>> What I said is that UndoManager can be used not only by >>>>>>>> AbstractDocument but also in other classes which can have the >>>>>>>> same synchronization problems. >>>>>>>> There should be a way to solve these problems without >>>>>>>> storing links of external classes inside the UndoManager. >>>>>>>> >>>>>>> >>>>>>> As well as AbstractDocument can use another undo managers. It >>>>>>> can be addressed to both parties. They need each others locks to >>>>>>> serialize changes without deadlock. >>>>>>> AbstarctDocument is related to UndoableEditListener as one to >>>>>>> many that means a lock should be taken for each undo manager >>>>>>> before the document change. >>>>>>> Undo manager does not have any methods to get its lock because >>>>>>> it is an UndoableEditListener implementation. AbstarctDocument >>>>>>> has API to receive its lock. >>>>>>> Do you still propose to fix the issue on AbstractDocument side? >>>>>> Yes. >>>>>>> Could you clarify how do you see such fix? >>>>>> >>>>>> Put an UndoableEdit/UndoableEditEvent/necessary information >>>>>> to a queue instead of firing the undoable edit event under the >>>>>> write lock. Do not read the queue under the write lock. The queue >>>>>> allows to preserve the order of UndoableEdit's adding to an >>>>>> UndoManager. >>>>>> >>>>> Is not it the same as the previous attempt to fix this issue (see >>>>> 8030118 )? >>>> 8030118 fix does a strange thing like firing InsertUpdate >>>> document event out of the lock. Do not do that. >>>>> Document change event need to be fired under write lock because >>>>> the change to the document should be atomic. Queue of changes is >>>>> undo manager's responsibility not the document. >>>>> And such queue in the AbstractDocument would require complex >>>>> coordination with all its undo managers queues. What if undo >>>>> called on undo manager during the doc's queue processing? The >>>>> right undo/redo requests and edit events order need to be >>>>> preserved in this case and it would be too complex or we would >>>>> have to change the concept and make AbstractDocument to maintain >>>>> its undo/redo history internally instead of external undo managers. >>>> It only needs to pass undoable edits in the right order from >>>> abstract document to the UndoManager. >>> >>> Consider the scenario: UndoManager executes undo/redo before it >>> receives the undoable edits. As result it will undo not the last >>> edit but intermediate and it will crash because the document state >>> is changed and intermediate the undoable edit cannot be applied to >>> the final document state. >> >> This is a good point. But this does not work neither with the >> current behavior nor with your proposed fix. >> Consider the following scenario: >> ----------------------- >> document.insertString("AAA") // "AAA" UndoableEdit is added to >> the UndoManager >> document.insertString("BBB") >> writeLock(); >> handleInsertString(); >> // a user press undo, the "AAA" UndoableEdit is selected in >> UndoManager but not executed, because of the write lock >> fireUndoableEditUpdate("BBB") // UndoManager is waiting >> for the "AAA" UndoableEdit execution >> writeUnlock() // "AAA" UndoableEdit is executed instead of >> "BBB" >> // "BBB" UndoableEdit is added to >> the UndoManager >> ----------------------- > It will work after the fix. When undo() method is called it will be > blocked on the document lock until the edit is done in another thread. > Then undo() will acquire the document lock and call editToBeUndone() > method which will return the actual last edit added with addEdit() > during the undoable callback execution. Is it possible to use the same undo manager with several abstract documents? If so, how are you going to map a document lock with the document undoable edit without querying it? > 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. > >>> >>>>> 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? 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 semyon.sadetsky at oracle.com Wed Aug 5 11:00:19 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 05 Aug 2015 14:00:19 +0300 Subject: [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager In-Reply-To: <55C1DFC5.8000007@oracle.com> References: <55B7BAEB.5050501@oracle.com> <55BA17E3.7020701@oracle.com> <55BA1B7A.7010502@oracle.com> <55BA3448.2040801@oracle.com> <55BB194C.50105@oracle.com> <55BF5AA0.4060703@oracle.com> <55BF6A4C.8080007@oracle.com> <55C07C04.6000301@oracle.com> <55C086AD.2070709@oracle.com> <55C09C16.1040907@oracle.com> <55C0AC85.4010402@oracle.com> <55C0D77E.2030907@oracle.com> <55C0F2C6.5000509@oracle.com> <55C1DFC5.8000007@oracle.com> Message-ID: <55C1ECC3.1080109@oracle.com> On 8/5/2015 1:04 PM, Alexander Scherbatiy wrote: > On 8/4/2015 8:13 PM, Semyon Sadetsky wrote: >> >> >> On 8/4/2015 6:17 PM, Alexander Scherbatiy wrote: >>> On 8/4/2015 3:13 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> On 8/4/2015 2:03 PM, Alexander Scherbatiy wrote: >>>>> On 8/4/2015 12:32 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> >>>>>> On 8/4/2015 11:47 AM, Alexander Scherbatiy wrote: >>>>>>> On 8/3/2015 4:19 PM, Semyon Sadetsky wrote: >>>>>>>> On 8/3/2015 3:12 PM, Alexander Scherbatiy wrote: >>>>>>>>> On 7/31/2015 9:44 AM, Semyon Sadetsky wrote: >>>>>>>>>> Good question. But I did not add a concrete class. >>>>>>>>>> The problem is that UndoManager provided by JDK wants to be >>>>>>>>>> serialized but undoable objects knows nothing about that. The >>>>>>>>>> contract between UndoManager and undoable is >>>>>>>>>> UndoableEditListener which only notifies UndoManager to add a >>>>>>>>>> new edit. AbstractDocument does not care about the specific >>>>>>>>>> UndoManager implementation and it can contain plenty >>>>>>>>>> different UndoableEditListener. That is the current API >>>>>>>>>> approach. >>>>>>>>>> If our specific UndoManager wants to be serialized it should >>>>>>>>>> also take into account that the undoable it controls may >>>>>>>>>> require serialization. For that it needs undoable's >>>>>>>>>> synchronization monitor and AbstractDocument can provide it >>>>>>>>>> using writeLock()/writeUnlock() methods. I assumed that in >>>>>>>>>> the first turn UndoManger should work well with JDK undoables >>>>>>>>>> than to serve as a general implementation. Also I tried to >>>>>>>>>> preserve the current API. >>>>>>>>>> And your suggestion is to change the existing >>>>>>>>>> UndoableEditListener API by introducing synchronization >>>>>>>>>> methods in it. Am I correctly understand you? >>>>>>>>> >>>>>>>>> What I said is that UndoManager can be used not only by >>>>>>>>> AbstractDocument but also in other classes which can have the >>>>>>>>> same synchronization problems. >>>>>>>>> There should be a way to solve these problems without >>>>>>>>> storing links of external classes inside the UndoManager. >>>>>>>>> >>>>>>>> >>>>>>>> As well as AbstractDocument can use another undo managers. It >>>>>>>> can be addressed to both parties. They need each others locks >>>>>>>> to serialize changes without deadlock. >>>>>>>> AbstarctDocument is related to UndoableEditListener as one to >>>>>>>> many that means a lock should be taken for each undo manager >>>>>>>> before the document change. >>>>>>>> Undo manager does not have any methods to get its lock because >>>>>>>> it is an UndoableEditListener implementation. AbstarctDocument >>>>>>>> has API to receive its lock. >>>>>>>> Do you still propose to fix the issue on AbstractDocument side? >>>>>>> Yes. >>>>>>>> Could you clarify how do you see such fix? >>>>>>> >>>>>>> Put an UndoableEdit/UndoableEditEvent/necessary information >>>>>>> to a queue instead of firing the undoable edit event under the >>>>>>> write lock. Do not read the queue under the write lock. The >>>>>>> queue allows to preserve the order of UndoableEdit's adding to >>>>>>> an UndoManager. >>>>>>> >>>>>> Is not it the same as the previous attempt to fix this issue (see >>>>>> 8030118 )? >>>>> 8030118 fix does a strange thing like firing InsertUpdate >>>>> document event out of the lock. Do not do that. >>>>>> Document change event need to be fired under write lock because >>>>>> the change to the document should be atomic. Queue of changes is >>>>>> undo manager's responsibility not the document. >>>>>> And such queue in the AbstractDocument would require complex >>>>>> coordination with all its undo managers queues. What if undo >>>>>> called on undo manager during the doc's queue processing? The >>>>>> right undo/redo requests and edit events order need to be >>>>>> preserved in this case and it would be too complex or we would >>>>>> have to change the concept and make AbstractDocument to maintain >>>>>> its undo/redo history internally instead of external undo managers. >>>>> It only needs to pass undoable edits in the right order from >>>>> abstract document to the UndoManager. >>>> >>>> Consider the scenario: UndoManager executes undo/redo before it >>>> receives the undoable edits. As result it will undo not the last >>>> edit but intermediate and it will crash because the document state >>>> is changed and intermediate the undoable edit cannot be applied to >>>> the final document state. >>> >>> This is a good point. But this does not work neither with the >>> current behavior nor with your proposed fix. >>> Consider the following scenario: >>> ----------------------- >>> document.insertString("AAA") // "AAA" UndoableEdit is added to >>> the UndoManager >>> document.insertString("BBB") >>> writeLock(); >>> handleInsertString(); >>> // a user press undo, the "AAA" UndoableEdit is selected >>> in UndoManager but not executed, because of the write lock >>> fireUndoableEditUpdate("BBB") // UndoManager is waiting >>> for the "AAA" UndoableEdit execution >>> writeUnlock() // "AAA" UndoableEdit is executed instead >>> of "BBB" >>> // "BBB" UndoableEdit is added to >>> the UndoManager >>> ----------------------- >> It will work after the fix. When undo() method is called it will be >> blocked on the document lock until the edit is done in another >> thread. Then undo() will acquire the document lock and call >> editToBeUndone() method which will return the actual last edit added >> with addEdit() during the undoable callback execution. > > Is it possible to use the same undo manager with several abstract > documents? If so, how are you going to map a document lock with the > document undoable edit without querying it? That scenario is possible. As well as several undo managers can be assigned to the same document. I think I can improve the fix in that direction when you agree with the general approach. > >> 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 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 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 Wed Aug 5 11:39:28 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 05 Aug 2015 14:39:28 +0300 Subject: [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager In-Reply-To: <55C1ECC3.1080109@oracle.com> References: <55B7BAEB.5050501@oracle.com> <55BA17E3.7020701@oracle.com> <55BA1B7A.7010502@oracle.com> <55BA3448.2040801@oracle.com> <55BB194C.50105@oracle.com> <55BF5AA0.4060703@oracle.com> <55BF6A4C.8080007@oracle.com> <55C07C04.6000301@oracle.com> <55C086AD.2070709@oracle.com> <55C09C16.1040907@oracle.com> <55C0AC85.4010402@oracle.com> <55C0D77E.2030907@oracle.com> <55C0F2C6.5000509@oracle.com> <55C1DFC5.8000007@oracle.com> <55C1ECC3.1080109@oracle.com> Message-ID: <55C1F5F0.2050608@oracle.com> On 8/5/2015 2:00 PM, Semyon Sadetsky wrote: > > > On 8/5/2015 1:04 PM, Alexander Scherbatiy wrote: >> On 8/4/2015 8:13 PM, Semyon Sadetsky wrote: >>> >>> >>> On 8/4/2015 6:17 PM, Alexander Scherbatiy wrote: >>>> On 8/4/2015 3:13 PM, Semyon Sadetsky wrote: >>>>> >>>>> >>>>> On 8/4/2015 2:03 PM, Alexander Scherbatiy wrote: >>>>>> On 8/4/2015 12:32 PM, Semyon Sadetsky wrote: >>>>>>> >>>>>>> >>>>>>> On 8/4/2015 11:47 AM, Alexander Scherbatiy wrote: >>>>>>>> On 8/3/2015 4:19 PM, Semyon Sadetsky wrote: >>>>>>>>> On 8/3/2015 3:12 PM, Alexander Scherbatiy wrote: >>>>>>>>>> On 7/31/2015 9:44 AM, Semyon Sadetsky wrote: >>>>>>>>>>> Good question. But I did not add a concrete class. >>>>>>>>>>> The problem is that UndoManager provided by JDK wants to be >>>>>>>>>>> serialized but undoable objects knows nothing about that. >>>>>>>>>>> The contract between UndoManager and undoable is >>>>>>>>>>> UndoableEditListener which only notifies UndoManager to add >>>>>>>>>>> a new edit. AbstractDocument does not care about the >>>>>>>>>>> specific UndoManager implementation and it can contain >>>>>>>>>>> plenty different UndoableEditListener. That is the current >>>>>>>>>>> API approach. >>>>>>>>>>> If our specific UndoManager wants to be serialized it should >>>>>>>>>>> also take into account that the undoable it controls may >>>>>>>>>>> require serialization. For that it needs undoable's >>>>>>>>>>> synchronization monitor and AbstractDocument can provide it >>>>>>>>>>> using writeLock()/writeUnlock() methods. I assumed that in >>>>>>>>>>> the first turn UndoManger should work well with JDK >>>>>>>>>>> undoables than to serve as a general implementation. Also I >>>>>>>>>>> tried to preserve the current API. >>>>>>>>>>> And your suggestion is to change the existing >>>>>>>>>>> UndoableEditListener API by introducing synchronization >>>>>>>>>>> methods in it. Am I correctly understand you? >>>>>>>>>> >>>>>>>>>> What I said is that UndoManager can be used not only by >>>>>>>>>> AbstractDocument but also in other classes which can have the >>>>>>>>>> same synchronization problems. >>>>>>>>>> There should be a way to solve these problems without >>>>>>>>>> storing links of external classes inside the UndoManager. >>>>>>>>>> >>>>>>>>> >>>>>>>>> As well as AbstractDocument can use another undo managers. It >>>>>>>>> can be addressed to both parties. They need each others locks >>>>>>>>> to serialize changes without deadlock. >>>>>>>>> AbstarctDocument is related to UndoableEditListener as one to >>>>>>>>> many that means a lock should be taken for each undo manager >>>>>>>>> before the document change. >>>>>>>>> Undo manager does not have any methods to get its lock because >>>>>>>>> it is an UndoableEditListener implementation. AbstarctDocument >>>>>>>>> has API to receive its lock. >>>>>>>>> Do you still propose to fix the issue on AbstractDocument side? >>>>>>>> Yes. >>>>>>>>> Could you clarify how do you see such fix? >>>>>>>> >>>>>>>> Put an UndoableEdit/UndoableEditEvent/necessary information >>>>>>>> to a queue instead of firing the undoable edit event under the >>>>>>>> write lock. Do not read the queue under the write lock. The >>>>>>>> queue allows to preserve the order of UndoableEdit's adding to >>>>>>>> an UndoManager. >>>>>>>> >>>>>>> Is not it the same as the previous attempt to fix this issue >>>>>>> (see 8030118 )? >>>>>> 8030118 fix does a strange thing like firing InsertUpdate >>>>>> document event out of the lock. Do not do that. >>>>>>> Document change event need to be fired under write lock because >>>>>>> the change to the document should be atomic. Queue of changes is >>>>>>> undo manager's responsibility not the document. >>>>>>> And such queue in the AbstractDocument would require complex >>>>>>> coordination with all its undo managers queues. What if undo >>>>>>> called on undo manager during the doc's queue processing? The >>>>>>> right undo/redo requests and edit events order need to be >>>>>>> preserved in this case and it would be too complex or we would >>>>>>> have to change the concept and make AbstractDocument to maintain >>>>>>> its undo/redo history internally instead of external undo managers. >>>>>> It only needs to pass undoable edits in the right order from >>>>>> abstract document to the UndoManager. >>>>> >>>>> Consider the scenario: UndoManager executes undo/redo before it >>>>> receives the undoable edits. As result it will undo not the last >>>>> edit but intermediate and it will crash because the document state >>>>> is changed and intermediate the undoable edit cannot be applied to >>>>> the final document state. >>>> >>>> This is a good point. But this does not work neither with the >>>> current behavior nor with your proposed fix. >>>> Consider the following scenario: >>>> ----------------------- >>>> document.insertString("AAA") // "AAA" UndoableEdit is added >>>> to the UndoManager >>>> document.insertString("BBB") >>>> writeLock(); >>>> handleInsertString(); >>>> // a user press undo, the "AAA" UndoableEdit is selected >>>> in UndoManager but not executed, because of the write lock >>>> fireUndoableEditUpdate("BBB") // UndoManager is waiting >>>> for the "AAA" UndoableEdit execution >>>> writeUnlock() // "AAA" UndoableEdit is executed instead >>>> of "BBB" >>>> // "BBB" UndoableEdit is added >>>> to the UndoManager >>>> ----------------------- >>> It will work after the fix. When undo() method is called it will be >>> blocked on the document lock until the edit is done in another >>> thread. Then undo() will acquire the document lock and call >>> editToBeUndone() method which will return the actual last edit added >>> with addEdit() during the undoable callback execution. >> >> Is it possible to use the same undo manager with several abstract >> documents? If so, how are you going to map a document lock with the >> document undoable edit without querying it? > That scenario is possible. As well as several undo managers can be > assigned to the same document. I think I can improve the fix in that > direction when you agree with the general approach. It is interesting how it is possible to do that without querying an undoable edit. Your fix is relaying that an abstract document lock should precede the undo manager lock but to get the right abstract manager lock you need to take an undoable edit under the undo manager lock first. >> >>> 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. > 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? 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 semyon.sadetsky at oracle.com Wed Aug 5 13:50:31 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 05 Aug 2015 16:50:31 +0300 Subject: [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager In-Reply-To: <55C1F5F0.2050608@oracle.com> References: <55B7BAEB.5050501@oracle.com> <55BA17E3.7020701@oracle.com> <55BA1B7A.7010502@oracle.com> <55BA3448.2040801@oracle.com> <55BB194C.50105@oracle.com> <55BF5AA0.4060703@oracle.com> <55BF6A4C.8080007@oracle.com> <55C07C04.6000301@oracle.com> <55C086AD.2070709@oracle.com> <55C09C16.1040907@oracle.com> <55C0AC85.4010402@oracle.com> <55C0D77E.2030907@oracle.com> <55C0F2C6.5000509@oracle.com> <55C1DFC5.8000007@oracle.com> <55C1ECC3.1080109@oracle.com> <55C1F5F0.2050608@oracle.com> Message-ID: <55C214A7.3080207@oracle.com> On 8/5/2015 2:39 PM, Alexander Scherbatiy wrote: > On 8/5/2015 2:00 PM, Semyon Sadetsky wrote: >> >> >> On 8/5/2015 1:04 PM, Alexander Scherbatiy wrote: >>> On 8/4/2015 8:13 PM, Semyon Sadetsky wrote: >>>> >>>> >>>> On 8/4/2015 6:17 PM, Alexander Scherbatiy wrote: >>>>> On 8/4/2015 3:13 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> >>>>>> On 8/4/2015 2:03 PM, Alexander Scherbatiy wrote: >>>>>>> On 8/4/2015 12:32 PM, Semyon Sadetsky wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 8/4/2015 11:47 AM, Alexander Scherbatiy wrote: >>>>>>>>> On 8/3/2015 4:19 PM, Semyon Sadetsky wrote: >>>>>>>>>> On 8/3/2015 3:12 PM, Alexander Scherbatiy wrote: >>>>>>>>>>> On 7/31/2015 9:44 AM, Semyon Sadetsky wrote: >>>>>>>>>>>> Good question. But I did not add a concrete class. >>>>>>>>>>>> The problem is that UndoManager provided by JDK wants to be >>>>>>>>>>>> serialized but undoable objects knows nothing about that. >>>>>>>>>>>> The contract between UndoManager and undoable is >>>>>>>>>>>> UndoableEditListener which only notifies UndoManager to add >>>>>>>>>>>> a new edit. AbstractDocument does not care about the >>>>>>>>>>>> specific UndoManager implementation and it can contain >>>>>>>>>>>> plenty different UndoableEditListener. That is the current >>>>>>>>>>>> API approach. >>>>>>>>>>>> If our specific UndoManager wants to be serialized it >>>>>>>>>>>> should also take into account that the undoable it controls >>>>>>>>>>>> may require serialization. For that it needs undoable's >>>>>>>>>>>> synchronization monitor and AbstractDocument can provide it >>>>>>>>>>>> using writeLock()/writeUnlock() methods. I assumed that in >>>>>>>>>>>> the first turn UndoManger should work well with JDK >>>>>>>>>>>> undoables than to serve as a general implementation. Also I >>>>>>>>>>>> tried to preserve the current API. >>>>>>>>>>>> And your suggestion is to change the existing >>>>>>>>>>>> UndoableEditListener API by introducing synchronization >>>>>>>>>>>> methods in it. Am I correctly understand you? >>>>>>>>>>> >>>>>>>>>>> What I said is that UndoManager can be used not only by >>>>>>>>>>> AbstractDocument but also in other classes which can have >>>>>>>>>>> the same synchronization problems. >>>>>>>>>>> There should be a way to solve these problems without >>>>>>>>>>> storing links of external classes inside the UndoManager. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> As well as AbstractDocument can use another undo managers. It >>>>>>>>>> can be addressed to both parties. They need each others locks >>>>>>>>>> to serialize changes without deadlock. >>>>>>>>>> AbstarctDocument is related to UndoableEditListener as one to >>>>>>>>>> many that means a lock should be taken for each undo manager >>>>>>>>>> before the document change. >>>>>>>>>> Undo manager does not have any methods to get its lock >>>>>>>>>> because it is an UndoableEditListener implementation. >>>>>>>>>> AbstarctDocument has API to receive its lock. >>>>>>>>>> Do you still propose to fix the issue on AbstractDocument side? >>>>>>>>> Yes. >>>>>>>>>> Could you clarify how do you see such fix? >>>>>>>>> >>>>>>>>> Put an UndoableEdit/UndoableEditEvent/necessary >>>>>>>>> information to a queue instead of firing the undoable edit >>>>>>>>> event under the write lock. Do not read the queue under the >>>>>>>>> write lock. The queue allows to preserve the order of >>>>>>>>> UndoableEdit's adding to an UndoManager. >>>>>>>>> >>>>>>>> Is not it the same as the previous attempt to fix this issue >>>>>>>> (see 8030118 )? >>>>>>> 8030118 fix does a strange thing like firing InsertUpdate >>>>>>> document event out of the lock. Do not do that. >>>>>>>> Document change event need to be fired under write lock because >>>>>>>> the change to the document should be atomic. Queue of changes >>>>>>>> is undo manager's responsibility not the document. >>>>>>>> And such queue in the AbstractDocument would require complex >>>>>>>> coordination with all its undo managers queues. What if undo >>>>>>>> called on undo manager during the doc's queue processing? The >>>>>>>> right undo/redo requests and edit events order need to be >>>>>>>> preserved in this case and it would be too complex or we would >>>>>>>> have to change the concept and make AbstractDocument to >>>>>>>> maintain its undo/redo history internally instead of external >>>>>>>> undo managers. >>>>>>> It only needs to pass undoable edits in the right order from >>>>>>> abstract document to the UndoManager. >>>>>> >>>>>> Consider the scenario: UndoManager executes undo/redo before it >>>>>> receives the undoable edits. As result it will undo not the last >>>>>> edit but intermediate and it will crash because the document >>>>>> state is changed and intermediate the undoable edit cannot be >>>>>> applied to the final document state. >>>>> >>>>> This is a good point. But this does not work neither with the >>>>> current behavior nor with your proposed fix. >>>>> Consider the following scenario: >>>>> ----------------------- >>>>> document.insertString("AAA") // "AAA" UndoableEdit is added >>>>> to the UndoManager >>>>> document.insertString("BBB") >>>>> writeLock(); >>>>> handleInsertString(); >>>>> // a user press undo, the "AAA" UndoableEdit is selected >>>>> in UndoManager but not executed, because of the write lock >>>>> fireUndoableEditUpdate("BBB") // UndoManager is waiting >>>>> for the "AAA" UndoableEdit execution >>>>> writeUnlock() // "AAA" UndoableEdit is executed instead >>>>> of "BBB" >>>>> // "BBB" UndoableEdit is added >>>>> to the UndoManager >>>>> ----------------------- >>>> It will work after the fix. When undo() method is called it will be >>>> blocked on the document lock until the edit is done in another >>>> thread. Then undo() will acquire the document lock and call >>>> editToBeUndone() method which will return the actual last edit >>>> added with addEdit() during the undoable callback execution. >>> >>> Is it possible to use the same undo manager with several abstract >>> documents? If so, how are you going to map a document lock with the >>> document undoable edit without querying it? >> That scenario is possible. As well as several undo managers can be >> assigned to the same document. I think I can improve the fix in that >> direction when you agree with the general approach. > It is interesting how it is possible to do that without querying > an undoable edit. Your fix is relaying that an abstract document lock > should precede the undo manager lock but to get the right abstract > manager lock you need to take an undoable edit under the undo manager > lock first. We always have only two possible directions forward and backward so it will require only 2 references. > >>> >>>> 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 nadeesh.tv at oracle.com Wed Aug 5 14:05:55 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 05 Aug 2015 19:35:55 +0530 Subject: [RFR JDK-8017187] [TEST BUG] [macosx] After click "test", the case failed automatically with thrown exception in the log since jdk8b75 In-Reply-To: <55B8A606.3030302@oracle.com> References: <55B28053.4000101@oracle.com> <55B8A606.3030302@oracle.com> Message-ID: <55C21843.6020806@oracle.com> HI all, Please review the updated webrev links closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ Thanks and Regards, Nadeesh TV On 7/29/2015 3:38 PM, Alexander Scherbatiy wrote: > > - It looks like the html file has been used only because the test was > manual and it can be simply removed. > - Is it possible to use a robot to press keys rather than put > KeyEvents directly to the SystemEventQueue? > > Thanks, > Alexandr. > > > On 7/24/2015 9:13 PM, nadeesh tv wrote: >> >> Hi all, >> >> Please review a test bug fix >> >> TEST : *closed/javax/swing/JMenu/4213634/bug4213634.java * >> BUG ID -*https://bugs.openjdk.java.net/browse/JDK-8017187* >> >> Please*move the test from closed repo tom open repo*. >> >> >> The webrev is:http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >> add to open repo >> >> >> http://cr.openjdk.java.net/~kshefov/8017187/webrev.diff/ - diff with >> previous version of the closed test. >> >> -- >> Thanks and Regards, >> Nadeesh TV >> > -- Thanks and Regards, Nadeesh TV From alexandr.scherbatiy at oracle.com Wed Aug 5 15:34:28 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 05 Aug 2015 18:34:28 +0300 Subject: [RFR JDK-8017187] [TEST BUG] [macosx] After click "test", the case failed automatically with thrown exception in the log since jdk8b75 In-Reply-To: <55C21843.6020806@oracle.com> References: <55B28053.4000101@oracle.com> <55B8A606.3030302@oracle.com> <55C21843.6020806@oracle.com> Message-ID: <55C22D04.7000405@oracle.com> On 8/5/2015 5:05 PM, nadeesh tv wrote: > HI all, > Please review the updated webrev links > closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ > open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ - the patch does not contain the html file as it expected but it still is shown on the provided open link. It seems that the index.html file has not been updated. - the swing calls like "!menu.isSelected()" should be invoked on EDT. Thanks, Alexandr. > Thanks and Regards, > Nadeesh TV > > On 7/29/2015 3:38 PM, Alexander Scherbatiy wrote: >> >> - It looks like the html file has been used only because the test >> was manual and it can be simply removed. >> - Is it possible to use a robot to press keys rather than put >> KeyEvents directly to the SystemEventQueue? >> >> Thanks, >> Alexandr. >> >> >> On 7/24/2015 9:13 PM, nadeesh tv wrote: >>> >>> Hi all, >>> >>> Please review a test bug fix >>> >>> TEST : *closed/javax/swing/JMenu/4213634/bug4213634.java * >>> BUG ID -*https://bugs.openjdk.java.net/browse/JDK-8017187* >>> >>> Please*move the test from closed repo tom open repo*. >>> >>> >>> The webrev is:http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>> add to open repo >>> >>> >>> http://cr.openjdk.java.net/~kshefov/8017187/webrev.diff/ - diff >>> with previous version of the closed test. >>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> >> > From alexandr.scherbatiy at oracle.com Thu Aug 6 08:29:05 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 06 Aug 2015 11:29:05 +0300 Subject: [9] Review request for 8081411 Add an API for painting an icon with a SynthContext Message-ID: <55C31AD1.9000909@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8081411 webrev: http://cr.openjdk.java.net/~alexsch/8081411/webrev.00 The following use case were considered: 1. An icon is taken from UIManager.getIcon(iconKey) and should be painted. Icon icon = UIManager.getIcon(iconKey); icon.paint(graphics, x, y) may not work for icons that are used by Synth L&F because the paint method with null synth context may just do nothing. 2. One icons is created based on existed icon. Foe example, creating a centered icon: ---------------------------- Icon centeredIcon = new SynthIcon() { private final SynthIcon synthIcon = (SynthIcon)icon; public void paintIcon(SynthContext sc, Graphics grphcs, int x, int y, int w, int h) { try { int dw = SynthIcon.getIconWidth(synthIcon, sc); int dh = SynthIcon.getIconHeight(synthIcon, sc); int dx = width - dw; int dy = height - dh; SynthIcon.paintIcon(synthIcon, sc, grphcs, x + dx/2, y + dy/2, dw + 2, dh + 2); } catch (Throwable t) { try { synthIcon.paintIcon(sc, grphcs, x, y, w, h); } catch (Throwable th) {} } } public int getIconWidth(SynthContext sc) { return width; } public int getIconHeight(SynthContext sc) { return height; } }; ---------------------------- Overriding just paintIcon(Component c, Graphics g, int x, int y) leads to the same issue. The icon may not be drawn in this case. 3. Replace an icon in UIManager to a custom icon which can use a synth context for painting: UIManager.putIcon(iconKey, new CustomIcon()) The case 1 requires that only the following static methods were public: SynthIcon.paintIcon(context, graphics, x, y, w, h) SynthIcon.getIconwidth(context) SynthIcon.getIconHeight(context) The cases 2 and 3 need to work with SyntIcon class. The proposed fix moves the paintIcon/getIconwidth/getIconHeight methods to the public SynthGraphicsUtils class and make the SynthIcon class public by moving it to the javax.swing.plaf.synth package. Thanks, Alexandr. From alexandr.scherbatiy at oracle.com Thu Aug 6 09:39:06 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 06 Aug 2015 12:39:06 +0300 Subject: Public API for internal Swing classes. In-Reply-To: <55B6244C.8040002@oracle.com> References: <55B6244C.8040002@oracle.com> Message-ID: <55C32B3A.80004@oracle.com> Some updates: - Just forgot to mention that it is better to provide not only information about used internal API but also simple use cases where it shown in which way the internal API us used and which task it is intended to solve. - It is better to use jdeps from JDK 9 where it is more up-to-date than in JDK 8, although the jdeps description is listed on Java SE 8 page: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.html - The updated list of known requests is: JDK-8133039 Provide public API to sun.swing.UIAction#isEnabled(Object) https://bugs.openjdk.java.net/browse/JDK-8133039 JDK-8081411 Add an API for painting an icon with a SynthContext https://bugs.openjdk.java.net/browse/JDK-8081411 JDK-6274842 RFE: Provide a means for a custom look and feel to use desktop font antialiasing settings. https://bugs.openjdk.java.net/browse/JDK-6274842 JDK-8132119 Provide public API for text related methods in SwingUtilities2 https://bugs.openjdk.java.net/browse/JDK-8132119 JDK-8132120 Provide public API for screen menu bar support on MacOS https://bugs.openjdk.java.net/browse/JDK-8132120 JDK-6274842 RFE: Provide a means for a custom look and feel to use desktop font antialiasing settings. https://bugs.openjdk.java.net/browse/JDK-6274842 Thanks, Alexandr. On 7/27/2015 3:30 PM, Alexander Scherbatiy wrote: > > According to the JEP 200: The Modular JDK (see > http://openjdk.java.net/jeps/200) > we expect that the standard Java SE modules will not export any > internal packages. > > It means that classes from internal packages (like sun.swing) will not > be accessible. > > For example: > sun.swing.FilePane > sun.swing.SwingUtilities2 > sun.swing.sun.swing.plaf.synth.SynthIcon > and others. > > > Please, let us known if you are using the internal Swing API and it is > not possible to replace it by public API. > > There are some known requests: > > JDK-8132119 Provide public API for text related methods in > SwingUtilities2 > https://bugs.openjdk.java.net/browse/JDK-8132119 > > JDK-8132120 Provide public API for screen menu bar support on MacOS > https://bugs.openjdk.java.net/browse/JDK-8132120 > > JDK-6274842 RFE: Provide a means for a custom look and feel to use > desktop font antialiasing settings. > https://bugs.openjdk.java.net/browse/JDK-6274842 > > > If you don't know if you use these types (because you use 3rd party jars) > you can use the JDK 8 "jdeps" tool to find such dependencies :- > > ~/jdk1.8/bin/jdeps > Usage: jdeps > where can be a pathname to a .class file, a directory, a JAR > file, or a fully-qualified class name > > Thanks, > Alexandr. > From nadeesh.tv at oracle.com Thu Aug 6 14:43:58 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Thu, 06 Aug 2015 20:13:58 +0530 Subject: [RFR JDK-8017187] [TEST BUG] [macosx] After click "test", the case failed automatically with thrown exception in the log since jdk8b75 In-Reply-To: <55C22D04.7000405@oracle.com> References: <55B28053.4000101@oracle.com> <55B8A606.3030302@oracle.com> <55C21843.6020806@oracle.com> <55C22D04.7000405@oracle.com> Message-ID: <55C372AE.1060701@oracle.com> Hi, Please review the updated webrev links closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ Thanks and Regards, Nadeesh TV On 8/5/2015 9:04 PM, Alexander Scherbatiy wrote: > On 8/5/2015 5:05 PM, nadeesh tv wrote: >> HI all, >> Please review the updated webrev links >> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ > - the patch does not contain the html file as it expected but it > still is shown on the provided open link. It seems that the index.html > file has not been updated. > - the swing calls like "!menu.isSelected()" should be invoked on EDT. > > Thanks, > Alexandr. >> Thanks and Regards, >> Nadeesh TV >> >> On 7/29/2015 3:38 PM, Alexander Scherbatiy wrote: >>> >>> - It looks like the html file has been used only because the test >>> was manual and it can be simply removed. >>> - Is it possible to use a robot to press keys rather than put >>> KeyEvents directly to the SystemEventQueue? >>> >>> Thanks, >>> Alexandr. >>> >>> >>> On 7/24/2015 9:13 PM, nadeesh tv wrote: >>>> >>>> Hi all, >>>> >>>> Please review a test bug fix >>>> >>>> TEST : *closed/javax/swing/JMenu/4213634/bug4213634.java * >>>> BUG ID -*https://bugs.openjdk.java.net/browse/JDK-8017187* >>>> >>>> Please*move the test from closed repo tom open repo*. >>>> >>>> >>>> The webrev is:http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>>> add to open repo >>>> >>>> >>>> http://cr.openjdk.java.net/~kshefov/8017187/webrev.diff/ - diff >>>> with previous version of the closed test. >>>> >>>> -- >>>> Thanks and Regards, >>>> Nadeesh TV >>>> >>> >> > -- Thanks and Regards, Nadeesh TV From semyon.sadetsky at oracle.com Thu Aug 6 16:46:36 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 06 Aug 2015 19:46:36 +0300 Subject: [9] Review Request for 8133108: [PIT] Container size is wrong in JEditorPane Message-ID: <55C38F6C.9020704@oracle.com> Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8133108 webrev: http://cr.openjdk.java.net/~ssadetsky/8133108/webrev.01/ This a regression from JDK-8132136 after which the GlyphView does not wrap text for the minimum width calculation by default anymore. InlineView as GlyphView descendant should take care about setting the right resize weight now. In the solution getResizeWeight() is overridden in InlineView to return the right weight according to the nowrap field. Test suite is added to check the right text positioning for wrap/nowrap styles in the JTextPane document. --Semyon From alexandr.scherbatiy at oracle.com Mon Aug 10 13:45:00 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 10 Aug 2015 16:45:00 +0300 Subject: [RFR JDK-8017187] [TEST BUG] [macosx] After click "test", the case failed automatically with thrown exception in the log since jdk8b75 In-Reply-To: <55C372AE.1060701@oracle.com> References: <55B28053.4000101@oracle.com> <55B8A606.3030302@oracle.com> <55C21843.6020806@oracle.com> <55C22D04.7000405@oracle.com> <55C372AE.1060701@oracle.com> Message-ID: <55C8AADC.1010601@oracle.com> On 8/6/2015 5:43 PM, nadeesh tv wrote: > Hi, > Please review the updated webrev links > closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ > open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ Could you recreate the webrev and put it with index.html file? Thanks, Alexandr. > > Thanks and Regards, > Nadeesh TV > On 8/5/2015 9:04 PM, Alexander Scherbatiy wrote: >> On 8/5/2015 5:05 PM, nadeesh tv wrote: >>> HI all, >>> Please review the updated webrev links >>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >> - the patch does not contain the html file as it expected but it >> still is shown on the provided open link. It seems that the >> index.html file has not been updated. >> - the swing calls like "!menu.isSelected()" should be invoked on >> EDT. >> >> Thanks, >> Alexandr. >>> Thanks and Regards, >>> Nadeesh TV >>> >>> On 7/29/2015 3:38 PM, Alexander Scherbatiy wrote: >>>> >>>> - It looks like the html file has been used only because the test >>>> was manual and it can be simply removed. >>>> - Is it possible to use a robot to press keys rather than put >>>> KeyEvents directly to the SystemEventQueue? >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> On 7/24/2015 9:13 PM, nadeesh tv wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Please review a test bug fix >>>>> >>>>> TEST : *closed/javax/swing/JMenu/4213634/bug4213634.java * >>>>> BUG ID -*https://bugs.openjdk.java.net/browse/JDK-8017187* >>>>> >>>>> Please*move the test from closed repo tom open repo*. >>>>> >>>>> >>>>> The webrev >>>>> is:http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ add to >>>>> open repo >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~kshefov/8017187/webrev.diff/ - diff >>>>> with previous version of the closed test. >>>>> >>>>> -- >>>>> Thanks and Regards, >>>>> Nadeesh TV >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Mon Aug 10 14:39:19 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 10 Aug 2015 17:39:19 +0300 Subject: [9] Review Request for 8133108: [PIT] Container size is wrong in JEditorPane In-Reply-To: <55C38F6C.9020704@oracle.com> References: <55C38F6C.9020704@oracle.com> Message-ID: <55C8B797.4000500@oracle.com> On 8/6/2015 7:46 PM, Semyon Sadetsky wrote: > Hello, > > Please review fix for JDK9: > bug: https://bugs.openjdk.java.net/browse/JDK-8133108 > webrev: http://cr.openjdk.java.net/~ssadetsky/8133108/webrev.01/ Could you look at the test javax/swing/JTextPane/JTextPaneDocumentAlignment.java It fails on my system with the suggested fix. Thanks, Alexandr. > > This a regression from JDK-8132136 after which the GlyphView does not > wrap text for the minimum width calculation by default anymore. > InlineView as GlyphView descendant should take care about setting the > right resize weight now. In the solution getResizeWeight() is > overridden in InlineView to return the right weight according to the > nowrap field. > Test suite is added to check the right text positioning for > wrap/nowrap styles in the JTextPane document. > > --Semyon From pooja.chopra at oracle.com Tue Aug 11 06:36:55 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Tue, 11 Aug 2015 12:06:55 +0530 Subject: < Swing Dev> [9] Review Request: JDK-8081764 [TEST_BUG] Test javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Solaris Sparcv9 and Linux but passes on MacOSX In-Reply-To: <55B8AD7F.6060102@oracle.com> References: <5575670A.6060802@oracle.com> <5575678E.2080803@oracle.com> <55769992.6090505@oracle.com> <55794C6C.2030807@oracle.com> <55B87A22.3020207@oracle.com> <55B8AD7F.6060102@oracle.com> Message-ID: <55C99807.3020908@oracle.com> Hi All, Please review below fix as I need one more approval for this . Regards, Pooja On 7/29/2015 4:09 PM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/29/2015 10:00 AM, pooja chopra wrote: >> Hi , >> As default look and feel in mac is aqua only so there is no need of >> setting system look and feel explicitly. >> >> Please review updated webrev link below:- >> >> 8081764 [TEST_BUG] Test >> javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Solaris >> Sparcv9 and Linux but passes on MacOSX >> Test bug fix. >> https://bugs.openjdk.java.net/browse/JDK-8081764 >> The webrev is : http://cr.openjdk.java.net/~pchopra/8081764/webrev.01/ >> >> Regards, >> Pooja >> >> On 6/11/2015 2:23 PM, pooja chopra wrote: >>> Hi Andrew , >>> The test passes with GTKLookAndFeel on Solaris but with out >>> GTKLookAndFeel test fails with same error as mentioned in the bug . >>> I had explicitly set the look and feel as system look and feel as >>> test was to be run for Mac only and this test was placed in >>> plaf/aqua and it is comparing screenshots so I thought in other look >>> and feel there can be a possibility that this matching fails. Please >>> let me know if some changes are required . >>> Regards, >>> Pooja >>> On 6/9/2015 1:15 PM, Andrew Brygin wrote: >>>> Hello Pooja, >>>> >>>> In general I tend to agree with idea to limit the scope of the >>>> test by macosx only. >>>> >>>> However, could you please clarify following questions: >>>> a) the test failure on linux/solaris: doesn't it indicate a similar >>>> problem with gtk laf, does it? >>>> b) what is purpose of the explicit LaF setup (lines 68 - 69)? >>>> >>>> Thanks, >>>> Andrew >>>> >>>> On 6/8/2015 12:59 PM, pooja chopra wrote: >>>>> Hi All, >>>>> Correcting the webrev link below . Please review below fix . >>>>> Regards, >>>>> Pooja >>>>> On 6/8/2015 3:27 PM, pooja chopra wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a fix for issue :- >>>>>> 8081764 [TEST_BUG] Test >>>>>> javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on >>>>>> Solaris Sparcv9 and Linux but passes on MacOSX >>>>>> Test bug fix. >>>>>> https://bugs.openjdk.java.net/browse/JDK-8081764 >>>>>> The webrev is : >>>>>> http://cr.openjdk.java.net/~pchopra/8081764/webrev.00 >>>>>> >>>>>> Regards, >>>>>> Pooja >>>>>> >>>>> >>>> >>> >> > From alexander.zvegintsev at oracle.com Tue Aug 11 08:38:06 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 11 Aug 2015 11:38:06 +0300 Subject: < Swing Dev> [9] Review Request: JDK-8081764 [TEST_BUG] Test javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Solaris Sparcv9 and Linux but passes on MacOSX In-Reply-To: <55B8AD7F.6060102@oracle.com> References: <5575670A.6060802@oracle.com> <5575678E.2080803@oracle.com> <55769992.6090505@oracle.com> <55794C6C.2030807@oracle.com> <55B87A22.3020207@oracle.com> <55B8AD7F.6060102@oracle.com> Message-ID: <55C9B46E.9080203@oracle.com> +1 Thanks, Alexander. On 07/29/2015 01:39 PM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 7/29/2015 10:00 AM, pooja chopra wrote: >> Hi , >> As default look and feel in mac is aqua only so there is no need of >> setting system look and feel explicitly. >> >> Please review updated webrev link below:- >> >> 8081764 [TEST_BUG] Test >> javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Solaris >> Sparcv9 and Linux but passes on MacOSX >> Test bug fix. >> https://bugs.openjdk.java.net/browse/JDK-8081764 >> The webrev is : http://cr.openjdk.java.net/~pchopra/8081764/webrev.01/ >> >> Regards, >> Pooja >> >> On 6/11/2015 2:23 PM, pooja chopra wrote: >>> Hi Andrew , >>> The test passes with GTKLookAndFeel on Solaris but with out >>> GTKLookAndFeel test fails with same error as mentioned in the bug . >>> I had explicitly set the look and feel as system look and feel as >>> test was to be run for Mac only and this test was placed in >>> plaf/aqua and it is comparing screenshots so I thought in other look >>> and feel there can be a possibility that this matching fails. Please >>> let me know if some changes are required . >>> Regards, >>> Pooja >>> On 6/9/2015 1:15 PM, Andrew Brygin wrote: >>>> Hello Pooja, >>>> >>>> In general I tend to agree with idea to limit the scope of the >>>> test by macosx only. >>>> >>>> However, could you please clarify following questions: >>>> a) the test failure on linux/solaris: doesn't it indicate a similar >>>> problem with gtk laf, does it? >>>> b) what is purpose of the explicit LaF setup (lines 68 - 69)? >>>> >>>> Thanks, >>>> Andrew >>>> >>>> On 6/8/2015 12:59 PM, pooja chopra wrote: >>>>> Hi All, >>>>> Correcting the webrev link below . Please review below fix . >>>>> Regards, >>>>> Pooja >>>>> On 6/8/2015 3:27 PM, pooja chopra wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a fix for issue :- >>>>>> 8081764 [TEST_BUG] Test >>>>>> javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on >>>>>> Solaris Sparcv9 and Linux but passes on MacOSX >>>>>> Test bug fix. >>>>>> https://bugs.openjdk.java.net/browse/JDK-8081764 >>>>>> The webrev is : >>>>>> http://cr.openjdk.java.net/~pchopra/8081764/webrev.00 >>>>>> >>>>>> Regards, >>>>>> Pooja >>>>>> >>>>> >>>> >>> >> > From nadeesh.tv at oracle.com Tue Aug 11 11:24:38 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 11 Aug 2015 16:54:38 +0530 Subject: [RFR JDK-8017187] [TEST BUG] [macosx] After click "test", the case failed automatically with thrown exception in the log since jdk8b75 In-Reply-To: <55C372AE.1060701@oracle.com> References: <55B28053.4000101@oracle.com> <55B8A606.3030302@oracle.com> <55C21843.6020806@oracle.com> <55C22D04.7000405@oracle.com> <55C372AE.1060701@oracle.com> Message-ID: <55C9DB76.4060905@oracle.com> Hi, Please review the updated webrev links closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ Thanks and Regards, Nadeesh TV On 8/6/2015 8:13 PM, nadeesh tv wrote: > Hi, > Please review the updated webrev links > closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ > open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ > > Thanks and Regards, > Nadeesh TV > On 8/5/2015 9:04 PM, Alexander Scherbatiy wrote: >> On 8/5/2015 5:05 PM, nadeesh tv wrote: >>> HI all, >>> Please review the updated webrev links >>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >> - the patch does not contain the html file as it expected but it >> still is shown on the provided open link. It seems that the >> index.html file has not been updated. >> - the swing calls like "!menu.isSelected()" should be invoked on >> EDT. >> >> Thanks, >> Alexandr. >>> Thanks and Regards, >>> Nadeesh TV >>> >>> On 7/29/2015 3:38 PM, Alexander Scherbatiy wrote: >>>> >>>> - It looks like the html file has been used only because the test >>>> was manual and it can be simply removed. >>>> - Is it possible to use a robot to press keys rather than put >>>> KeyEvents directly to the SystemEventQueue? >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> On 7/24/2015 9:13 PM, nadeesh tv wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Please review a test bug fix >>>>> >>>>> TEST : *closed/javax/swing/JMenu/4213634/bug4213634.java * >>>>> BUG ID -*https://bugs.openjdk.java.net/browse/JDK-8017187* >>>>> >>>>> Please*move the test from closed repo tom open repo*. >>>>> >>>>> >>>>> The webrev >>>>> is:http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ add to >>>>> open repo >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~kshefov/8017187/webrev.diff/ - diff >>>>> with previous version of the closed test. >>>>> >>>>> -- >>>>> Thanks and Regards, >>>>> Nadeesh TV >>>>> >>>> >>> >> > -- Thanks and Regards, Nadeesh TV From alexandr.scherbatiy at oracle.com Tue Aug 11 12:26:59 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 11 Aug 2015 15:26:59 +0300 Subject: [RFR JDK-8017187] [TEST BUG] [macosx] After click "test", the case failed automatically with thrown exception in the log since jdk8b75 In-Reply-To: <55C9DB76.4060905@oracle.com> References: <55B28053.4000101@oracle.com> <55B8A606.3030302@oracle.com> <55C21843.6020806@oracle.com> <55C22D04.7000405@oracle.com> <55C372AE.1060701@oracle.com> <55C9DB76.4060905@oracle.com> Message-ID: <55C9EA13.70709@oracle.com> On 8/11/2015 2:24 PM, nadeesh tv wrote: > > Hi, > > Please review the updated webrev links > closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ > open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ Some comments: - copyright should be added to the test - it needs to use SwingUtilities.invokeAndWait() in the tests instead of invokeLater() because JTreg can just finish the test and report it as passed before EDT can even start - could you put each new webrev in a separate directory so it would be possible to look at the previous versions Thanks, Alexandr. > Thanks and Regards, > Nadeesh TV > > > On 8/6/2015 8:13 PM, nadeesh tv wrote: >> Hi, >> Please review the updated webrev links >> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >> >> Thanks and Regards, >> Nadeesh TV >> On 8/5/2015 9:04 PM, Alexander Scherbatiy wrote: >>> On 8/5/2015 5:05 PM, nadeesh tv wrote: >>>> HI all, >>>> Please review the updated webrev links >>>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >>> - the patch does not contain the html file as it expected but it >>> still is shown on the provided open link. It seems that the >>> index.html file has not been updated. >>> - the swing calls like "!menu.isSelected()" should be invoked on >>> EDT. >>> >>> Thanks, >>> Alexandr. >>>> Thanks and Regards, >>>> Nadeesh TV >>>> >>>> On 7/29/2015 3:38 PM, Alexander Scherbatiy wrote: >>>>> >>>>> - It looks like the html file has been used only because the test >>>>> was manual and it can be simply removed. >>>>> - Is it possible to use a robot to press keys rather than put >>>>> KeyEvents directly to the SystemEventQueue? >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>> On 7/24/2015 9:13 PM, nadeesh tv wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Please review a test bug fix >>>>>> >>>>>> TEST : *closed/javax/swing/JMenu/4213634/bug4213634.java * >>>>>> BUG ID -*https://bugs.openjdk.java.net/browse/JDK-8017187* >>>>>> >>>>>> Please*move the test from closed repo tom open repo*. >>>>>> >>>>>> >>>>>> The webrev >>>>>> is:http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ add to >>>>>> open repo >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~kshefov/8017187/webrev.diff/ - diff >>>>>> with previous version of the closed test. >>>>>> >>>>>> -- >>>>>> Thanks and Regards, >>>>>> Nadeesh TV >>>>>> >>>>> >>>> >>> >> > From alexander.v.stepanov at oracle.com Tue Aug 11 15:45:28 2015 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Tue, 11 Aug 2015 18:45:28 +0300 Subject: RFR JDK-8133134: docs: replace tags (obsolete in html5) for java.desktop Message-ID: <55CA1898.20107@oracle.com> Hello, Could you please review the following fix: http://cr.openjdk.java.net/~avstepan/8133134/webrev.00 for https://bugs.openjdk.java.net/browse/JDK-8133134 Deprecated tags replaced with {@code}. Thanks, Alexander From nadeesh.tv at oracle.com Wed Aug 12 07:46:40 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 12 Aug 2015 13:16:40 +0530 Subject: [RFR JDK-8017187] [TEST BUG] [macosx] After click "test", the case failed automatically with thrown exception in the log since jdk8b75 In-Reply-To: <55C9DB76.4060905@oracle.com> References: <55B28053.4000101@oracle.com> <55B8A606.3030302@oracle.com> <55C21843.6020806@oracle.com> <55C22D04.7000405@oracle.com> <55C372AE.1060701@oracle.com> <55C9DB76.4060905@oracle.com> Message-ID: <55CAF9E0.30205@oracle.com> Hi, Please review the updated webrev links open- http://cr.openjdk.java.net/~sgupta/8017187/webrev.02/ closed- http://cr.openjdk.java.net/~sgupta/8017187/webrev.03/ Thanks and Regards, Nadeesh TV On 8/11/2015 4:54 PM, nadeesh tv wrote: > > Hi, > > Please review the updated webrev links > closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ > open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ > Thanks and Regards, > Nadeesh TV > > > On 8/6/2015 8:13 PM, nadeesh tv wrote: >> Hi, >> Please review the updated webrev links >> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >> >> Thanks and Regards, >> Nadeesh TV >> On 8/5/2015 9:04 PM, Alexander Scherbatiy wrote: >>> On 8/5/2015 5:05 PM, nadeesh tv wrote: >>>> HI all, >>>> Please review the updated webrev links >>>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >>> - the patch does not contain the html file as it expected but it >>> still is shown on the provided open link. It seems that the >>> index.html file has not been updated. >>> - the swing calls like "!menu.isSelected()" should be invoked on >>> EDT. >>> >>> Thanks, >>> Alexandr. >>>> Thanks and Regards, >>>> Nadeesh TV >>>> >>>> On 7/29/2015 3:38 PM, Alexander Scherbatiy wrote: >>>>> >>>>> - It looks like the html file has been used only because the test >>>>> was manual and it can be simply removed. >>>>> - Is it possible to use a robot to press keys rather than put >>>>> KeyEvents directly to the SystemEventQueue? >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>> On 7/24/2015 9:13 PM, nadeesh tv wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Please review a test bug fix >>>>>> >>>>>> TEST : *closed/javax/swing/JMenu/4213634/bug4213634.java * >>>>>> BUG ID -*https://bugs.openjdk.java.net/browse/JDK-8017187* >>>>>> >>>>>> Please*move the test from closed repo tom open repo*. >>>>>> >>>>>> >>>>>> The webrev >>>>>> is:http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ add to >>>>>> open repo >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~kshefov/8017187/webrev.diff/ - diff >>>>>> with previous version of the closed test. >>>>>> >>>>>> -- >>>>>> Thanks and Regards, >>>>>> Nadeesh TV >>>>>> >>>>> >>>> >>> >> > -- Thanks and Regards, Nadeesh TV From alexandr.scherbatiy at oracle.com Wed Aug 12 08:00:23 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 12 Aug 2015 11:00:23 +0300 Subject: RFR JDK-8133134: docs: replace tags (obsolete in html5) for java.desktop In-Reply-To: <55CA1898.20107@oracle.com> References: <55CA1898.20107@oracle.com> Message-ID: <55CAFD17.3090603@oracle.com> The fix looks good to me. Thanks, Alexandr. On 8/11/2015 6:45 PM, Alexander Stepanov wrote: > Hello, > > Could you please review the following fix: > http://cr.openjdk.java.net/~avstepan/8133134/webrev.00 > for > https://bugs.openjdk.java.net/browse/JDK-8133134 > > Deprecated tags replaced with {@code}. > > Thanks, > Alexander > From alexandr.scherbatiy at oracle.com Wed Aug 12 08:03:00 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 12 Aug 2015 11:03:00 +0300 Subject: [RFR JDK-8017187] [TEST BUG] [macosx] After click "test", the case failed automatically with thrown exception in the log since jdk8b75 In-Reply-To: <55CAF9E0.30205@oracle.com> References: <55B28053.4000101@oracle.com> <55B8A606.3030302@oracle.com> <55C21843.6020806@oracle.com> <55C22D04.7000405@oracle.com> <55C372AE.1060701@oracle.com> <55C9DB76.4060905@oracle.com> <55CAF9E0.30205@oracle.com> Message-ID: <55CAFDB4.5030201@oracle.com> The fix looks good to me. Thanks, Alexandr. On 8/12/2015 10:46 AM, nadeesh tv wrote: > > Hi, > > Please review the updated webrev links > open- http://cr.openjdk.java.net/~sgupta/8017187/webrev.02/ > closed- http://cr.openjdk.java.net/~sgupta/8017187/webrev.03/ > Thanks and Regards, > Nadeesh TV > On 8/11/2015 4:54 PM, nadeesh tv wrote: >> >> Hi, >> >> Please review the updated webrev links >> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >> Thanks and Regards, >> Nadeesh TV >> >> >> On 8/6/2015 8:13 PM, nadeesh tv wrote: >>> Hi, >>> Please review the updated webrev links >>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>> >>> Thanks and Regards, >>> Nadeesh TV >>> On 8/5/2015 9:04 PM, Alexander Scherbatiy wrote: >>>> On 8/5/2015 5:05 PM, nadeesh tv wrote: >>>>> HI all, >>>>> Please review the updated webrev links >>>>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>>>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >>>> - the patch does not contain the html file as it expected but >>>> it still is shown on the provided open link. It seems that the >>>> index.html file has not been updated. >>>> - the swing calls like "!menu.isSelected()" should be invoked >>>> on EDT. >>>> >>>> Thanks, >>>> Alexandr. >>>>> Thanks and Regards, >>>>> Nadeesh TV >>>>> >>>>> On 7/29/2015 3:38 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> - It looks like the html file has been used only because the >>>>>> test was manual and it can be simply removed. >>>>>> - Is it possible to use a robot to press keys rather than put >>>>>> KeyEvents directly to the SystemEventQueue? >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>>> On 7/24/2015 9:13 PM, nadeesh tv wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Please review a test bug fix >>>>>>> >>>>>>> TEST : *closed/javax/swing/JMenu/4213634/bug4213634.java * >>>>>>> BUG ID -*https://bugs.openjdk.java.net/browse/JDK-8017187* >>>>>>> >>>>>>> Please*move the test from closed repo tom open repo*. >>>>>>> >>>>>>> >>>>>>> The webrev >>>>>>> is:http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ add to >>>>>>> open repo >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~kshefov/8017187/webrev.diff/ - diff >>>>>>> with previous version of the closed test. >>>>>>> >>>>>>> -- >>>>>>> Thanks and Regards, >>>>>>> Nadeesh TV >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexander.v.stepanov at oracle.com Wed Aug 12 10:02:23 2015 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Wed, 12 Aug 2015 13:02:23 +0300 Subject: RFR JDK-8133134: docs: replace tags (obsolete in html5) for java.desktop In-Reply-To: <55CAFD17.3090603@oracle.com> References: <55CA1898.20107@oracle.com> <55CAFD17.3090603@oracle.com> Message-ID: <55CB19AF.6000803@oracle.com> Thanks! On 8/12/2015 11:00 AM, Alexander Scherbatiy wrote: > > > The fix looks good to me. > > Thanks, > Alexandr. > > On 8/11/2015 6:45 PM, Alexander Stepanov wrote: >> Hello, >> >> Could you please review the following fix: >> http://cr.openjdk.java.net/~avstepan/8133134/webrev.00 >> for >> https://bugs.openjdk.java.net/browse/JDK-8133134 >> >> Deprecated tags replaced with {@code}. >> >> Thanks, >> Alexander >> > From Sergey.Bylokhov at oracle.com Wed Aug 12 12:53:44 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 12 Aug 2015 15:53:44 +0300 Subject: [9] Review request for 8081411 Add an API for painting an icon with a SynthContext In-Reply-To: <55C31AD1.9000909@oracle.com> References: <55C31AD1.9000909@oracle.com> Message-ID: <55CB41D8.6050309@oracle.com> The fix looks fine to me. On 06.08.15 11:29, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8081411 > webrev: http://cr.openjdk.java.net/~alexsch/8081411/webrev.00 > > The following use case were considered: > > 1. An icon is taken from UIManager.getIcon(iconKey) and should be > painted. > Icon icon = UIManager.getIcon(iconKey); > > icon.paint(graphics, x, y) may not work for icons that are used by > Synth L&F because the paint method with null synth context may just do > nothing. > > 2. One icons is created based on existed icon. > > Foe example, creating a centered icon: > ---------------------------- > Icon centeredIcon = new SynthIcon() { > private final SynthIcon synthIcon = (SynthIcon)icon; > public void paintIcon(SynthContext sc, Graphics grphcs, int x, > int y, int w, int h) { > try { > int dw = SynthIcon.getIconWidth(synthIcon, sc); > int dh = SynthIcon.getIconHeight(synthIcon, sc); > int dx = width - dw; > int dy = height - dh; > SynthIcon.paintIcon(synthIcon, sc, grphcs, x + dx/2, y > + dy/2, dw + 2, dh + 2); > } catch (Throwable t) { > try { synthIcon.paintIcon(sc, grphcs, x, y, w, h); } > catch (Throwable th) {} > } > } > public int getIconWidth(SynthContext sc) { return width; } > public int getIconHeight(SynthContext sc) { return height; } > }; > ---------------------------- > > Overriding just paintIcon(Component c, Graphics g, int x, int y) > leads to the same issue. The icon may not be drawn in this case. > > 3. Replace an icon in UIManager to a custom icon which can use a synth > context for painting: > UIManager.putIcon(iconKey, new CustomIcon()) > > The case 1 requires that only the following static methods were public: > SynthIcon.paintIcon(context, graphics, x, y, w, h) > SynthIcon.getIconwidth(context) > SynthIcon.getIconHeight(context) > > The cases 2 and 3 need to work with SyntIcon class. > > The proposed fix moves the paintIcon/getIconwidth/getIconHeight > methods to the public SynthGraphicsUtils class > and make the SynthIcon class public by moving it to the > javax.swing.plaf.synth package. > > Thanks, > Alexandr. > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Aug 13 07:26:01 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 13 Aug 2015 10:26:01 +0300 Subject: [9-client] Review request for bug 7124238 : [TEST_BUG] Font in BasicHTML document is bigger than it should be In-Reply-To: <55CC283F.2090901@oracle.com> References: <55CC283F.2090901@oracle.com> Message-ID: <55CC4689.1070005@oracle.com> On 8/13/2015 8:16 AM, shilpi rastogi wrote: > Hi all, > > Please review a test bug fix > > TEST : closed/javax/swing/plaf/basic/BasicHTML/4960629/bug4960629.java > BUG ID - https://bugs.openjdk.java.net/browse/JDK-7124238 > > Pleasemove the test from closed repo to open repo. > > The webrev is: http://cr.openjdk.java.net/~sgupta/7124238/webrev.01 > add to open repo - The long lines should be split so they fit to a page - Exceptions should be re-thrown. In other case they are just printed but jtreg decides that a test is passed. 69 try { 70 createAndShowGUI(); 71 } catch (AWTException e) { 72 e.printStackTrace(); 73 } - The test methods can throw a general Exceptioninstead of several concrete ones. This usually makes a test more readable. It also allows to omit try/catch block for the the UIManager.setLookAndFeel() call. Thanks, Alexandr. > > http://cr.openjdk.java.net/~sgupta/7124238/webrev.00/ > - diff > with previous version of the closed test. > > Thanks, > Shilpi From shilpi.rastogi at oracle.com Thu Aug 13 05:16:47 2015 From: shilpi.rastogi at oracle.com (shilpi rastogi) Date: Thu, 13 Aug 2015 10:46:47 +0530 Subject: [9-client] Review request for bug 7124238 : [TEST_BUG] Font in BasicHTML document is bigger than it should be Message-ID: <55CC283F.2090901@oracle.com> Hi all, Please review a test bug fix TEST : closed/javax/swing/plaf/basic/BasicHTML/4960629/bug4960629.java BUG ID - https://bugs.openjdk.java.net/browse/JDK-7124238 Pleasemove the test from closed repo to open repo. The webrev is: http://cr.openjdk.java.net/~sgupta/7124238/webrev.01 add to open repo http://cr.openjdk.java.net/~sgupta/7124238/webrev.00/ - diff with previous version of the closed test. Thanks, Shilpi -------------- next part -------------- An HTML attachment was scrubbed... URL: From shilpi.rastogi at oracle.com Thu Aug 13 11:51:11 2015 From: shilpi.rastogi at oracle.com (shilpi rastogi) Date: Thu, 13 Aug 2015 17:21:11 +0530 Subject: [9-client] Review request for bug 7124238 : [TEST_BUG] Font in BasicHTML document is bigger than it should be In-Reply-To: <55CC4689.1070005@oracle.com> References: <55CC283F.2090901@oracle.com> <55CC4689.1070005@oracle.com> Message-ID: <55CC84AF.2000104@oracle.com> Hi All, Please review updated webrev http://cr.openjdk.java.net/~sgupta/7124238/webrev.03/ http://cr.openjdk.java.net/~sgupta/7124238/webrev.02/ Thanks, Shilpi On 8/13/2015 12:56 PM, Alexander Scherbatiy wrote: > On 8/13/2015 8:16 AM, shilpi rastogi wrote: >> Hi all, >> >> Please review a test bug fix >> >> TEST : closed/javax/swing/plaf/basic/BasicHTML/4960629/bug4960629.java >> BUG ID - https://bugs.openjdk.java.net/browse/JDK-7124238 >> >> Pleasemove the test from closed repo to open repo. >> >> The webrev is: http://cr.openjdk.java.net/~sgupta/7124238/webrev.01 >> add to open repo > > - The long lines should be split so they fit to a page > - Exceptions should be re-thrown. In other case they are just > printed but jtreg decides that a test is passed. > > 69 try { > 70 createAndShowGUI(); > 71 } catch (AWTException e) { > 72 e.printStackTrace(); > 73 } > > - The test methods can throw a general Exceptioninstead of several > concrete ones. This usually makes a test more readable. > It also allows to omit try/catch block for the the > UIManager.setLookAndFeel() call. > > Thanks, > Alexandr. >> >> http://cr.openjdk.java.net/~sgupta/7124238/webrev.00/ >> - diff >> with previous version of the closed test. >> >> Thanks, >> Shilpi > From alexandr.scherbatiy at oracle.com Thu Aug 13 12:07:15 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 13 Aug 2015 15:07:15 +0300 Subject: [9] Review request for 6302464 Allow programmatic enabling of subpixel anti-aliasing in Swing Message-ID: <55CC8873.7030202@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-6302464 webrev: http://cr.openjdk.java.net/~alexsch/6302464/webrev.00 Swing uses internal API to set antialiasing settings for L&Fs and components. SwingUtilities2.AATextInfo aaTextInfo = new SwingUtilities2.AATextInfo( RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB, 140); UIManager.getDefaults().put(SwingUtilities2.AA_TEXT_PROPERTY_KEY, aaTextInfo); // set aa hints globally component.putClientProperty(SwingUtilities2.AA_TEXT_PROPERTY_KEY, aaTextInfo); // set aa hints for a JComponent There are some ways to provide a public mechanism for antialiasing enabling in Swing: 1. Setting antialiasing rendering hints into UI defaults and component client properties: UIManager.getDefaults().put(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); component.putClientProperty(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); 2. Setting a map which contains antialiasing hints: Map aaHintsMap = new HashMap<>(); aaHintsMap.put(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); UIManager.getDefaults().put(AA_TEXT_PROPERTY_KEY, aaHintsMap); component.putClientProperty(AA_TEXT_PROPERTY_KEY, aaHintsMap); 3. Information about antialiasing hints can be stored in a public class AATextInfo aaTextInfo = new AATextInfo(RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB, 140); UIManager.getDefaults().put(AA_TEXT_PROPERTY_KEY, aaTextInfo); component.putClientProperty(AA_TEXT_PROPERTY_KEY, aaTextInfo); The proposed fix used the first approach. Thanks, Alexandr. From alexandr.scherbatiy at oracle.com Thu Aug 13 14:07:22 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 13 Aug 2015 17:07:22 +0300 Subject: [9-client] Review request for bug 7124238 : [TEST_BUG] Font in BasicHTML document is bigger than it should be In-Reply-To: <55CC84AF.2000104@oracle.com> References: <55CC283F.2090901@oracle.com> <55CC4689.1070005@oracle.com> <55CC84AF.2000104@oracle.com> Message-ID: <55CCA49A.3000103@oracle.com> On 8/13/2015 2:51 PM, shilpi rastogi wrote: > Hi All, > > Please review updated webrev > > http://cr.openjdk.java.net/~sgupta/7124238/webrev.03/ > http://cr.openjdk.java.net/~sgupta/7124238/webrev.02/ - I forgot to mention that the rule is to split line if it longer than 80 characters. Long lines are annoying for side-by-side views. IDEs usually allow to configure right margin settings in a editor for this purposes. - It is better to define that createAndShowGUI() method throws Exception. In this case the try/catch block for L&F setting is unnecessary. - SwingUtilities.invokeAndWait() does not throw AWTException so its declaration can be removed. Thanks, Alexandr. > > Thanks, > Shilpi > > > On 8/13/2015 12:56 PM, Alexander Scherbatiy wrote: >> On 8/13/2015 8:16 AM, shilpi rastogi wrote: >>> Hi all, >>> >>> Please review a test bug fix >>> >>> TEST : closed/javax/swing/plaf/basic/BasicHTML/4960629/bug4960629.java >>> BUG ID - https://bugs.openjdk.java.net/browse/JDK-7124238 >>> >>> Pleasemove the test from closed repo to open repo. >>> >>> The webrev is: http://cr.openjdk.java.net/~sgupta/7124238/webrev.01 >>> add to open repo >> >> - The long lines should be split so they fit to a page >> - Exceptions should be re-thrown. In other case they are just >> printed but jtreg decides that a test is passed. >> >> 69 try { >> 70 createAndShowGUI(); >> 71 } catch (AWTException e) { >> 72 e.printStackTrace(); >> 73 } >> >> - The test methods can throw a general Exceptioninstead of several >> concrete ones. This usually makes a test more readable. >> It also allows to omit try/catch block for the the >> UIManager.setLookAndFeel() call. >> >> Thanks, >> Alexandr. >>> >>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.00/ >>> - diff >>> with previous version of the closed test. >>> >>> Thanks, >>> Shilpi >> > From shilpi.rastogi at oracle.com Fri Aug 14 07:33:39 2015 From: shilpi.rastogi at oracle.com (shilpi rastogi) Date: Fri, 14 Aug 2015 13:03:39 +0530 Subject: [9-client] Review request for bug 7124238 : [TEST_BUG] Font in BasicHTML document is bigger than it should be In-Reply-To: <55CCA49A.3000103@oracle.com> References: <55CC283F.2090901@oracle.com> <55CC4689.1070005@oracle.com> <55CC84AF.2000104@oracle.com> <55CCA49A.3000103@oracle.com> Message-ID: <55CD99D3.4060907@oracle.com> Hi All, Thanks Alexander for comments! I tried to incorporate all changes suggested by you. Please have a look http://cr.openjdk.java.net/~sgupta/7124238/webrev.05/ http://cr.openjdk.java.net/~sgupta/7124238/webrev.04/ Thanks Shilpi On 8/13/2015 7:37 PM, Alexander Scherbatiy wrote: > On 8/13/2015 2:51 PM, shilpi rastogi wrote: >> Hi All, >> >> Please review updated webrev >> >> http://cr.openjdk.java.net/~sgupta/7124238/webrev.03/ >> http://cr.openjdk.java.net/~sgupta/7124238/webrev.02/ > > - I forgot to mention that the rule is to split line if it longer > than 80 characters. Long lines are annoying for side-by-side views. > IDEs usually allow to configure right margin settings in a editor > for this purposes. > - It is better to define that createAndShowGUI() method throws > Exception. In this case the try/catch block for L&F setting is > unnecessary. > - SwingUtilities.invokeAndWait() does not throw AWTException so its > declaration can be removed. > > Thanks, > Alexandr. > > >> >> Thanks, >> Shilpi >> >> >> On 8/13/2015 12:56 PM, Alexander Scherbatiy wrote: >>> On 8/13/2015 8:16 AM, shilpi rastogi wrote: >>>> Hi all, >>>> >>>> Please review a test bug fix >>>> >>>> TEST : closed/javax/swing/plaf/basic/BasicHTML/4960629/bug4960629.java >>>> BUG ID - https://bugs.openjdk.java.net/browse/JDK-7124238 >>>> >>>> Pleasemove the test from closed repo to open repo. >>>> >>>> The webrev is: http://cr.openjdk.java.net/~sgupta/7124238/webrev.01 >>>> add to open repo >>> >>> - The long lines should be split so they fit to a page >>> - Exceptions should be re-thrown. In other case they are just >>> printed but jtreg decides that a test is passed. >>> >>> 69 try { >>> 70 createAndShowGUI(); >>> 71 } catch (AWTException e) { >>> 72 e.printStackTrace(); >>> 73 } >>> >>> - The test methods can throw a general Exceptioninstead of >>> several concrete ones. This usually makes a test more readable. >>> It also allows to omit try/catch block for the the >>> UIManager.setLookAndFeel() call. >>> >>> Thanks, >>> Alexandr. >>>> >>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.00/ >>>> - diff >>>> with previous version of the closed test. >>>> >>>> Thanks, >>>> Shilpi >>> >> > From alexandr.scherbatiy at oracle.com Fri Aug 14 07:53:41 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 14 Aug 2015 10:53:41 +0300 Subject: [9-client] Review request for bug 7124238 : [TEST_BUG] Font in BasicHTML document is bigger than it should be In-Reply-To: <55CD99D3.4060907@oracle.com> References: <55CC283F.2090901@oracle.com> <55CC4689.1070005@oracle.com> <55CC84AF.2000104@oracle.com> <55CCA49A.3000103@oracle.com> <55CD99D3.4060907@oracle.com> Message-ID: <55CD9E85.2070909@oracle.com> The fix looks good to me. Thanks, Alexandr. On 8/14/2015 10:33 AM, shilpi rastogi wrote: > Hi All, > > Thanks Alexander for comments! > > I tried to incorporate all changes suggested by you. > > Please have a look > > http://cr.openjdk.java.net/~sgupta/7124238/webrev.05/ > http://cr.openjdk.java.net/~sgupta/7124238/webrev.04/ > > > Thanks > Shilpi > > On 8/13/2015 7:37 PM, Alexander Scherbatiy wrote: >> On 8/13/2015 2:51 PM, shilpi rastogi wrote: >>> Hi All, >>> >>> Please review updated webrev >>> >>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.03/ >>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.02/ >> >> - I forgot to mention that the rule is to split line if it longer >> than 80 characters. Long lines are annoying for side-by-side views. >> IDEs usually allow to configure right margin settings in a editor >> for this purposes. >> - It is better to define that createAndShowGUI() method throws >> Exception. In this case the try/catch block for L&F setting is >> unnecessary. >> - SwingUtilities.invokeAndWait() does not throw AWTException so its >> declaration can be removed. >> >> Thanks, >> Alexandr. >> >> >>> >>> Thanks, >>> Shilpi >>> >>> >>> On 8/13/2015 12:56 PM, Alexander Scherbatiy wrote: >>>> On 8/13/2015 8:16 AM, shilpi rastogi wrote: >>>>> Hi all, >>>>> >>>>> Please review a test bug fix >>>>> >>>>> TEST : >>>>> closed/javax/swing/plaf/basic/BasicHTML/4960629/bug4960629.java >>>>> BUG ID - https://bugs.openjdk.java.net/browse/JDK-7124238 >>>>> >>>>> Pleasemove the test from closed repo to open repo. >>>>> >>>>> The webrev is: >>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.01 add to open repo >>>> >>>> - The long lines should be split so they fit to a page >>>> - Exceptions should be re-thrown. In other case they are just >>>> printed but jtreg decides that a test is passed. >>>> >>>> 69 try { >>>> 70 createAndShowGUI(); >>>> 71 } catch (AWTException e) { >>>> 72 e.printStackTrace(); >>>> 73 } >>>> >>>> - The test methods can throw a general Exceptioninstead of >>>> several concrete ones. This usually makes a test more readable. >>>> It also allows to omit try/catch block for the the >>>> UIManager.setLookAndFeel() call. >>>> >>>> Thanks, >>>> Alexandr. >>>>> >>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.00/ >>>>> - >>>>> diff with previous version of the closed test. >>>>> >>>>> Thanks, >>>>> Shilpi >>>> >>> >> > From nadeesh.tv at oracle.com Mon Aug 17 11:05:17 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Mon, 17 Aug 2015 16:35:17 +0530 Subject: [RFR JDK-8017187] [TEST BUG] [macosx] After click "test", the case failed automatically with thrown exception in the log since jdk8b75 In-Reply-To: <55CAFDB4.5030201@oracle.com> References: <55B28053.4000101@oracle.com> <55B8A606.3030302@oracle.com> <55C21843.6020806@oracle.com> <55C22D04.7000405@oracle.com> <55C372AE.1060701@oracle.com> <55C9DB76.4060905@oracle.com> <55CAF9E0.30205@oracle.com> <55CAFDB4.5030201@oracle.com> Message-ID: <55D1BFED.8010601@oracle.com> Hi all, Gentle reminder Regards, Nadeesh On 8/12/2015 1:33 PM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 8/12/2015 10:46 AM, nadeesh tv wrote: >> >> Hi, >> >> Please review the updated webrev links >> open- http://cr.openjdk.java.net/~sgupta/8017187/webrev.02/ >> closed- http://cr.openjdk.java.net/~sgupta/8017187/webrev.03/ >> Thanks and Regards, >> Nadeesh TV >> On 8/11/2015 4:54 PM, nadeesh tv wrote: >>> >>> Hi, >>> >>> Please review the updated webrev links >>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>> Thanks and Regards, >>> Nadeesh TV >>> >>> >>> On 8/6/2015 8:13 PM, nadeesh tv wrote: >>>> Hi, >>>> Please review the updated webrev links >>>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >>>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>>> >>>> Thanks and Regards, >>>> Nadeesh TV >>>> On 8/5/2015 9:04 PM, Alexander Scherbatiy wrote: >>>>> On 8/5/2015 5:05 PM, nadeesh tv wrote: >>>>>> HI all, >>>>>> Please review the updated webrev links >>>>>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>>>>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >>>>> - the patch does not contain the html file as it expected but >>>>> it still is shown on the provided open link. It seems that the >>>>> index.html file has not been updated. >>>>> - the swing calls like "!menu.isSelected()" should be invoked >>>>> on EDT. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> Thanks and Regards, >>>>>> Nadeesh TV >>>>>> >>>>>> On 7/29/2015 3:38 PM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> - It looks like the html file has been used only because the >>>>>>> test was manual and it can be simply removed. >>>>>>> - Is it possible to use a robot to press keys rather than put >>>>>>> KeyEvents directly to the SystemEventQueue? >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>>> On 7/24/2015 9:13 PM, nadeesh tv wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review a test bug fix >>>>>>>> >>>>>>>> TEST : *closed/javax/swing/JMenu/4213634/bug4213634.java * >>>>>>>> BUG ID -*https://bugs.openjdk.java.net/browse/JDK-8017187* >>>>>>>> >>>>>>>> Please*move the test from closed repo tom open repo*. >>>>>>>> >>>>>>>> >>>>>>>> The webrev >>>>>>>> is:http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ add to >>>>>>>> open repo >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~kshefov/8017187/webrev.diff/ - diff >>>>>>>> with previous version of the closed test. >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks and Regards, >>>>>>>> Nadeesh TV >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Thanks and Regards, Nadeesh TV From Sergey.Bylokhov at oracle.com Tue Aug 18 13:39:25 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 18 Aug 2015 16:39:25 +0300 Subject: [RFR JDK-8017187] [TEST BUG] [macosx] After click "test", the case failed automatically with thrown exception in the log since jdk8b75 In-Reply-To: <55D1BFED.8010601@oracle.com> References: <55B28053.4000101@oracle.com> <55B8A606.3030302@oracle.com> <55C21843.6020806@oracle.com> <55C22D04.7000405@oracle.com> <55C372AE.1060701@oracle.com> <55C9DB76.4060905@oracle.com> <55CAF9E0.30205@oracle.com> <55CAFDB4.5030201@oracle.com> <55D1BFED.8010601@oracle.com> Message-ID: <55D3358D.403@oracle.com> Looks fine. On 17.08.15 14:05, nadeesh tv wrote: > Hi all, > Gentle reminder > Regards, > Nadeesh > On 8/12/2015 1:33 PM, Alexander Scherbatiy wrote: >> >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 8/12/2015 10:46 AM, nadeesh tv wrote: >>> >>> Hi, >>> >>> Please review the updated webrev links >>> open- http://cr.openjdk.java.net/~sgupta/8017187/webrev.02/ >>> closed- http://cr.openjdk.java.net/~sgupta/8017187/webrev.03/ >>> Thanks and Regards, >>> Nadeesh TV >>> On 8/11/2015 4:54 PM, nadeesh tv wrote: >>>> >>>> Hi, >>>> >>>> Please review the updated webrev links >>>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >>>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>>> Thanks and Regards, >>>> Nadeesh TV >>>> >>>> >>>> On 8/6/2015 8:13 PM, nadeesh tv wrote: >>>>> Hi, >>>>> Please review the updated webrev links >>>>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >>>>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>>>> >>>>> Thanks and Regards, >>>>> Nadeesh TV >>>>> On 8/5/2015 9:04 PM, Alexander Scherbatiy wrote: >>>>>> On 8/5/2015 5:05 PM, nadeesh tv wrote: >>>>>>> HI all, >>>>>>> Please review the updated webrev links >>>>>>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>>>>>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >>>>>> - the patch does not contain the html file as it expected but >>>>>> it still is shown on the provided open link. It seems that the >>>>>> index.html file has not been updated. >>>>>> - the swing calls like "!menu.isSelected()" should be invoked >>>>>> on EDT. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> Thanks and Regards, >>>>>>> Nadeesh TV >>>>>>> >>>>>>> On 7/29/2015 3:38 PM, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> - It looks like the html file has been used only because the >>>>>>>> test was manual and it can be simply removed. >>>>>>>> - Is it possible to use a robot to press keys rather than put >>>>>>>> KeyEvents directly to the SystemEventQueue? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>>> On 7/24/2015 9:13 PM, nadeesh tv wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review a test bug fix >>>>>>>>> >>>>>>>>> TEST : *closed/javax/swing/JMenu/4213634/bug4213634.java * >>>>>>>>> BUG ID -*https://bugs.openjdk.java.net/browse/JDK-8017187* >>>>>>>>> >>>>>>>>> Please*move the test from closed repo tom open repo*. >>>>>>>>> >>>>>>>>> >>>>>>>>> The webrev >>>>>>>>> is:http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ add >>>>>>>>> to open repo >>>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~kshefov/8017187/webrev.diff/ - >>>>>>>>> diff with previous version of the closed test. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Thanks and Regards, >>>>>>>>> Nadeesh TV >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Best regards, Sergey. From nadeesh.tv at oracle.com Tue Aug 18 14:14:57 2015 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 18 Aug 2015 19:44:57 +0530 Subject: [RFR JDK-8017187] [TEST BUG] [macosx] After click "test", the case failed automatically with thrown exception in the log since jdk8b75 In-Reply-To: <55D3358D.403@oracle.com> References: <55B28053.4000101@oracle.com> <55B8A606.3030302@oracle.com> <55C21843.6020806@oracle.com> <55C22D04.7000405@oracle.com> <55C372AE.1060701@oracle.com> <55C9DB76.4060905@oracle.com> <55CAF9E0.30205@oracle.com> <55CAFDB4.5030201@oracle.com> <55D1BFED.8010601@oracle.com> <55D3358D.403@oracle.com> Message-ID: <55D33DE1.8020402@oracle.com> Hi all, Thanks for the review. Regards, Nadeesh On 8/18/2015 7:09 PM, Sergey Bylokhov wrote: > Looks fine. > > On 17.08.15 14:05, nadeesh tv wrote: >> Hi all, >> Gentle reminder >> Regards, >> Nadeesh >> On 8/12/2015 1:33 PM, Alexander Scherbatiy wrote: >>> >>> The fix looks good to me. >>> >>> Thanks, >>> Alexandr. >>> >>> On 8/12/2015 10:46 AM, nadeesh tv wrote: >>>> >>>> Hi, >>>> >>>> Please review the updated webrev links >>>> open- http://cr.openjdk.java.net/~sgupta/8017187/webrev.02/ >>>> closed- http://cr.openjdk.java.net/~sgupta/8017187/webrev.03/ >>>> Thanks and Regards, >>>> Nadeesh TV >>>> On 8/11/2015 4:54 PM, nadeesh tv wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review the updated webrev links >>>>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >>>>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>>>> Thanks and Regards, >>>>> Nadeesh TV >>>>> >>>>> >>>>> On 8/6/2015 8:13 PM, nadeesh tv wrote: >>>>>> Hi, >>>>>> Please review the updated webrev links >>>>>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >>>>>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>>>>> >>>>>> Thanks and Regards, >>>>>> Nadeesh TV >>>>>> On 8/5/2015 9:04 PM, Alexander Scherbatiy wrote: >>>>>>> On 8/5/2015 5:05 PM, nadeesh tv wrote: >>>>>>>> HI all, >>>>>>>> Please review the updated webrev links >>>>>>>> closed - http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ >>>>>>>> open - http://cr.openjdk.java.net/~sgupta/8017187/webrev.01/ >>>>>>> - the patch does not contain the html file as it expected >>>>>>> but it still is shown on the provided open link. It seems that >>>>>>> the index.html file has not been updated. >>>>>>> - the swing calls like "!menu.isSelected()" should be >>>>>>> invoked on EDT. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> Thanks and Regards, >>>>>>>> Nadeesh TV >>>>>>>> >>>>>>>> On 7/29/2015 3:38 PM, Alexander Scherbatiy wrote: >>>>>>>>> >>>>>>>>> - It looks like the html file has been used only because the >>>>>>>>> test was manual and it can be simply removed. >>>>>>>>> - Is it possible to use a robot to press keys rather than put >>>>>>>>> KeyEvents directly to the SystemEventQueue? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/24/2015 9:13 PM, nadeesh tv wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review a test bug fix >>>>>>>>>> >>>>>>>>>> TEST : *closed/javax/swing/JMenu/4213634/bug4213634.java * >>>>>>>>>> BUG ID -*https://bugs.openjdk.java.net/browse/JDK-8017187* >>>>>>>>>> >>>>>>>>>> Please*move the test from closed repo tom open repo*. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The webrev >>>>>>>>>> is:http://cr.openjdk.java.net/~sgupta/8017187/webrev.00/ add >>>>>>>>>> to open repo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8017187/webrev.diff/ - >>>>>>>>>> diff with previous version of the closed test. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Thanks and Regards, >>>>>>>>>> Nadeesh TV >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > -- Thanks and Regards, Nadeesh TV From Sergey.Bylokhov at oracle.com Wed Aug 19 13:42:16 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 19 Aug 2015 16:42:16 +0300 Subject: [9] Review Request: 8133926 No frame icon for InternalFrame in Windows LaF Message-ID: <55D487B8.7020207@oracle.com> Hello. Please review a small fix for jdk9. The fix for JDK- 8035313 [1] placed a parameters of the icon in the uidefaults instead of icon. Bug: https://bugs.openjdk.java.net/browse/JDK-8133926 Webrev can be found at: http://cr.openjdk.java.net/~serb/8133926/webrev.00 [1] http://hg.openjdk.java.net/jdk9/client/jdk/rev/01008cbd82a4 -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.brunet at oracle.com Wed Aug 19 21:50:24 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 19 Aug 2015 16:50:24 -0500 Subject: RfR: JDK-8133897, IndexOutOfBounds exception being thrown Message-ID: <55D4FA20.2070609@oracle.com> Please review this patch. http://cr.openjdk.java.net/~ptbrunet/JDK-8133897/webrev.00/ The issue is that the application has a tab with a visible title but for some reason JTabbedPane's title field was "". This caused indexOfTab(title) to return -1 and then getTabBounds(parent, -1) raised ArrayIndexOutOfBoundsException. public Rectangle getBounds() { - return parent.getUI().getTabBounds(parent, - parent.indexOfTab(title)); + int i = parent.indexOfTab(title); + Rectangle r; + // Check for no title. Even though that's a bug in the app we should + // inhibit an ArrayIndexOutOfBoundsException from getTabBounds. + if (i == -1) { + r = null; + } else { + r = parent.getUI().getTabBounds(parent, i); + } + return r; } Maybe someone more familiar with the code can see a bug related to why title is allowed to be "" when there is a visible title displayed in the tab. The bug I am working was raised during use of an app for which we do not have access so its source is not available. Thanks, Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.brunet at oracle.com Wed Aug 19 21:56:44 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 19 Aug 2015 16:56:44 -0500 Subject: RfR: JDK-8133897, IndexOutOfBounds exception being thrown In-Reply-To: <55D4FA20.2070609@oracle.com> References: <55D4FA20.2070609@oracle.com> Message-ID: <55D4FB9C.4000104@oracle.com> On 8/19/15 4:50 PM, Pete Brunet wrote: > Please review this patch. > http://cr.openjdk.java.net/~ptbrunet/JDK-8133897/webrev.00/ > > The issue is that the application has a tab with a visible title but > for some reason JTabbedPane's title field was "". This caused > indexOfTab(title) to return -1 and then getTabBounds(parent, -1) > raised ArrayIndexOutOfBoundsException. > > > public Rectangle getBounds() { > - return parent.getUI().getTabBounds(parent, > - parent.indexOfTab(title)); > + int i = parent.indexOfTab(title); > + Rectangle r; > + // Check for no title. Even though that's a bug in the > app we should > + // inhibit an ArrayIndexOutOfBoundsException from > getTabBounds. > + if (i == -1) { > + r = null; > + } else { > + r = parent.getUI().getTabBounds(parent, i); > + } > + return r; I suppose that could have been return (i == -1) ? null : parent.getUI().getTabBounds(parent, i); > } > > Maybe someone more familiar with the code can see a bug related to why > title is allowed to be "" when there is a visible title displayed in > the tab. The bug I am working was raised during use of an app for > which we do not have access so its source is not available. > > Thanks, Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Thu Aug 20 14:24:04 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 20 Aug 2015 17:24:04 +0300 Subject: [9] Review Request: 8133926 No frame icon for InternalFrame in Windows LaF In-Reply-To: <55D487B8.7020207@oracle.com> References: <55D487B8.7020207@oracle.com> Message-ID: <55D5E303.9060600@oracle.com> The fix looks good to me. Thanks, Alexandr. On 8/19/2015 4:42 PM, Sergey Bylokhov wrote: > Hello. > Please review a small fix for jdk9. > The fix for JDK- 8035313 [1] placed a parameters of the icon in the > uidefaults instead of icon. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8133926 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8133926/webrev.00 > > [1] http://hg.openjdk.java.net/jdk9/client/jdk/rev/01008cbd82a4 > -- > Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Aug 20 14:54:28 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 20 Aug 2015 17:54:28 +0300 Subject: RfR: JDK-8133897, IndexOutOfBounds exception being thrown In-Reply-To: <55D4FA20.2070609@oracle.com> References: <55D4FA20.2070609@oracle.com> Message-ID: <55D5EA24.2010502@oracle.com> On 8/20/2015 12:50 AM, Pete Brunet wrote: > Please review this patch. > http://cr.openjdk.java.net/~ptbrunet/JDK-8133897/webrev.00/ > > The issue is that the application has a tab with a visible title but > for some reason JTabbedPane's title field was "". This caused > indexOfTab(title) to return -1 and then getTabBounds(parent, -1) > raised ArrayIndexOutOfBoundsException. > > > public Rectangle getBounds() { > - return parent.getUI().getTabBounds(parent, > - parent.indexOfTab(title)); > + int i = parent.indexOfTab(title); > + Rectangle r; > + // Check for no title. Even though that's a bug in the > app we should > + // inhibit an ArrayIndexOutOfBoundsException from > getTabBounds. > + if (i == -1) { > + r = null; > + } else { > + r = parent.getUI().getTabBounds(parent, i); > + } > + return r; > } > > Maybe someone more familiar with the code can see a bug related to why > title is allowed to be "" when there is a visible title displayed in > the tab. The bug I am working was raised during use of an app for > which we do not have access so its source is not available. It is possible to add icon with text so the title will be empty: tabbedPane.addTab(null, icon, new JLabel("Content"). But even in this case indexOfTab returns the first tab with null title: tabbedPane.indexOfTab((String)null). Could it be that the tabbed pane title was changed between JTabbedPane.Page class creation and getBounds() method invoking? Thanks, Alexandr. > > Thanks, Pete From alexander.zvegintsev at oracle.com Thu Aug 20 15:00:14 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 20 Aug 2015 18:00:14 +0300 Subject: [9] Review Request: 8133926 No frame icon for InternalFrame in Windows LaF In-Reply-To: <55D5E303.9060600@oracle.com> References: <55D487B8.7020207@oracle.com> <55D5E303.9060600@oracle.com> Message-ID: <55D5EB7E.5020803@oracle.com> +1 Thanks, Alexander. On 08/20/2015 05:24 PM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 8/19/2015 4:42 PM, Sergey Bylokhov wrote: >> Hello. >> Please review a small fix for jdk9. >> The fix for JDK- 8035313 [1] placed a parameters of the icon in the >> uidefaults instead of icon. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8133926 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8133926/webrev.00 >> >> [1] http://hg.openjdk.java.net/jdk9/client/jdk/rev/01008cbd82a4 >> -- >> Best regards, Sergey. > From alexander.zvegintsev at oracle.com Thu Aug 20 15:28:42 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 20 Aug 2015 18:28:42 +0300 Subject: [9] Review request for 8081411 Add an API for painting an icon with a SynthContext In-Reply-To: <55C31AD1.9000909@oracle.com> References: <55C31AD1.9000909@oracle.com> Message-ID: <55D5F22A.7080900@oracle.com> The fix looks good to me. Thanks, Alexander. On 08/06/2015 11:29 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8081411 > webrev: http://cr.openjdk.java.net/~alexsch/8081411/webrev.00 > > The following use case were considered: > > 1. An icon is taken from UIManager.getIcon(iconKey) and should be > painted. > Icon icon = UIManager.getIcon(iconKey); > > icon.paint(graphics, x, y) may not work for icons that are used by > Synth L&F because the paint method with null synth context may just do > nothing. > > 2. One icons is created based on existed icon. > > Foe example, creating a centered icon: > ---------------------------- > Icon centeredIcon = new SynthIcon() { > private final SynthIcon synthIcon = (SynthIcon)icon; > public void paintIcon(SynthContext sc, Graphics grphcs, int x, > int y, int w, int h) { > try { > int dw = SynthIcon.getIconWidth(synthIcon, sc); > int dh = SynthIcon.getIconHeight(synthIcon, sc); > int dx = width - dw; > int dy = height - dh; > SynthIcon.paintIcon(synthIcon, sc, grphcs, x + dx/2, y > + dy/2, dw + 2, dh + 2); > } catch (Throwable t) { > try { synthIcon.paintIcon(sc, grphcs, x, y, w, h); } > catch (Throwable th) {} > } > } > public int getIconWidth(SynthContext sc) { return width; } > public int getIconHeight(SynthContext sc) { return height; } > }; > ---------------------------- > > Overriding just paintIcon(Component c, Graphics g, int x, int y) > leads to the same issue. The icon may not be drawn in this case. > > 3. Replace an icon in UIManager to a custom icon which can use a synth > context for painting: > UIManager.putIcon(iconKey, new CustomIcon()) > > The case 1 requires that only the following static methods were public: > SynthIcon.paintIcon(context, graphics, x, y, w, h) > SynthIcon.getIconwidth(context) > SynthIcon.getIconHeight(context) > > The cases 2 and 3 need to work with SyntIcon class. > > The proposed fix moves the paintIcon/getIconwidth/getIconHeight > methods to the public SynthGraphicsUtils class > and make the SynthIcon class public by moving it to the > javax.swing.plaf.synth package. > > Thanks, > Alexandr. > From javalists at cbfiddle.com Thu Aug 20 16:52:13 2015 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 20 Aug 2015 09:52:13 -0700 Subject: Public API for internal Swing classes. In-Reply-To: <55C32B3A.80004@oracle.com> References: <55B6244C.8040002@oracle.com> <55C32B3A.80004@oracle.com> Message-ID: <1FA9445E-7919-4366-8BE0-4B8EC2F9FE9C@cbfiddle.com> Although not strictly a Swing issue, this request could be of interest for platform specific LAFs: JDK-8133998 Provide public API to make natively rendered images cacheable > On Aug 6, 2015, at 2:39 AM, Alexander Scherbatiy wrote: > > > Some updates: > > - Just forgot to mention that it is better to provide not only information about used internal API but also > simple use cases where it shown in which way the internal API us used and which task it is intended to solve. > > - It is better to use jdeps from JDK 9 where it is more up-to-date than in JDK 8, > although the jdeps description is listed on Java SE 8 page: > https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.html > > - The updated list of known requests is: > > JDK-8133039 Provide public API to sun.swing.UIAction#isEnabled(Object) > https://bugs.openjdk.java.net/browse/JDK-8133039 > > JDK-8081411 Add an API for painting an icon with a SynthContext > https://bugs.openjdk.java.net/browse/JDK-8081411 > > JDK-6274842 RFE: Provide a means for a custom look and feel to use desktop font antialiasing settings. > https://bugs.openjdk.java.net/browse/JDK-6274842 > > JDK-8132119 Provide public API for text related methods in SwingUtilities2 > https://bugs.openjdk.java.net/browse/JDK-8132119 > > JDK-8132120 Provide public API for screen menu bar support on MacOS > https://bugs.openjdk.java.net/browse/JDK-8132120 > > JDK-6274842 RFE: Provide a means for a custom look and feel to use desktop font antialiasing settings. > https://bugs.openjdk.java.net/browse/JDK-6274842 > > Thanks, > Alexandr. > > On 7/27/2015 3:30 PM, Alexander Scherbatiy wrote: >> >> According to the JEP 200: The Modular JDK (see http://openjdk.java.net/jeps/200) >> we expect that the standard Java SE modules will not export any internal packages. >> >> It means that classes from internal packages (like sun.swing) will not be accessible. >> >> For example: >> sun.swing.FilePane >> sun.swing.SwingUtilities2 >> sun.swing.sun.swing.plaf.synth.SynthIcon >> and others. >> >> >> Please, let us known if you are using the internal Swing API and it is not possible to replace it by public API. >> >> There are some known requests: >> >> JDK-8132119 Provide public API for text related methods in SwingUtilities2 >> https://bugs.openjdk.java.net/browse/JDK-8132119 >> >> JDK-8132120 Provide public API for screen menu bar support on MacOS >> https://bugs.openjdk.java.net/browse/JDK-8132120 >> >> JDK-6274842 RFE: Provide a means for a custom look and feel to use desktop font antialiasing settings. >> https://bugs.openjdk.java.net/browse/JDK-6274842 >> >> >> If you don't know if you use these types (because you use 3rd party jars) >> you can use the JDK 8 "jdeps" tool to find such dependencies :- >> >> ~/jdk1.8/bin/jdeps >> Usage: jdeps >> where can be a pathname to a .class file, a directory, a JAR >> file, or a fully-qualified class name >> >> Thanks, >> Alexandr. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Aug 20 17:47:35 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 20 Aug 2015 10:47:35 -0700 Subject: JDK 9 RFR of JDK-8134084: Mark client libs regression tests using randomness Message-ID: <55D612B7.4010001@oracle.com> Hello, As part of implementing tiered testing [1], client library tests which use randomness should be marked with the corresponding keyword. The analogous changes have been made in core libs, see JDK-8078334: Mark regression tests using randomness. Webrev at JDK-8134084 : Mark client libs regression tests using randomness http://cr.openjdk.java.net/~darcy/8134084.0/ and patch below. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html --- old/test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java 2015-08-20 10:39:36.425041467 -0700 +++ new/test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java 2015-08-20 10:39:36.273041463 -0700 @@ -30,6 +30,7 @@ * @library ../../regtesthelpers * @build Util * @run main LoopRobustness + * @key randomness */ import java.awt.*; --- old/test/java/awt/FullScreen/AltTabCrashTest/AltTabCrashTest.java 2015-08-20 10:39:36.805041477 -0700 +++ new/test/java/awt/FullScreen/AltTabCrashTest/AltTabCrashTest.java 2015-08-20 10:39:36.653041473 -0700 @@ -31,6 +31,7 @@ @run main/othervm/timeout=100 -Dsun.java2d.d3d=True AltTabCrashTest -auto -changedm @run main/othervm/timeout=100 -Dsun.java2d.d3d=True AltTabCrashTest -auto -usebs -changedm @run main/othervm/timeout=100 -Dsun.java2d.opengl=True AltTabCrashTest -auto + @key randomness */ import java.awt.AWTException; --- old/test/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java 2015-08-20 10:39:37.193041487 -0700 +++ new/test/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java 2015-08-20 10:39:37.041041483 -0700 @@ -29,6 +29,7 @@ * @run main/othervm/timeout=200 DisplayChangeVITest * @run main/othervm/timeout=200 -Dsun.java2d.d3d=false DisplayChangeVITest * @run main/othervm/timeout=200 -Dsun.java2d.opengl=true DisplayChangeVITest + * @key randomness */ import java.awt.Color; --- old/test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java 2015-08-20 10:39:37.577041497 -0700 +++ new/test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java 2015-08-20 10:39:37.425041493 -0700 @@ -50,6 +50,7 @@ * @run main/manual/othervm -Dsun.java2d.d3d=True MultimonFullscreenTest * @run main/manual/othervm -Dsun.java2d.noddraw=true MultimonFullscreenTest * @run main/manual/othervm -Dsun.java2d.opengl=True MultimonFullscreenTest + * @key randomness */ import java.awt.Button; --- old/test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java 2015-08-20 10:39:37.957041506 -0700 +++ new/test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java 2015-08-20 10:39:37.797041502 -0700 @@ -29,6 +29,7 @@ @author Dmitri.Trembovetski at sun.com area=Graphics @run main MTGraphicsAccessTest + @key randomness */ import java.awt.*; --- old/test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java 2015-08-20 10:39:38.333041516 -0700 +++ new/test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java 2015-08-20 10:39:38.185041512 -0700 @@ -27,6 +27,7 @@ * @summary Tests clipping invariance for AA rectangle and line primitives * @run main RenderClipTest -strict -readfile 6766342.tests * @run main RenderClipTest -rectsuite -count 10 + * @key randomness */ import java.awt.*; --- old/test/java/awt/GridLayout/ComponentPreferredSize/ComponentPreferredSize.java 2015-08-20 10:39:38.765041527 -0700 +++ new/test/java/awt/GridLayout/ComponentPreferredSize/ComponentPreferredSize.java 2015-08-20 10:39:38.569041522 -0700 @@ -36,6 +36,7 @@ * @build ExtendedRobot * @run main ComponentPreferredSize * @run main ComponentPreferredSize -hg 20 -vg 20 + * @key randomness */ public class ComponentPreferredSize { --- old/test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java 2015-08-20 10:39:39.169041537 -0700 +++ new/test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java 2015-08-20 10:39:39.017041534 -0700 @@ -46,6 +46,7 @@ * @library ../../../../lib/testlibrary * @build Common ExtendedRobot * @run main Shaped + * @key randomness */ public class Shaped extends Common{ --- old/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java 2015-08-20 10:39:39.549041547 -0700 +++ new/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java 2015-08-20 10:39:39.397041543 -0700 @@ -44,6 +44,7 @@ * @author Dmitriy Ermashov (dmitriy.ermashov at oracle.com) * @library ../../../../lib/testlibrary * @run main ShapedByAPI + * @key randomness */ public class ShapedByAPI extends Common { --- old/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java 2015-08-20 10:39:39.933041557 -0700 +++ new/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java 2015-08-20 10:39:39.777041553 -0700 @@ -45,6 +45,7 @@ * @library ../../../../lib/testlibrary * @build Common ExtendedRobot * @run main ShapedTranslucent + * @key randomness */ public class ShapedTranslucent extends Common { --- old/test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 2015-08-20 10:39:40.313041567 -0700 +++ new/test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java 2015-08-20 10:39:40.161041563 -0700 @@ -45,6 +45,7 @@ * @library ../../../../lib/testlibrary * @build Common ExtendedRobot * @run main StaticallyShaped + * @key randomness */ public class StaticallyShaped extends Common { --- old/test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java 2015-08-20 10:39:40.697041577 -0700 +++ new/test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java 2015-08-20 10:39:40.545041573 -0700 @@ -43,6 +43,7 @@ * @library ../../../../lib/testlibrary * @build Common ExtendedRobot * @run main Translucent + * @key randomness */ public class Translucent extends Common { --- old/test/java/awt/Window/setLocRelativeTo/SetLocationRelativeToTest.java 2015-08-20 10:39:41.077041586 -0700 +++ new/test/java/awt/Window/setLocRelativeTo/SetLocationRelativeToTest.java 2015-08-20 10:39:40.921041582 -0700 @@ -34,6 +34,7 @@ @library ../../../../lib/testlibrary @build ExtendedRobot @run main/timeout=1200 SetLocationRelativeToTest + at key randomness */ public class SetLocationRelativeToTest { --- old/test/java/awt/font/LineBreakMeasurer/FRCTest.java 2015-08-20 10:39:41.461041596 -0700 +++ new/test/java/awt/font/LineBreakMeasurer/FRCTest.java 2015-08-20 10:39:41.309041592 -0700 @@ -26,6 +26,7 @@ * @bug 6448405 6519513 6745225 * @summary static HashMap cache in LineBreakMeasurer can grow wihout bounds * @run main/othervm/timeout=600 -client -Xms16m -Xmx16m FRCTest + * @key randomness */ import java.awt.*; import java.awt.image.*; --- old/test/java/awt/geom/AffineTransform/GetTypeOptimization.java 2015-08-20 10:39:41.845041606 -0700 +++ new/test/java/awt/geom/AffineTransform/GetTypeOptimization.java 2015-08-20 10:39:41.689041602 -0700 @@ -29,6 +29,7 @@ * This test also confirms that isIdentity() returns the * optimal value under all histories of modification. * @run main GetTypeOptimization + * @key randomness */ import java.awt.geom.AffineTransform; --- old/test/java/awt/geom/AffineTransform/TestRotateMethods.java 2015-08-20 10:39:42.221041616 -0700 +++ new/test/java/awt/geom/AffineTransform/TestRotateMethods.java 2015-08-20 10:39:42.073041612 -0700 @@ -36,6 +36,7 @@ * * @author flar * @run main TestRotateMethods + * @key randomness */ import java.awt.geom.AffineTransform; --- old/test/java/awt/image/BufferedImage/TinyScale.java 2015-08-20 10:39:42.593041625 -0700 +++ new/test/java/awt/image/BufferedImage/TinyScale.java 2015-08-20 10:39:42.445041622 -0700 @@ -22,9 +22,10 @@ */ /* - * @test %W% %E% + * @test * @bug 7016495 * @summary Test tiny scales of BufferedImage + * @key randomness */ import java.awt.*; --- old/test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java 2015-08-20 10:39:42.973041635 -0700 +++ new/test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java 2015-08-20 10:39:42.817041631 -0700 @@ -28,6 +28,7 @@ * even if destroy() or reset() methods is not invoked. * * @run main JpegWriterLeakTest + * @key randomness */ import java.awt.Color; --- old/test/javax/imageio/plugins/png/ShortHistogramTest.java 2015-08-20 10:39:43.345041645 -0700 +++ new/test/javax/imageio/plugins/png/ShortHistogramTest.java 2015-08-20 10:39:43.193041641 -0700 @@ -28,6 +28,7 @@ * hIST chunk if length of image palette in not power of two. * * @run main ShortHistogramTest 15 + * @key randomness */ import java.awt.Color; --- old/test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java 2015-08-20 10:39:43.717041654 -0700 +++ new/test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java 2015-08-20 10:39:43.569041650 -0700 @@ -24,6 +24,7 @@ /* @test @summary Test SoftFilter processAudio method @modules java.desktop/com.sun.media.sound + @key randomness */ import java.io.File; --- old/test/javax/sound/sampled/FileWriter/AlawEncoderSync.java 2015-08-20 10:39:44.093041664 -0700 +++ new/test/javax/sound/sampled/FileWriter/AlawEncoderSync.java 2015-08-20 10:39:43.941041660 -0700 @@ -27,6 +27,7 @@ * @bug 7058852 * @summary Tests that Alaw encoder works properly in multithreaded environment * @author Alex Menkov + * @key randomness */ import java.io.ByteArrayInputStream; --- old/test/javax/swing/JColorChooser/Test4165217.java 2015-08-20 10:39:44.461041673 -0700 +++ new/test/javax/swing/JColorChooser/Test4165217.java 2015-08-20 10:39:44.309041669 -0700 @@ -26,6 +26,7 @@ * @bug 4165217 * @summary Tests JColorChooser serialization * @author Ilya Boyandin + * @key randomness */ import java.awt.Color; --- old/test/javax/swing/JFileChooser/6868611/bug6868611.java 2015-08-20 10:39:44.833041683 -0700 +++ new/test/javax/swing/JFileChooser/6868611/bug6868611.java 2015-08-20 10:39:44.681041679 -0700 @@ -26,6 +26,7 @@ @summary FileSystemView throws NullPointerException @author Pavel Porvatov @run main bug6868611 + @key randomness */ import javax.swing.*; --- old/test/javax/swing/JFrame/4962534/bug4962534.java 2015-08-20 10:39:45.205041692 -0700 +++ new/test/javax/swing/JFrame/4962534/bug4962534.java 2015-08-20 10:39:45.053041688 -0700 @@ -27,6 +27,7 @@ @summary JFrame dances very badly @author dav at sparc.spb.su area= @run applet bug4962534.html + @key randomness */ import java.applet.Applet; import java.awt.*; --- old/test/javax/swing/system/6799345/TestShutdown.java 2015-08-20 10:39:45.577041702 -0700 +++ new/test/javax/swing/system/6799345/TestShutdown.java 2015-08-20 10:39:45.433041698 -0700 @@ -28,6 +28,7 @@ @author art @modules java.desktop/sun.awt @run main TestShutdown + @key randomness */ import java.awt.*; From philip.race at oracle.com Thu Aug 20 18:14:17 2015 From: philip.race at oracle.com (Phil Race) Date: Thu, 20 Aug 2015 11:14:17 -0700 Subject: JDK 9 RFR of JDK-8134084: Mark client libs regression tests using randomness In-Reply-To: <55D612B7.4010001@oracle.com> References: <55D612B7.4010001@oracle.com> Message-ID: <55D618F9.3020404@oracle.com> Joe, How is this keyword interpreted and used ? How did you select the tests below to be so marked ? I might ask more once I understand the answers to these but looking at just one of these - MTGraphicsAccessTest.java - there is no such thing a spurious failure of this test. If you ever see a failure that is a real bug. Perhaps all the passes are spurious if there is in fact a bug somewhere that would cause a crash but the test is not catching it but that does not seem like a reason to exclude the test - assuming that is what this keyword will be used for. -phil. On 08/20/2015 10:47 AM, joe darcy wrote: > Hello, > > As part of implementing tiered testing [1], client library tests which > use randomness should be marked with the corresponding keyword. The > analogous changes have been made in core libs, see JDK-8078334: Mark > regression tests using randomness. > > Webrev at > > JDK-8134084 : Mark client libs regression tests using randomness > http://cr.openjdk.java.net/~darcy/8134084.0/ > > and patch below. > > Thanks, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html > > --- > old/test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java > 2015-08-20 10:39:36.425041467 -0700 > +++ > new/test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java > 2015-08-20 10:39:36.273041463 -0700 > @@ -30,6 +30,7 @@ > * @library ../../regtesthelpers > * @build Util > * @run main LoopRobustness > + * @key randomness > */ > > import java.awt.*; > --- old/test/java/awt/FullScreen/AltTabCrashTest/AltTabCrashTest.java > 2015-08-20 10:39:36.805041477 -0700 > +++ new/test/java/awt/FullScreen/AltTabCrashTest/AltTabCrashTest.java > 2015-08-20 10:39:36.653041473 -0700 > @@ -31,6 +31,7 @@ > @run main/othervm/timeout=100 -Dsun.java2d.d3d=True AltTabCrashTest > -auto -changedm > @run main/othervm/timeout=100 -Dsun.java2d.d3d=True AltTabCrashTest > -auto -usebs -changedm > @run main/othervm/timeout=100 -Dsun.java2d.opengl=True > AltTabCrashTest -auto > + @key randomness > */ > > import java.awt.AWTException; > --- > old/test/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java > 2015-08-20 10:39:37.193041487 -0700 > +++ > new/test/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java > 2015-08-20 10:39:37.041041483 -0700 > @@ -29,6 +29,7 @@ > * @run main/othervm/timeout=200 DisplayChangeVITest > * @run main/othervm/timeout=200 -Dsun.java2d.d3d=false > DisplayChangeVITest > * @run main/othervm/timeout=200 -Dsun.java2d.opengl=true > DisplayChangeVITest > + * @key randomness > */ > > import java.awt.Color; > --- > old/test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java > 2015-08-20 10:39:37.577041497 -0700 > +++ > new/test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java > 2015-08-20 10:39:37.425041493 -0700 > @@ -50,6 +50,7 @@ > * @run main/manual/othervm -Dsun.java2d.d3d=True MultimonFullscreenTest > * @run main/manual/othervm -Dsun.java2d.noddraw=true > MultimonFullscreenTest > * @run main/manual/othervm -Dsun.java2d.opengl=True > MultimonFullscreenTest > + * @key randomness > */ > > import java.awt.Button; > --- > old/test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java > 2015-08-20 10:39:37.957041506 -0700 > +++ > new/test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java > 2015-08-20 10:39:37.797041502 -0700 > @@ -29,6 +29,7 @@ > > @author Dmitri.Trembovetski at sun.com area=Graphics > @run main MTGraphicsAccessTest > + @key randomness > */ > > import java.awt.*; > --- old/test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java > 2015-08-20 10:39:38.333041516 -0700 > +++ new/test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java > 2015-08-20 10:39:38.185041512 -0700 > @@ -27,6 +27,7 @@ > * @summary Tests clipping invariance for AA rectangle and line > primitives > * @run main RenderClipTest -strict -readfile 6766342.tests > * @run main RenderClipTest -rectsuite -count 10 > + * @key randomness > */ > > import java.awt.*; > --- > old/test/java/awt/GridLayout/ComponentPreferredSize/ComponentPreferredSize.java > 2015-08-20 10:39:38.765041527 -0700 > +++ > new/test/java/awt/GridLayout/ComponentPreferredSize/ComponentPreferredSize.java > 2015-08-20 10:39:38.569041522 -0700 > @@ -36,6 +36,7 @@ > * @build ExtendedRobot > * @run main ComponentPreferredSize > * @run main ComponentPreferredSize -hg 20 -vg 20 > + * @key randomness > */ > > public class ComponentPreferredSize { > --- old/test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java > 2015-08-20 10:39:39.169041537 -0700 > +++ new/test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java > 2015-08-20 10:39:39.017041534 -0700 > @@ -46,6 +46,7 @@ > * @library ../../../../lib/testlibrary > * @build Common ExtendedRobot > * @run main Shaped > + * @key randomness > */ > public class Shaped extends Common{ > > --- > old/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java > 2015-08-20 10:39:39.549041547 -0700 > +++ > new/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java > 2015-08-20 10:39:39.397041543 -0700 > @@ -44,6 +44,7 @@ > * @author Dmitriy Ermashov (dmitriy.ermashov at oracle.com) > * @library ../../../../lib/testlibrary > * @run main ShapedByAPI > + * @key randomness > */ > public class ShapedByAPI extends Common { > > --- > old/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java > 2015-08-20 10:39:39.933041557 -0700 > +++ > new/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java > 2015-08-20 10:39:39.777041553 -0700 > @@ -45,6 +45,7 @@ > * @library ../../../../lib/testlibrary > * @build Common ExtendedRobot > * @run main ShapedTranslucent > + * @key randomness > */ > public class ShapedTranslucent extends Common { > > --- > old/test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java > 2015-08-20 10:39:40.313041567 -0700 > +++ > new/test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java > 2015-08-20 10:39:40.161041563 -0700 > @@ -45,6 +45,7 @@ > * @library ../../../../lib/testlibrary > * @build Common ExtendedRobot > * @run main StaticallyShaped > + * @key randomness > */ > > public class StaticallyShaped extends Common { > --- > old/test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java > 2015-08-20 10:39:40.697041577 -0700 > +++ > new/test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java > 2015-08-20 10:39:40.545041573 -0700 > @@ -43,6 +43,7 @@ > * @library ../../../../lib/testlibrary > * @build Common ExtendedRobot > * @run main Translucent > + * @key randomness > */ > public class Translucent extends Common { > > --- > old/test/java/awt/Window/setLocRelativeTo/SetLocationRelativeToTest.java > 2015-08-20 10:39:41.077041586 -0700 > +++ > new/test/java/awt/Window/setLocRelativeTo/SetLocationRelativeToTest.java > 2015-08-20 10:39:40.921041582 -0700 > @@ -34,6 +34,7 @@ > @library ../../../../lib/testlibrary > @build ExtendedRobot > @run main/timeout=1200 SetLocationRelativeToTest > + at key randomness > */ > > public class SetLocationRelativeToTest { > --- old/test/java/awt/font/LineBreakMeasurer/FRCTest.java 2015-08-20 > 10:39:41.461041596 -0700 > +++ new/test/java/awt/font/LineBreakMeasurer/FRCTest.java 2015-08-20 > 10:39:41.309041592 -0700 > @@ -26,6 +26,7 @@ > * @bug 6448405 6519513 6745225 > * @summary static HashMap cache in LineBreakMeasurer can grow wihout > bounds > * @run main/othervm/timeout=600 -client -Xms16m -Xmx16m FRCTest > + * @key randomness > */ > import java.awt.*; > import java.awt.image.*; > --- old/test/java/awt/geom/AffineTransform/GetTypeOptimization.java > 2015-08-20 10:39:41.845041606 -0700 > +++ new/test/java/awt/geom/AffineTransform/GetTypeOptimization.java > 2015-08-20 10:39:41.689041602 -0700 > @@ -29,6 +29,7 @@ > * This test also confirms that isIdentity() returns the > * optimal value under all histories of modification. > * @run main GetTypeOptimization > + * @key randomness > */ > > import java.awt.geom.AffineTransform; > --- old/test/java/awt/geom/AffineTransform/TestRotateMethods.java > 2015-08-20 10:39:42.221041616 -0700 > +++ new/test/java/awt/geom/AffineTransform/TestRotateMethods.java > 2015-08-20 10:39:42.073041612 -0700 > @@ -36,6 +36,7 @@ > * > * @author flar > * @run main TestRotateMethods > + * @key randomness > */ > > import java.awt.geom.AffineTransform; > --- old/test/java/awt/image/BufferedImage/TinyScale.java 2015-08-20 > 10:39:42.593041625 -0700 > +++ new/test/java/awt/image/BufferedImage/TinyScale.java 2015-08-20 > 10:39:42.445041622 -0700 > @@ -22,9 +22,10 @@ > */ > > /* > - * @test %W% %E% > + * @test > * @bug 7016495 > * @summary Test tiny scales of BufferedImage > + * @key randomness > */ > > import java.awt.*; > --- old/test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java > 2015-08-20 10:39:42.973041635 -0700 > +++ new/test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java > 2015-08-20 10:39:42.817041631 -0700 > @@ -28,6 +28,7 @@ > * even if destroy() or reset() methods is not invoked. > * > * @run main JpegWriterLeakTest > + * @key randomness > */ > > import java.awt.Color; > --- old/test/javax/imageio/plugins/png/ShortHistogramTest.java > 2015-08-20 10:39:43.345041645 -0700 > +++ new/test/javax/imageio/plugins/png/ShortHistogramTest.java > 2015-08-20 10:39:43.193041641 -0700 > @@ -28,6 +28,7 @@ > * hIST chunk if length of image palette in not power of two. > * > * @run main ShortHistogramTest 15 > + * @key randomness > */ > > import java.awt.Color; > --- old/test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java > 2015-08-20 10:39:43.717041654 -0700 > +++ new/test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java > 2015-08-20 10:39:43.569041650 -0700 > @@ -24,6 +24,7 @@ > /* @test > @summary Test SoftFilter processAudio method > @modules java.desktop/com.sun.media.sound > + @key randomness > */ > > import java.io.File; > --- old/test/javax/sound/sampled/FileWriter/AlawEncoderSync.java > 2015-08-20 10:39:44.093041664 -0700 > +++ new/test/javax/sound/sampled/FileWriter/AlawEncoderSync.java > 2015-08-20 10:39:43.941041660 -0700 > @@ -27,6 +27,7 @@ > * @bug 7058852 > * @summary Tests that Alaw encoder works properly in multithreaded > environment > * @author Alex Menkov > + * @key randomness > */ > > import java.io.ByteArrayInputStream; > --- old/test/javax/swing/JColorChooser/Test4165217.java 2015-08-20 > 10:39:44.461041673 -0700 > +++ new/test/javax/swing/JColorChooser/Test4165217.java 2015-08-20 > 10:39:44.309041669 -0700 > @@ -26,6 +26,7 @@ > * @bug 4165217 > * @summary Tests JColorChooser serialization > * @author Ilya Boyandin > + * @key randomness > */ > > import java.awt.Color; > --- old/test/javax/swing/JFileChooser/6868611/bug6868611.java > 2015-08-20 10:39:44.833041683 -0700 > +++ new/test/javax/swing/JFileChooser/6868611/bug6868611.java > 2015-08-20 10:39:44.681041679 -0700 > @@ -26,6 +26,7 @@ > @summary FileSystemView throws NullPointerException > @author Pavel Porvatov > @run main bug6868611 > + @key randomness > */ > > import javax.swing.*; > --- old/test/javax/swing/JFrame/4962534/bug4962534.java 2015-08-20 > 10:39:45.205041692 -0700 > +++ new/test/javax/swing/JFrame/4962534/bug4962534.java 2015-08-20 > 10:39:45.053041688 -0700 > @@ -27,6 +27,7 @@ > @summary JFrame dances very badly > @author dav at sparc.spb.su area= > @run applet bug4962534.html > + @key randomness > */ > import java.applet.Applet; > import java.awt.*; > --- old/test/javax/swing/system/6799345/TestShutdown.java 2015-08-20 > 10:39:45.577041702 -0700 > +++ new/test/javax/swing/system/6799345/TestShutdown.java 2015-08-20 > 10:39:45.433041698 -0700 > @@ -28,6 +28,7 @@ > @author art > @modules java.desktop/sun.awt > @run main TestShutdown > + @key randomness > */ > > import java.awt.*; > From joe.darcy at oracle.com Thu Aug 20 18:44:57 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 20 Aug 2015 11:44:57 -0700 Subject: JDK 9 RFR of JDK-8134084: Mark client libs regression tests using randomness In-Reply-To: <55D618F9.3020404@oracle.com> References: <55D612B7.4010001@oracle.com> <55D618F9.3020404@oracle.com> Message-ID: <55D62029.9020103@oracle.com> Hi Phil, On 8/20/2015 11:14 AM, Phil Race wrote: > Joe, > > How is this keyword interpreted and used ? From the TEST.ROOT file in the jdk/test directory: # The "randomness" keyword marks tests using randomness with test # cases differing from run to run. (A test using a fixed random seed # would not count as "randomness" by this definition.) Extra care # should be taken to handle test failures of intermittent or # randomness tests. > How did you select the tests below to be so marked ? Running the command find java/awt java/beans/ javax/swing/ javax/imageio/ javax/sound -type f | xargs grep -l -i random and looking for cases were randomness was used such as extracting values from a Random or SecureRandom object. In particular, test just using random-access-file and the like did get tagged with the keyword. > I might ask more once I understand the answers to these but looking > at just one of these - MTGraphicsAccessTest.java - there is no such > thing a spurious failure of this test. If you ever see a failure that > is a real > bug. Perhaps all the passes are spurious if there is in fact a bug > somewhere that would cause a crash but the test is not catching > it but that does not seem like a reason to exclude the test - assuming > that is what this keyword will be used for. We've seen cases elsewhere where using a random number generator has obscured the cause of a intermittent test failure or a true product bug. If a test using randomness fails intermittently, then its random number generator should be switched over to a utility random number generator which always prints out the seed and allows the seed to be set. We've had a number of fixes in core libs from following this policy, including JDK-8022224 and JDK-6854417 HTH, -Joe > > -phil. > > On 08/20/2015 10:47 AM, joe darcy wrote: >> Hello, >> >> As part of implementing tiered testing [1], client library tests >> which use randomness should be marked with the corresponding keyword. >> The analogous changes have been made in core libs, see JDK-8078334: >> Mark regression tests using randomness. >> >> Webrev at >> >> JDK-8134084 : Mark client libs regression tests using randomness >> http://cr.openjdk.java.net/~darcy/8134084.0/ >> >> and patch below. >> >> Thanks, >> >> -Joe >> >> [1] >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html >> >> --- >> old/test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java >> 2015-08-20 10:39:36.425041467 -0700 >> +++ >> new/test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java >> 2015-08-20 10:39:36.273041463 -0700 >> @@ -30,6 +30,7 @@ >> * @library ../../regtesthelpers >> * @build Util >> * @run main LoopRobustness >> + * @key randomness >> */ >> >> import java.awt.*; >> --- old/test/java/awt/FullScreen/AltTabCrashTest/AltTabCrashTest.java >> 2015-08-20 10:39:36.805041477 -0700 >> +++ new/test/java/awt/FullScreen/AltTabCrashTest/AltTabCrashTest.java >> 2015-08-20 10:39:36.653041473 -0700 >> @@ -31,6 +31,7 @@ >> @run main/othervm/timeout=100 -Dsun.java2d.d3d=True AltTabCrashTest >> -auto -changedm >> @run main/othervm/timeout=100 -Dsun.java2d.d3d=True AltTabCrashTest >> -auto -usebs -changedm >> @run main/othervm/timeout=100 -Dsun.java2d.opengl=True >> AltTabCrashTest -auto >> + @key randomness >> */ >> >> import java.awt.AWTException; >> --- >> old/test/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java >> 2015-08-20 10:39:37.193041487 -0700 >> +++ >> new/test/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java >> 2015-08-20 10:39:37.041041483 -0700 >> @@ -29,6 +29,7 @@ >> * @run main/othervm/timeout=200 DisplayChangeVITest >> * @run main/othervm/timeout=200 -Dsun.java2d.d3d=false >> DisplayChangeVITest >> * @run main/othervm/timeout=200 -Dsun.java2d.opengl=true >> DisplayChangeVITest >> + * @key randomness >> */ >> >> import java.awt.Color; >> --- >> old/test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java >> 2015-08-20 10:39:37.577041497 -0700 >> +++ >> new/test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java >> 2015-08-20 10:39:37.425041493 -0700 >> @@ -50,6 +50,7 @@ >> * @run main/manual/othervm -Dsun.java2d.d3d=True >> MultimonFullscreenTest >> * @run main/manual/othervm -Dsun.java2d.noddraw=true >> MultimonFullscreenTest >> * @run main/manual/othervm -Dsun.java2d.opengl=True >> MultimonFullscreenTest >> + * @key randomness >> */ >> >> import java.awt.Button; >> --- >> old/test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java >> 2015-08-20 10:39:37.957041506 -0700 >> +++ >> new/test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java >> 2015-08-20 10:39:37.797041502 -0700 >> @@ -29,6 +29,7 @@ >> >> @author Dmitri.Trembovetski at sun.com area=Graphics >> @run main MTGraphicsAccessTest >> + @key randomness >> */ >> >> import java.awt.*; >> --- old/test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java >> 2015-08-20 10:39:38.333041516 -0700 >> +++ new/test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java >> 2015-08-20 10:39:38.185041512 -0700 >> @@ -27,6 +27,7 @@ >> * @summary Tests clipping invariance for AA rectangle and line >> primitives >> * @run main RenderClipTest -strict -readfile 6766342.tests >> * @run main RenderClipTest -rectsuite -count 10 >> + * @key randomness >> */ >> >> import java.awt.*; >> --- >> old/test/java/awt/GridLayout/ComponentPreferredSize/ComponentPreferredSize.java >> 2015-08-20 10:39:38.765041527 -0700 >> +++ >> new/test/java/awt/GridLayout/ComponentPreferredSize/ComponentPreferredSize.java >> 2015-08-20 10:39:38.569041522 -0700 >> @@ -36,6 +36,7 @@ >> * @build ExtendedRobot >> * @run main ComponentPreferredSize >> * @run main ComponentPreferredSize -hg 20 -vg 20 >> + * @key randomness >> */ >> >> public class ComponentPreferredSize { >> --- old/test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java >> 2015-08-20 10:39:39.169041537 -0700 >> +++ new/test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java >> 2015-08-20 10:39:39.017041534 -0700 >> @@ -46,6 +46,7 @@ >> * @library ../../../../lib/testlibrary >> * @build Common ExtendedRobot >> * @run main Shaped >> + * @key randomness >> */ >> public class Shaped extends Common{ >> >> --- >> old/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java >> 2015-08-20 10:39:39.549041547 -0700 >> +++ >> new/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java >> 2015-08-20 10:39:39.397041543 -0700 >> @@ -44,6 +44,7 @@ >> * @author Dmitriy Ermashov (dmitriy.ermashov at oracle.com) >> * @library ../../../../lib/testlibrary >> * @run main ShapedByAPI >> + * @key randomness >> */ >> public class ShapedByAPI extends Common { >> >> --- >> old/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java >> 2015-08-20 10:39:39.933041557 -0700 >> +++ >> new/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java >> 2015-08-20 10:39:39.777041553 -0700 >> @@ -45,6 +45,7 @@ >> * @library ../../../../lib/testlibrary >> * @build Common ExtendedRobot >> * @run main ShapedTranslucent >> + * @key randomness >> */ >> public class ShapedTranslucent extends Common { >> >> --- >> old/test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >> 2015-08-20 10:39:40.313041567 -0700 >> +++ >> new/test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >> 2015-08-20 10:39:40.161041563 -0700 >> @@ -45,6 +45,7 @@ >> * @library ../../../../lib/testlibrary >> * @build Common ExtendedRobot >> * @run main StaticallyShaped >> + * @key randomness >> */ >> >> public class StaticallyShaped extends Common { >> --- >> old/test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java >> 2015-08-20 10:39:40.697041577 -0700 >> +++ >> new/test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java >> 2015-08-20 10:39:40.545041573 -0700 >> @@ -43,6 +43,7 @@ >> * @library ../../../../lib/testlibrary >> * @build Common ExtendedRobot >> * @run main Translucent >> + * @key randomness >> */ >> public class Translucent extends Common { >> >> --- >> old/test/java/awt/Window/setLocRelativeTo/SetLocationRelativeToTest.java >> 2015-08-20 10:39:41.077041586 -0700 >> +++ >> new/test/java/awt/Window/setLocRelativeTo/SetLocationRelativeToTest.java >> 2015-08-20 10:39:40.921041582 -0700 >> @@ -34,6 +34,7 @@ >> @library ../../../../lib/testlibrary >> @build ExtendedRobot >> @run main/timeout=1200 SetLocationRelativeToTest >> + at key randomness >> */ >> >> public class SetLocationRelativeToTest { >> --- old/test/java/awt/font/LineBreakMeasurer/FRCTest.java 2015-08-20 >> 10:39:41.461041596 -0700 >> +++ new/test/java/awt/font/LineBreakMeasurer/FRCTest.java 2015-08-20 >> 10:39:41.309041592 -0700 >> @@ -26,6 +26,7 @@ >> * @bug 6448405 6519513 6745225 >> * @summary static HashMap cache in LineBreakMeasurer can grow >> wihout bounds >> * @run main/othervm/timeout=600 -client -Xms16m -Xmx16m FRCTest >> + * @key randomness >> */ >> import java.awt.*; >> import java.awt.image.*; >> --- old/test/java/awt/geom/AffineTransform/GetTypeOptimization.java >> 2015-08-20 10:39:41.845041606 -0700 >> +++ new/test/java/awt/geom/AffineTransform/GetTypeOptimization.java >> 2015-08-20 10:39:41.689041602 -0700 >> @@ -29,6 +29,7 @@ >> * This test also confirms that isIdentity() returns the >> * optimal value under all histories of modification. >> * @run main GetTypeOptimization >> + * @key randomness >> */ >> >> import java.awt.geom.AffineTransform; >> --- old/test/java/awt/geom/AffineTransform/TestRotateMethods.java >> 2015-08-20 10:39:42.221041616 -0700 >> +++ new/test/java/awt/geom/AffineTransform/TestRotateMethods.java >> 2015-08-20 10:39:42.073041612 -0700 >> @@ -36,6 +36,7 @@ >> * >> * @author flar >> * @run main TestRotateMethods >> + * @key randomness >> */ >> >> import java.awt.geom.AffineTransform; >> --- old/test/java/awt/image/BufferedImage/TinyScale.java 2015-08-20 >> 10:39:42.593041625 -0700 >> +++ new/test/java/awt/image/BufferedImage/TinyScale.java 2015-08-20 >> 10:39:42.445041622 -0700 >> @@ -22,9 +22,10 @@ >> */ >> >> /* >> - * @test %W% %E% >> + * @test >> * @bug 7016495 >> * @summary Test tiny scales of BufferedImage >> + * @key randomness >> */ >> >> import java.awt.*; >> --- old/test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java >> 2015-08-20 10:39:42.973041635 -0700 >> +++ new/test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java >> 2015-08-20 10:39:42.817041631 -0700 >> @@ -28,6 +28,7 @@ >> * even if destroy() or reset() methods is not invoked. >> * >> * @run main JpegWriterLeakTest >> + * @key randomness >> */ >> >> import java.awt.Color; >> --- old/test/javax/imageio/plugins/png/ShortHistogramTest.java >> 2015-08-20 10:39:43.345041645 -0700 >> +++ new/test/javax/imageio/plugins/png/ShortHistogramTest.java >> 2015-08-20 10:39:43.193041641 -0700 >> @@ -28,6 +28,7 @@ >> * hIST chunk if length of image palette in not power of two. >> * >> * @run main ShortHistogramTest 15 >> + * @key randomness >> */ >> >> import java.awt.Color; >> --- >> old/test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java >> 2015-08-20 10:39:43.717041654 -0700 >> +++ >> new/test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java >> 2015-08-20 10:39:43.569041650 -0700 >> @@ -24,6 +24,7 @@ >> /* @test >> @summary Test SoftFilter processAudio method >> @modules java.desktop/com.sun.media.sound >> + @key randomness >> */ >> >> import java.io.File; >> --- old/test/javax/sound/sampled/FileWriter/AlawEncoderSync.java >> 2015-08-20 10:39:44.093041664 -0700 >> +++ new/test/javax/sound/sampled/FileWriter/AlawEncoderSync.java >> 2015-08-20 10:39:43.941041660 -0700 >> @@ -27,6 +27,7 @@ >> * @bug 7058852 >> * @summary Tests that Alaw encoder works properly in multithreaded >> environment >> * @author Alex Menkov >> + * @key randomness >> */ >> >> import java.io.ByteArrayInputStream; >> --- old/test/javax/swing/JColorChooser/Test4165217.java 2015-08-20 >> 10:39:44.461041673 -0700 >> +++ new/test/javax/swing/JColorChooser/Test4165217.java 2015-08-20 >> 10:39:44.309041669 -0700 >> @@ -26,6 +26,7 @@ >> * @bug 4165217 >> * @summary Tests JColorChooser serialization >> * @author Ilya Boyandin >> + * @key randomness >> */ >> >> import java.awt.Color; >> --- old/test/javax/swing/JFileChooser/6868611/bug6868611.java >> 2015-08-20 10:39:44.833041683 -0700 >> +++ new/test/javax/swing/JFileChooser/6868611/bug6868611.java >> 2015-08-20 10:39:44.681041679 -0700 >> @@ -26,6 +26,7 @@ >> @summary FileSystemView throws NullPointerException >> @author Pavel Porvatov >> @run main bug6868611 >> + @key randomness >> */ >> >> import javax.swing.*; >> --- old/test/javax/swing/JFrame/4962534/bug4962534.java 2015-08-20 >> 10:39:45.205041692 -0700 >> +++ new/test/javax/swing/JFrame/4962534/bug4962534.java 2015-08-20 >> 10:39:45.053041688 -0700 >> @@ -27,6 +27,7 @@ >> @summary JFrame dances very badly >> @author dav at sparc.spb.su area= >> @run applet bug4962534.html >> + @key randomness >> */ >> import java.applet.Applet; >> import java.awt.*; >> --- old/test/javax/swing/system/6799345/TestShutdown.java 2015-08-20 >> 10:39:45.577041702 -0700 >> +++ new/test/javax/swing/system/6799345/TestShutdown.java 2015-08-20 >> 10:39:45.433041698 -0700 >> @@ -28,6 +28,7 @@ >> @author art >> @modules java.desktop/sun.awt >> @run main TestShutdown >> + @key randomness >> */ >> >> import java.awt.*; >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Aug 20 18:52:18 2015 From: philip.race at oracle.com (Phil Race) Date: Thu, 20 Aug 2015 11:52:18 -0700 Subject: JDK 9 RFR of JDK-8134084: Mark client libs regression tests using randomness In-Reply-To: <55D62029.9020103@oracle.com> References: <55D612B7.4010001@oracle.com> <55D618F9.3020404@oracle.com> <55D62029.9020103@oracle.com> Message-ID: <55D621E2.9070305@oracle.com> So randomness is a keyword that is read by a human and interpreted in the process of filing a bug on the test ? The one I pointed out does not seem like it needs this treatment. If it fails there is nothing to argue about. A crash is pretty conclusive. So the others probably ought to be examined too. I would prefer that we not label tests just based on grep output. -phil. On 8/20/2015 11:44 AM, joe darcy wrote: > Hi Phil, > > On 8/20/2015 11:14 AM, Phil Race wrote: >> Joe, >> >> How is this keyword interpreted and used ? > > From the TEST.ROOT file in the jdk/test directory: > > # The "randomness" keyword marks tests using randomness with test > # cases differing from run to run. (A test using a fixed random seed > # would not count as "randomness" by this definition.) Extra care > # should be taken to handle test failures of intermittent or > # randomness tests. > >> How did you select the tests below to be so marked ? > > Running the command > > find java/awt java/beans/ javax/swing/ javax/imageio/ javax/sound > -type f | xargs grep -l -i random > > and looking for cases were randomness was used such as extracting > values from a Random or SecureRandom object. In particular, test just > using random-access-file and the like did get tagged with the keyword. > >> I might ask more once I understand the answers to these but looking >> at just one of these - MTGraphicsAccessTest.java - there is no such >> thing a spurious failure of this test. If you ever see a failure that >> is a real >> bug. Perhaps all the passes are spurious if there is in fact a bug >> somewhere that would cause a crash but the test is not catching >> it but that does not seem like a reason to exclude the test - assuming >> that is what this keyword will be used for. > > We've seen cases elsewhere where using a random number generator has > obscured the cause of a intermittent test failure or a true product > bug. If a test using randomness fails intermittently, then its random > number generator should be switched over to a utility random number > generator which always prints out the seed and allows the seed to be > set. We've had a number of fixes in core libs from following this > policy, including JDK-8022224 and JDK-6854417 > > HTH, > > -Joe > >> >> -phil. >> >> On 08/20/2015 10:47 AM, joe darcy wrote: >>> Hello, >>> >>> As part of implementing tiered testing [1], client library tests >>> which use randomness should be marked with the corresponding >>> keyword. The analogous changes have been made in core libs, see >>> JDK-8078334: Mark regression tests using randomness. >>> >>> Webrev at >>> >>> JDK-8134084 : Mark client libs regression tests using randomness >>> http://cr.openjdk.java.net/~darcy/8134084.0/ >>> >>> and patch below. >>> >>> Thanks, >>> >>> -Joe >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html >>> >>> --- >>> old/test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java >>> 2015-08-20 10:39:36.425041467 -0700 >>> +++ >>> new/test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java >>> 2015-08-20 10:39:36.273041463 -0700 >>> @@ -30,6 +30,7 @@ >>> * @library ../../regtesthelpers >>> * @build Util >>> * @run main LoopRobustness >>> + * @key randomness >>> */ >>> >>> import java.awt.*; >>> --- >>> old/test/java/awt/FullScreen/AltTabCrashTest/AltTabCrashTest.java >>> 2015-08-20 10:39:36.805041477 -0700 >>> +++ >>> new/test/java/awt/FullScreen/AltTabCrashTest/AltTabCrashTest.java >>> 2015-08-20 10:39:36.653041473 -0700 >>> @@ -31,6 +31,7 @@ >>> @run main/othervm/timeout=100 -Dsun.java2d.d3d=True >>> AltTabCrashTest -auto -changedm >>> @run main/othervm/timeout=100 -Dsun.java2d.d3d=True >>> AltTabCrashTest -auto -usebs -changedm >>> @run main/othervm/timeout=100 -Dsun.java2d.opengl=True >>> AltTabCrashTest -auto >>> + @key randomness >>> */ >>> >>> import java.awt.AWTException; >>> --- >>> old/test/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java >>> 2015-08-20 10:39:37.193041487 -0700 >>> +++ >>> new/test/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java >>> 2015-08-20 10:39:37.041041483 -0700 >>> @@ -29,6 +29,7 @@ >>> * @run main/othervm/timeout=200 DisplayChangeVITest >>> * @run main/othervm/timeout=200 -Dsun.java2d.d3d=false >>> DisplayChangeVITest >>> * @run main/othervm/timeout=200 -Dsun.java2d.opengl=true >>> DisplayChangeVITest >>> + * @key randomness >>> */ >>> >>> import java.awt.Color; >>> --- >>> old/test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java >>> 2015-08-20 10:39:37.577041497 -0700 >>> +++ >>> new/test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java >>> 2015-08-20 10:39:37.425041493 -0700 >>> @@ -50,6 +50,7 @@ >>> * @run main/manual/othervm -Dsun.java2d.d3d=True >>> MultimonFullscreenTest >>> * @run main/manual/othervm -Dsun.java2d.noddraw=true >>> MultimonFullscreenTest >>> * @run main/manual/othervm -Dsun.java2d.opengl=True >>> MultimonFullscreenTest >>> + * @key randomness >>> */ >>> >>> import java.awt.Button; >>> --- >>> old/test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java >>> 2015-08-20 10:39:37.957041506 -0700 >>> +++ >>> new/test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java >>> 2015-08-20 10:39:37.797041502 -0700 >>> @@ -29,6 +29,7 @@ >>> >>> @author Dmitri.Trembovetski at sun.com area=Graphics >>> @run main MTGraphicsAccessTest >>> + @key randomness >>> */ >>> >>> import java.awt.*; >>> --- old/test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java >>> 2015-08-20 10:39:38.333041516 -0700 >>> +++ new/test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java >>> 2015-08-20 10:39:38.185041512 -0700 >>> @@ -27,6 +27,7 @@ >>> * @summary Tests clipping invariance for AA rectangle and line >>> primitives >>> * @run main RenderClipTest -strict -readfile 6766342.tests >>> * @run main RenderClipTest -rectsuite -count 10 >>> + * @key randomness >>> */ >>> >>> import java.awt.*; >>> --- >>> old/test/java/awt/GridLayout/ComponentPreferredSize/ComponentPreferredSize.java >>> 2015-08-20 10:39:38.765041527 -0700 >>> +++ >>> new/test/java/awt/GridLayout/ComponentPreferredSize/ComponentPreferredSize.java >>> 2015-08-20 10:39:38.569041522 -0700 >>> @@ -36,6 +36,7 @@ >>> * @build ExtendedRobot >>> * @run main ComponentPreferredSize >>> * @run main ComponentPreferredSize -hg 20 -vg 20 >>> + * @key randomness >>> */ >>> >>> public class ComponentPreferredSize { >>> --- old/test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java >>> 2015-08-20 10:39:39.169041537 -0700 >>> +++ new/test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java >>> 2015-08-20 10:39:39.017041534 -0700 >>> @@ -46,6 +46,7 @@ >>> * @library ../../../../lib/testlibrary >>> * @build Common ExtendedRobot >>> * @run main Shaped >>> + * @key randomness >>> */ >>> public class Shaped extends Common{ >>> >>> --- >>> old/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java 2015-08-20 >>> 10:39:39.549041547 -0700 >>> +++ >>> new/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java 2015-08-20 >>> 10:39:39.397041543 -0700 >>> @@ -44,6 +44,7 @@ >>> * @author Dmitriy Ermashov (dmitriy.ermashov at oracle.com) >>> * @library ../../../../lib/testlibrary >>> * @run main ShapedByAPI >>> + * @key randomness >>> */ >>> public class ShapedByAPI extends Common { >>> >>> --- >>> old/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java >>> 2015-08-20 10:39:39.933041557 -0700 >>> +++ >>> new/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java >>> 2015-08-20 10:39:39.777041553 -0700 >>> @@ -45,6 +45,7 @@ >>> * @library ../../../../lib/testlibrary >>> * @build Common ExtendedRobot >>> * @run main ShapedTranslucent >>> + * @key randomness >>> */ >>> public class ShapedTranslucent extends Common { >>> >>> --- >>> old/test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >>> 2015-08-20 10:39:40.313041567 -0700 >>> +++ >>> new/test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >>> 2015-08-20 10:39:40.161041563 -0700 >>> @@ -45,6 +45,7 @@ >>> * @library ../../../../lib/testlibrary >>> * @build Common ExtendedRobot >>> * @run main StaticallyShaped >>> + * @key randomness >>> */ >>> >>> public class StaticallyShaped extends Common { >>> --- >>> old/test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java 2015-08-20 >>> 10:39:40.697041577 -0700 >>> +++ >>> new/test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java 2015-08-20 >>> 10:39:40.545041573 -0700 >>> @@ -43,6 +43,7 @@ >>> * @library ../../../../lib/testlibrary >>> * @build Common ExtendedRobot >>> * @run main Translucent >>> + * @key randomness >>> */ >>> public class Translucent extends Common { >>> >>> --- >>> old/test/java/awt/Window/setLocRelativeTo/SetLocationRelativeToTest.java >>> 2015-08-20 10:39:41.077041586 -0700 >>> +++ >>> new/test/java/awt/Window/setLocRelativeTo/SetLocationRelativeToTest.java >>> 2015-08-20 10:39:40.921041582 -0700 >>> @@ -34,6 +34,7 @@ >>> @library ../../../../lib/testlibrary >>> @build ExtendedRobot >>> @run main/timeout=1200 SetLocationRelativeToTest >>> + at key randomness >>> */ >>> >>> public class SetLocationRelativeToTest { >>> --- old/test/java/awt/font/LineBreakMeasurer/FRCTest.java 2015-08-20 >>> 10:39:41.461041596 -0700 >>> +++ new/test/java/awt/font/LineBreakMeasurer/FRCTest.java 2015-08-20 >>> 10:39:41.309041592 -0700 >>> @@ -26,6 +26,7 @@ >>> * @bug 6448405 6519513 6745225 >>> * @summary static HashMap cache in LineBreakMeasurer can grow >>> wihout bounds >>> * @run main/othervm/timeout=600 -client -Xms16m -Xmx16m FRCTest >>> + * @key randomness >>> */ >>> import java.awt.*; >>> import java.awt.image.*; >>> --- old/test/java/awt/geom/AffineTransform/GetTypeOptimization.java >>> 2015-08-20 10:39:41.845041606 -0700 >>> +++ new/test/java/awt/geom/AffineTransform/GetTypeOptimization.java >>> 2015-08-20 10:39:41.689041602 -0700 >>> @@ -29,6 +29,7 @@ >>> * This test also confirms that isIdentity() returns the >>> * optimal value under all histories of modification. >>> * @run main GetTypeOptimization >>> + * @key randomness >>> */ >>> >>> import java.awt.geom.AffineTransform; >>> --- old/test/java/awt/geom/AffineTransform/TestRotateMethods.java >>> 2015-08-20 10:39:42.221041616 -0700 >>> +++ new/test/java/awt/geom/AffineTransform/TestRotateMethods.java >>> 2015-08-20 10:39:42.073041612 -0700 >>> @@ -36,6 +36,7 @@ >>> * >>> * @author flar >>> * @run main TestRotateMethods >>> + * @key randomness >>> */ >>> >>> import java.awt.geom.AffineTransform; >>> --- old/test/java/awt/image/BufferedImage/TinyScale.java 2015-08-20 >>> 10:39:42.593041625 -0700 >>> +++ new/test/java/awt/image/BufferedImage/TinyScale.java 2015-08-20 >>> 10:39:42.445041622 -0700 >>> @@ -22,9 +22,10 @@ >>> */ >>> >>> /* >>> - * @test %W% %E% >>> + * @test >>> * @bug 7016495 >>> * @summary Test tiny scales of BufferedImage >>> + * @key randomness >>> */ >>> >>> import java.awt.*; >>> --- old/test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java >>> 2015-08-20 10:39:42.973041635 -0700 >>> +++ new/test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java >>> 2015-08-20 10:39:42.817041631 -0700 >>> @@ -28,6 +28,7 @@ >>> * even if destroy() or reset() methods is not invoked. >>> * >>> * @run main JpegWriterLeakTest >>> + * @key randomness >>> */ >>> >>> import java.awt.Color; >>> --- old/test/javax/imageio/plugins/png/ShortHistogramTest.java >>> 2015-08-20 10:39:43.345041645 -0700 >>> +++ new/test/javax/imageio/plugins/png/ShortHistogramTest.java >>> 2015-08-20 10:39:43.193041641 -0700 >>> @@ -28,6 +28,7 @@ >>> * hIST chunk if length of image palette in not power of two. >>> * >>> * @run main ShortHistogramTest 15 >>> + * @key randomness >>> */ >>> >>> import java.awt.Color; >>> --- >>> old/test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java >>> 2015-08-20 10:39:43.717041654 -0700 >>> +++ >>> new/test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java >>> 2015-08-20 10:39:43.569041650 -0700 >>> @@ -24,6 +24,7 @@ >>> /* @test >>> @summary Test SoftFilter processAudio method >>> @modules java.desktop/com.sun.media.sound >>> + @key randomness >>> */ >>> >>> import java.io.File; >>> --- old/test/javax/sound/sampled/FileWriter/AlawEncoderSync.java >>> 2015-08-20 10:39:44.093041664 -0700 >>> +++ new/test/javax/sound/sampled/FileWriter/AlawEncoderSync.java >>> 2015-08-20 10:39:43.941041660 -0700 >>> @@ -27,6 +27,7 @@ >>> * @bug 7058852 >>> * @summary Tests that Alaw encoder works properly in multithreaded >>> environment >>> * @author Alex Menkov >>> + * @key randomness >>> */ >>> >>> import java.io.ByteArrayInputStream; >>> --- old/test/javax/swing/JColorChooser/Test4165217.java 2015-08-20 >>> 10:39:44.461041673 -0700 >>> +++ new/test/javax/swing/JColorChooser/Test4165217.java 2015-08-20 >>> 10:39:44.309041669 -0700 >>> @@ -26,6 +26,7 @@ >>> * @bug 4165217 >>> * @summary Tests JColorChooser serialization >>> * @author Ilya Boyandin >>> + * @key randomness >>> */ >>> >>> import java.awt.Color; >>> --- old/test/javax/swing/JFileChooser/6868611/bug6868611.java >>> 2015-08-20 10:39:44.833041683 -0700 >>> +++ new/test/javax/swing/JFileChooser/6868611/bug6868611.java >>> 2015-08-20 10:39:44.681041679 -0700 >>> @@ -26,6 +26,7 @@ >>> @summary FileSystemView throws NullPointerException >>> @author Pavel Porvatov >>> @run main bug6868611 >>> + @key randomness >>> */ >>> >>> import javax.swing.*; >>> --- old/test/javax/swing/JFrame/4962534/bug4962534.java 2015-08-20 >>> 10:39:45.205041692 -0700 >>> +++ new/test/javax/swing/JFrame/4962534/bug4962534.java 2015-08-20 >>> 10:39:45.053041688 -0700 >>> @@ -27,6 +27,7 @@ >>> @summary JFrame dances very badly >>> @author dav at sparc.spb.su area= >>> @run applet bug4962534.html >>> + @key randomness >>> */ >>> import java.applet.Applet; >>> import java.awt.*; >>> --- old/test/javax/swing/system/6799345/TestShutdown.java 2015-08-20 >>> 10:39:45.577041702 -0700 >>> +++ new/test/javax/swing/system/6799345/TestShutdown.java 2015-08-20 >>> 10:39:45.433041698 -0700 >>> @@ -28,6 +28,7 @@ >>> @author art >>> @modules java.desktop/sun.awt >>> @run main TestShutdown >>> + @key randomness >>> */ >>> >>> import java.awt.*; >>> >> > From peter.brunet at oracle.com Thu Aug 20 19:16:00 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 20 Aug 2015 14:16:00 -0500 Subject: RfR: JDK-8133897, IndexOutOfBounds exception being thrown In-Reply-To: <55D4FB9C.4000104@oracle.com> References: <55D4FA20.2070609@oracle.com> <55D4FB9C.4000104@oracle.com> Message-ID: <55D62770.102@oracle.com> Is this fix trivial enough to qualify for the noreg-trivial tag? On 8/19/15 4:56 PM, Pete Brunet wrote: > > > On 8/19/15 4:50 PM, Pete Brunet wrote: >> Please review this patch. >> http://cr.openjdk.java.net/~ptbrunet/JDK-8133897/webrev.00/ >> >> The issue is that the application has a tab with a visible title but >> for some reason JTabbedPane's title field was "". This caused >> indexOfTab(title) to return -1 and then getTabBounds(parent, -1) >> raised ArrayIndexOutOfBoundsException. >> >> >> public Rectangle getBounds() { >> - return parent.getUI().getTabBounds(parent, >> - >> parent.indexOfTab(title)); >> + int i = parent.indexOfTab(title); >> + Rectangle r; >> + // Check for no title. Even though that's a bug in the >> app we should >> + // inhibit an ArrayIndexOutOfBoundsException from >> getTabBounds. >> + if (i == -1) { >> + r = null; >> + } else { >> + r = parent.getUI().getTabBounds(parent, i); >> + } >> + return r; > I suppose that could have been return (i == -1) ? null : > parent.getUI().getTabBounds(parent, i); >> } >> >> Maybe someone more familiar with the code can see a bug related to >> why title is allowed to be "" when there is a visible title displayed >> in the tab. The bug I am working was raised during use of an app for >> which we do not have access so its source is not available. >> >> Thanks, Pete > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Thu Aug 20 20:04:02 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 20 Aug 2015 13:04:02 -0700 Subject: JDK 9 RFR of JDK-8134084: Mark client libs regression tests using randomness In-Reply-To: <55D621E2.9070305@oracle.com> References: <55D612B7.4010001@oracle.com> <55D618F9.3020404@oracle.com> <55D62029.9020103@oracle.com> <55D621E2.9070305@oracle.com> Message-ID: <55D632B2.8000103@oracle.com> On 8/20/2015 11:52 AM, Phil Race wrote: > So randomness is a keyword that is read by a human and interpreted in the > process of filing a bug on the test ? Yes, the randomness keyword is a message to the human reader of the test or someone doing analysis of a test failure. The connotation of the keyword is informative rather than pejorative. > > The one I pointed out does not seem like it needs this treatment. > If it fails there is nothing to argue about. A crash is pretty > conclusive. > So the others probably ought to be examined too. I would prefer that > we not label tests just based on grep output. I look at every test file sent out for review. This is the same methodology I followed when marking several hundred tests in core libs: http://cr.openjdk.java.net/~darcy/8078334.0/ The test in question uses randomness to determine the sleep time: private void mysleep(long time) { try { // add +/-5ms variance to increase randomness Thread.sleep(time + (long)(5 - Math.random()*10)); } catch (InterruptedException e) {}; } -Joe > > -phil. > > On 8/20/2015 11:44 AM, joe darcy wrote: >> Hi Phil, >> >> On 8/20/2015 11:14 AM, Phil Race wrote: >>> Joe, >>> >>> How is this keyword interpreted and used ? >> >> From the TEST.ROOT file in the jdk/test directory: >> >> # The "randomness" keyword marks tests using randomness with test >> # cases differing from run to run. (A test using a fixed random seed >> # would not count as "randomness" by this definition.) Extra care >> # should be taken to handle test failures of intermittent or >> # randomness tests. >> >>> How did you select the tests below to be so marked ? >> >> Running the command >> >> find java/awt java/beans/ javax/swing/ javax/imageio/ javax/sound >> -type f | xargs grep -l -i random >> >> and looking for cases were randomness was used such as extracting >> values from a Random or SecureRandom object. In particular, test just >> using random-access-file and the like did get tagged with the keyword. >> >>> I might ask more once I understand the answers to these but looking >>> at just one of these - MTGraphicsAccessTest.java - there is no such >>> thing a spurious failure of this test. If you ever see a failure >>> that is a real >>> bug. Perhaps all the passes are spurious if there is in fact a bug >>> somewhere that would cause a crash but the test is not catching >>> it but that does not seem like a reason to exclude the test - assuming >>> that is what this keyword will be used for. >> >> We've seen cases elsewhere where using a random number generator has >> obscured the cause of a intermittent test failure or a true product >> bug. If a test using randomness fails intermittently, then its random >> number generator should be switched over to a utility random number >> generator which always prints out the seed and allows the seed to be >> set. We've had a number of fixes in core libs from following this >> policy, including JDK-8022224 and JDK-6854417 >> >> HTH, >> >> -Joe >> >>> >>> -phil. >>> >>> On 08/20/2015 10:47 AM, joe darcy wrote: >>>> Hello, >>>> >>>> As part of implementing tiered testing [1], client library tests >>>> which use randomness should be marked with the corresponding >>>> keyword. The analogous changes have been made in core libs, see >>>> JDK-8078334: Mark regression tests using randomness. >>>> >>>> Webrev at >>>> >>>> JDK-8134084 : Mark client libs regression tests using randomness >>>> http://cr.openjdk.java.net/~darcy/8134084.0/ >>>> >>>> and patch below. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html >>>> >>>> --- >>>> old/test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java >>>> 2015-08-20 10:39:36.425041467 -0700 >>>> +++ >>>> new/test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java >>>> 2015-08-20 10:39:36.273041463 -0700 >>>> @@ -30,6 +30,7 @@ >>>> * @library ../../regtesthelpers >>>> * @build Util >>>> * @run main LoopRobustness >>>> + * @key randomness >>>> */ >>>> >>>> import java.awt.*; >>>> --- >>>> old/test/java/awt/FullScreen/AltTabCrashTest/AltTabCrashTest.java >>>> 2015-08-20 10:39:36.805041477 -0700 >>>> +++ >>>> new/test/java/awt/FullScreen/AltTabCrashTest/AltTabCrashTest.java >>>> 2015-08-20 10:39:36.653041473 -0700 >>>> @@ -31,6 +31,7 @@ >>>> @run main/othervm/timeout=100 -Dsun.java2d.d3d=True >>>> AltTabCrashTest -auto -changedm >>>> @run main/othervm/timeout=100 -Dsun.java2d.d3d=True >>>> AltTabCrashTest -auto -usebs -changedm >>>> @run main/othervm/timeout=100 -Dsun.java2d.opengl=True >>>> AltTabCrashTest -auto >>>> + @key randomness >>>> */ >>>> >>>> import java.awt.AWTException; >>>> --- >>>> old/test/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java >>>> 2015-08-20 10:39:37.193041487 -0700 >>>> +++ >>>> new/test/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java >>>> 2015-08-20 10:39:37.041041483 -0700 >>>> @@ -29,6 +29,7 @@ >>>> * @run main/othervm/timeout=200 DisplayChangeVITest >>>> * @run main/othervm/timeout=200 -Dsun.java2d.d3d=false >>>> DisplayChangeVITest >>>> * @run main/othervm/timeout=200 -Dsun.java2d.opengl=true >>>> DisplayChangeVITest >>>> + * @key randomness >>>> */ >>>> >>>> import java.awt.Color; >>>> --- >>>> old/test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java >>>> 2015-08-20 10:39:37.577041497 -0700 >>>> +++ >>>> new/test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java >>>> 2015-08-20 10:39:37.425041493 -0700 >>>> @@ -50,6 +50,7 @@ >>>> * @run main/manual/othervm -Dsun.java2d.d3d=True >>>> MultimonFullscreenTest >>>> * @run main/manual/othervm -Dsun.java2d.noddraw=true >>>> MultimonFullscreenTest >>>> * @run main/manual/othervm -Dsun.java2d.opengl=True >>>> MultimonFullscreenTest >>>> + * @key randomness >>>> */ >>>> >>>> import java.awt.Button; >>>> --- >>>> old/test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java >>>> 2015-08-20 10:39:37.957041506 -0700 >>>> +++ >>>> new/test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java >>>> 2015-08-20 10:39:37.797041502 -0700 >>>> @@ -29,6 +29,7 @@ >>>> >>>> @author Dmitri.Trembovetski at sun.com area=Graphics >>>> @run main MTGraphicsAccessTest >>>> + @key randomness >>>> */ >>>> >>>> import java.awt.*; >>>> --- old/test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java >>>> 2015-08-20 10:39:38.333041516 -0700 >>>> +++ new/test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java >>>> 2015-08-20 10:39:38.185041512 -0700 >>>> @@ -27,6 +27,7 @@ >>>> * @summary Tests clipping invariance for AA rectangle and line >>>> primitives >>>> * @run main RenderClipTest -strict -readfile 6766342.tests >>>> * @run main RenderClipTest -rectsuite -count 10 >>>> + * @key randomness >>>> */ >>>> >>>> import java.awt.*; >>>> --- >>>> old/test/java/awt/GridLayout/ComponentPreferredSize/ComponentPreferredSize.java >>>> 2015-08-20 10:39:38.765041527 -0700 >>>> +++ >>>> new/test/java/awt/GridLayout/ComponentPreferredSize/ComponentPreferredSize.java >>>> 2015-08-20 10:39:38.569041522 -0700 >>>> @@ -36,6 +36,7 @@ >>>> * @build ExtendedRobot >>>> * @run main ComponentPreferredSize >>>> * @run main ComponentPreferredSize -hg 20 -vg 20 >>>> + * @key randomness >>>> */ >>>> >>>> public class ComponentPreferredSize { >>>> --- >>>> old/test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java >>>> 2015-08-20 10:39:39.169041537 -0700 >>>> +++ >>>> new/test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java >>>> 2015-08-20 10:39:39.017041534 -0700 >>>> @@ -46,6 +46,7 @@ >>>> * @library ../../../../lib/testlibrary >>>> * @build Common ExtendedRobot >>>> * @run main Shaped >>>> + * @key randomness >>>> */ >>>> public class Shaped extends Common{ >>>> >>>> --- >>>> old/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java >>>> 2015-08-20 10:39:39.549041547 -0700 >>>> +++ >>>> new/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java >>>> 2015-08-20 10:39:39.397041543 -0700 >>>> @@ -44,6 +44,7 @@ >>>> * @author Dmitriy Ermashov (dmitriy.ermashov at oracle.com) >>>> * @library ../../../../lib/testlibrary >>>> * @run main ShapedByAPI >>>> + * @key randomness >>>> */ >>>> public class ShapedByAPI extends Common { >>>> >>>> --- >>>> old/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java >>>> 2015-08-20 10:39:39.933041557 -0700 >>>> +++ >>>> new/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java >>>> 2015-08-20 10:39:39.777041553 -0700 >>>> @@ -45,6 +45,7 @@ >>>> * @library ../../../../lib/testlibrary >>>> * @build Common ExtendedRobot >>>> * @run main ShapedTranslucent >>>> + * @key randomness >>>> */ >>>> public class ShapedTranslucent extends Common { >>>> >>>> --- >>>> old/test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >>>> 2015-08-20 10:39:40.313041567 -0700 >>>> +++ >>>> new/test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java >>>> 2015-08-20 10:39:40.161041563 -0700 >>>> @@ -45,6 +45,7 @@ >>>> * @library ../../../../lib/testlibrary >>>> * @build Common ExtendedRobot >>>> * @run main StaticallyShaped >>>> + * @key randomness >>>> */ >>>> >>>> public class StaticallyShaped extends Common { >>>> --- >>>> old/test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java >>>> 2015-08-20 10:39:40.697041577 -0700 >>>> +++ >>>> new/test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java >>>> 2015-08-20 10:39:40.545041573 -0700 >>>> @@ -43,6 +43,7 @@ >>>> * @library ../../../../lib/testlibrary >>>> * @build Common ExtendedRobot >>>> * @run main Translucent >>>> + * @key randomness >>>> */ >>>> public class Translucent extends Common { >>>> >>>> --- >>>> old/test/java/awt/Window/setLocRelativeTo/SetLocationRelativeToTest.java >>>> 2015-08-20 10:39:41.077041586 -0700 >>>> +++ >>>> new/test/java/awt/Window/setLocRelativeTo/SetLocationRelativeToTest.java >>>> 2015-08-20 10:39:40.921041582 -0700 >>>> @@ -34,6 +34,7 @@ >>>> @library ../../../../lib/testlibrary >>>> @build ExtendedRobot >>>> @run main/timeout=1200 SetLocationRelativeToTest >>>> + at key randomness >>>> */ >>>> >>>> public class SetLocationRelativeToTest { >>>> --- old/test/java/awt/font/LineBreakMeasurer/FRCTest.java >>>> 2015-08-20 10:39:41.461041596 -0700 >>>> +++ new/test/java/awt/font/LineBreakMeasurer/FRCTest.java >>>> 2015-08-20 10:39:41.309041592 -0700 >>>> @@ -26,6 +26,7 @@ >>>> * @bug 6448405 6519513 6745225 >>>> * @summary static HashMap cache in LineBreakMeasurer can grow >>>> wihout bounds >>>> * @run main/othervm/timeout=600 -client -Xms16m -Xmx16m FRCTest >>>> + * @key randomness >>>> */ >>>> import java.awt.*; >>>> import java.awt.image.*; >>>> --- old/test/java/awt/geom/AffineTransform/GetTypeOptimization.java >>>> 2015-08-20 10:39:41.845041606 -0700 >>>> +++ new/test/java/awt/geom/AffineTransform/GetTypeOptimization.java >>>> 2015-08-20 10:39:41.689041602 -0700 >>>> @@ -29,6 +29,7 @@ >>>> * This test also confirms that isIdentity() returns the >>>> * optimal value under all histories of modification. >>>> * @run main GetTypeOptimization >>>> + * @key randomness >>>> */ >>>> >>>> import java.awt.geom.AffineTransform; >>>> --- old/test/java/awt/geom/AffineTransform/TestRotateMethods.java >>>> 2015-08-20 10:39:42.221041616 -0700 >>>> +++ new/test/java/awt/geom/AffineTransform/TestRotateMethods.java >>>> 2015-08-20 10:39:42.073041612 -0700 >>>> @@ -36,6 +36,7 @@ >>>> * >>>> * @author flar >>>> * @run main TestRotateMethods >>>> + * @key randomness >>>> */ >>>> >>>> import java.awt.geom.AffineTransform; >>>> --- old/test/java/awt/image/BufferedImage/TinyScale.java 2015-08-20 >>>> 10:39:42.593041625 -0700 >>>> +++ new/test/java/awt/image/BufferedImage/TinyScale.java 2015-08-20 >>>> 10:39:42.445041622 -0700 >>>> @@ -22,9 +22,10 @@ >>>> */ >>>> >>>> /* >>>> - * @test %W% %E% >>>> + * @test >>>> * @bug 7016495 >>>> * @summary Test tiny scales of BufferedImage >>>> + * @key randomness >>>> */ >>>> >>>> import java.awt.*; >>>> --- old/test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java >>>> 2015-08-20 10:39:42.973041635 -0700 >>>> +++ new/test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java >>>> 2015-08-20 10:39:42.817041631 -0700 >>>> @@ -28,6 +28,7 @@ >>>> * even if destroy() or reset() methods is not invoked. >>>> * >>>> * @run main JpegWriterLeakTest >>>> + * @key randomness >>>> */ >>>> >>>> import java.awt.Color; >>>> --- old/test/javax/imageio/plugins/png/ShortHistogramTest.java >>>> 2015-08-20 10:39:43.345041645 -0700 >>>> +++ new/test/javax/imageio/plugins/png/ShortHistogramTest.java >>>> 2015-08-20 10:39:43.193041641 -0700 >>>> @@ -28,6 +28,7 @@ >>>> * hIST chunk if length of image palette in not power of >>>> two. >>>> * >>>> * @run main ShortHistogramTest 15 >>>> + * @key randomness >>>> */ >>>> >>>> import java.awt.Color; >>>> --- >>>> old/test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java >>>> 2015-08-20 10:39:43.717041654 -0700 >>>> +++ >>>> new/test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java >>>> 2015-08-20 10:39:43.569041650 -0700 >>>> @@ -24,6 +24,7 @@ >>>> /* @test >>>> @summary Test SoftFilter processAudio method >>>> @modules java.desktop/com.sun.media.sound >>>> + @key randomness >>>> */ >>>> >>>> import java.io.File; >>>> --- old/test/javax/sound/sampled/FileWriter/AlawEncoderSync.java >>>> 2015-08-20 10:39:44.093041664 -0700 >>>> +++ new/test/javax/sound/sampled/FileWriter/AlawEncoderSync.java >>>> 2015-08-20 10:39:43.941041660 -0700 >>>> @@ -27,6 +27,7 @@ >>>> * @bug 7058852 >>>> * @summary Tests that Alaw encoder works properly in >>>> multithreaded environment >>>> * @author Alex Menkov >>>> + * @key randomness >>>> */ >>>> >>>> import java.io.ByteArrayInputStream; >>>> --- old/test/javax/swing/JColorChooser/Test4165217.java 2015-08-20 >>>> 10:39:44.461041673 -0700 >>>> +++ new/test/javax/swing/JColorChooser/Test4165217.java 2015-08-20 >>>> 10:39:44.309041669 -0700 >>>> @@ -26,6 +26,7 @@ >>>> * @bug 4165217 >>>> * @summary Tests JColorChooser serialization >>>> * @author Ilya Boyandin >>>> + * @key randomness >>>> */ >>>> >>>> import java.awt.Color; >>>> --- old/test/javax/swing/JFileChooser/6868611/bug6868611.java >>>> 2015-08-20 10:39:44.833041683 -0700 >>>> +++ new/test/javax/swing/JFileChooser/6868611/bug6868611.java >>>> 2015-08-20 10:39:44.681041679 -0700 >>>> @@ -26,6 +26,7 @@ >>>> @summary FileSystemView throws NullPointerException >>>> @author Pavel Porvatov >>>> @run main bug6868611 >>>> + @key randomness >>>> */ >>>> >>>> import javax.swing.*; >>>> --- old/test/javax/swing/JFrame/4962534/bug4962534.java 2015-08-20 >>>> 10:39:45.205041692 -0700 >>>> +++ new/test/javax/swing/JFrame/4962534/bug4962534.java 2015-08-20 >>>> 10:39:45.053041688 -0700 >>>> @@ -27,6 +27,7 @@ >>>> @summary JFrame dances very badly >>>> @author dav at sparc.spb.su area= >>>> @run applet bug4962534.html >>>> + @key randomness >>>> */ >>>> import java.applet.Applet; >>>> import java.awt.*; >>>> --- old/test/javax/swing/system/6799345/TestShutdown.java >>>> 2015-08-20 10:39:45.577041702 -0700 >>>> +++ new/test/javax/swing/system/6799345/TestShutdown.java >>>> 2015-08-20 10:39:45.433041698 -0700 >>>> @@ -28,6 +28,7 @@ >>>> @author art >>>> @modules java.desktop/sun.awt >>>> @run main TestShutdown >>>> + @key randomness >>>> */ >>>> >>>> import java.awt.*; >>>> >>> >> > From WLaan at costengineering.eu Fri Aug 21 07:43:52 2015 From: WLaan at costengineering.eu (Walter Laan) Date: Fri, 21 Aug 2015 07:43:52 +0000 Subject: RfR: JDK-8133897, IndexOutOfBounds exception being thrown In-Reply-To: <55D62770.102@oracle.com> References: <55D4FA20.2070609@oracle.com> <55D4FB9C.4000104@oracle.com> <55D62770.102@oracle.com> Message-ID: <59CA7531B79CD24C9220F8C952EF389E19306839@EXCH2010.ce.local> The patch just changes the AIOOB to a NPE elsewhere, for example to a method just above: public Point getLocation() { Rectangle r = getBounds(); return new Point(r.x, r.y); } Seems like the only way for the exception to happen is because removeTabAt() or setTitleAt() is called from a different thread than the EDT. You could avoid the setTitleAt change, by using parent.pages.indexOf(this) although there might be a reason it is looked up by name everywhere. It would still fail if the tab is removed from another thread, but it probably should fail in that case since Swing is not thread safe. You could return an zero or negative sized rectangle, but that also might lead to problems elsewhere. Thanks, Walter From: swing-dev [mailto:swing-dev-bounces at openjdk.java.net] On Behalf Of Pete Brunet Sent: donderdag 20 augustus 2015 21:16 To: swing-dev at openjdk.java.net Subject: Re: RfR: JDK-8133897, IndexOutOfBounds exception being thrown Is this fix trivial enough to qualify for the noreg-trivial tag? On 8/19/15 4:56 PM, Pete Brunet wrote: On 8/19/15 4:50 PM, Pete Brunet wrote: Please review this patch. http://cr.openjdk.java.net/~ptbrunet/JDK-8133897/webrev.00/ The issue is that the application has a tab with a visible title but for some reason JTabbedPane's title field was "". This caused indexOfTab(title) to return -1 and then getTabBounds(parent, -1) raised ArrayIndexOutOfBoundsException. public Rectangle getBounds() { - return parent.getUI().getTabBounds(parent, - parent.indexOfTab(title)); + int i = parent.indexOfTab(title); + Rectangle r; + // Check for no title. Even though that's a bug in the app we should + // inhibit an ArrayIndexOutOfBoundsException from getTabBounds. + if (i == -1) { + r = null; + } else { + r = parent.getUI().getTabBounds(parent, i); + } + return r; I suppose that could have been return (i == -1) ? null : parent.getUI().getTabBounds(parent, i); } Maybe someone more familiar with the code can see a bug related to why title is allowed to be "" when there is a visible title displayed in the tab. The bug I am working was raised during use of an app for which we do not have access so its source is not available. Thanks, Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Aug 21 09:16:05 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 21 Aug 2015 12:16:05 +0300 Subject: RfR: JDK-8133897, IndexOutOfBounds exception being thrown In-Reply-To: <55D5EA24.2010502@oracle.com> References: <55D4FA20.2070609@oracle.com> <55D5EA24.2010502@oracle.com> Message-ID: <55D6EC55.6070802@oracle.com> The setTabComponentAt() method allows to set a component to a tabbed pane title. In the following example the tab title is "": tabbedPane.addTab(null, new JLabel("Content 1")); tabbedPane.setTabComponentAt(0, new JLabel("Title 1")); The getBounds() method can also try to find a tab index by tabComponent and by icon in case if indexOfTab(title) fails. Thanks, Alexandr. On 8/20/2015 5:54 PM, Alexander Scherbatiy wrote: > On 8/20/2015 12:50 AM, Pete Brunet wrote: >> Please review this patch. >> http://cr.openjdk.java.net/~ptbrunet/JDK-8133897/webrev.00/ >> >> The issue is that the application has a tab with a visible title but >> for some reason JTabbedPane's title field was "". This caused >> indexOfTab(title) to return -1 and then getTabBounds(parent, -1) >> raised ArrayIndexOutOfBoundsException. >> >> >> public Rectangle getBounds() { >> - return parent.getUI().getTabBounds(parent, >> - parent.indexOfTab(title)); >> + int i = parent.indexOfTab(title); >> + Rectangle r; >> + // Check for no title. Even though that's a bug in the >> app we should >> + // inhibit an ArrayIndexOutOfBoundsException from >> getTabBounds. >> + if (i == -1) { >> + r = null; >> + } else { >> + r = parent.getUI().getTabBounds(parent, i); >> + } >> + return r; >> } >> >> Maybe someone more familiar with the code can see a bug related to >> why title is allowed to be "" when there is a visible title displayed >> in the tab. The bug I am working was raised during use of an app for >> which we do not have access so its source is not available. > > It is possible to add icon with text so the title will be empty: > tabbedPane.addTab(null, icon, new JLabel("Content"). > But even in this case indexOfTab returns the first tab with null > title: tabbedPane.indexOfTab((String)null). > > Could it be that the tabbed pane title was changed between > JTabbedPane.Page class creation and getBounds() method invoking? > > Thanks, > Alexandr. >> >> Thanks, Pete > From Sergey.Bylokhov at oracle.com Fri Aug 21 10:04:37 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 21 Aug 2015 13:04:37 +0300 Subject: [9] Review Request: 4339584 Adding a getUI public method to JComponent Message-ID: <55D6F7B5.2080001@oracle.com> Hello. Please review a small fix for jdk9. Long long time ago the next request was filed for jdk 1.4.0: "Today, there is no way for a program to access the UI of a JComponent. Adding a getUI method would provide that capability and be consistent with the fact that, for example, the JComponent's Border is accessible" It was evaluated and was closed: "JComponent does not have a getUI so that each class can override it to return the UI that is appropriate for the class, such as TreeUI or TextUI..." The problem was in absent of covariant returns, which were added to the jdk 1.5. So now we can add the "ComponentUI getUI()" method to the JComponent and in the same time we will have an ability to override it using more specific return value in subclasses. Bug: https://bugs.openjdk.java.net/browse/JDK-4339584 Webrev can be found at: http://cr.openjdk.java.net/~serb/4339584/webrev.00 -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri Aug 21 10:10:11 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 21 Aug 2015 13:10:11 +0300 Subject: [9] Review Request: 4339584 Adding a getUI public method to JComponent In-Reply-To: <55D6F7B5.2080001@oracle.com> References: <55D6F7B5.2080001@oracle.com> Message-ID: <55D6F903.5010807@oracle.com> On 8/21/2015 1:04 PM, Sergey Bylokhov wrote: > Hello. > Please review a small fix for jdk9. > > Long long time ago the next request was filed for jdk 1.4.0: > "Today, there is no way for a program to access the UI of a > JComponent. Adding a getUI method would provide that capability and be > consistent with the fact that, for example, the JComponent's Border is > accessible" > > It was evaluated and was closed: > "JComponent does not have a getUI so that each class can override it > to return the UI that is appropriate for the class, such as TreeUI or > TextUI..." > > The problem was in absent of covariant returns, which were added to > the jdk 1.5. So now we can add the "ComponentUI getUI()" method to the > JComponent and in the same time we will have an ability to override it > using more specific return value in subclasses. Could it break a binary compatibility if someone does not follow the javadoc specification and has in his program getUI() method which return type is not subclass of the ComponentUI? Thanks, Alexandr. > > Bug: https://bugs.openjdk.java.net/browse/JDK-4339584 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/4339584/webrev.00 > From Sergey.Bylokhov at oracle.com Fri Aug 21 10:49:29 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 21 Aug 2015 13:49:29 +0300 Subject: [9] Review Request: 4339584 Adding a getUI public method to JComponent In-Reply-To: <55D6F903.5010807@oracle.com> References: <55D6F7B5.2080001@oracle.com> <55D6F903.5010807@oracle.com> Message-ID: <55D70239.8020805@oracle.com> I just double checked that if I compiles the subclass when the parent class has not this method, then recompiles a new parent, the correct method in subclass still called, so it seems fine. Probably there are some other cases, which will be checked during ccc review. > Could it break a binary compatibility if someone does not follow the > javadoc specification and has in his program getUI() method which > return type is not subclass of the ComponentUI? > > Thanks, > Alexandr. > >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-4339584 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/4339584/webrev.00 >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Aug 21 11:18:49 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 21 Aug 2015 14:18:49 +0300 Subject: [9] Review request for 6302464 Allow programmatic enabling of subpixel anti-aliasing in Swing In-Reply-To: <55CC8873.7030202@oracle.com> References: <55CC8873.7030202@oracle.com> Message-ID: <55D70919.8030205@oracle.com> Hi, Alexander. It seems this is only a part of the request. It does not cover some situations like java properties, which can be used to enable/set/disable anti-aliasing. Also it is unclear how and why our look and feels modify the desktop properties, this api seems private also. On 13.08.15 15:07, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-6302464 > webrev: http://cr.openjdk.java.net/~alexsch/6302464/webrev.00 > > Swing uses internal API to set antialiasing settings for L&Fs and > components. > > SwingUtilities2.AATextInfo aaTextInfo = new > SwingUtilities2.AATextInfo( > RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB, 140); > > UIManager.getDefaults().put(SwingUtilities2.AA_TEXT_PROPERTY_KEY, > aaTextInfo); // set aa hints globally > component.putClientProperty(SwingUtilities2.AA_TEXT_PROPERTY_KEY, > aaTextInfo); // set aa hints for a JComponent > > > There are some ways to provide a public mechanism for antialiasing > enabling in Swing: > > 1. Setting antialiasing rendering hints into UI defaults and component > client properties: > > UIManager.getDefaults().put(RenderingHints.KEY_TEXT_ANTIALIASING, > RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); > component.putClientProperty(RenderingHints.KEY_TEXT_ANTIALIASING, > RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); > > 2. Setting a map which contains antialiasing hints: > > Map aaHintsMap = new HashMap<>(); > aaHintsMap.put(RenderingHints.KEY_TEXT_ANTIALIASING, > RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); > > UIManager.getDefaults().put(AA_TEXT_PROPERTY_KEY, aaHintsMap); > component.putClientProperty(AA_TEXT_PROPERTY_KEY, aaHintsMap); > > 3. Information about antialiasing hints can be stored in a public class > > AATextInfo aaTextInfo = new > AATextInfo(RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB, 140); > UIManager.getDefaults().put(AA_TEXT_PROPERTY_KEY, aaTextInfo); > component.putClientProperty(AA_TEXT_PROPERTY_KEY, aaTextInfo); > > The proposed fix used the first approach. > > Thanks, > Alexandr. > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri Aug 21 11:20:32 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 21 Aug 2015 14:20:32 +0300 Subject: [9] Review Request: 4339584 Adding a getUI public method to JComponent In-Reply-To: <55D70239.8020805@oracle.com> References: <55D6F7B5.2080001@oracle.com> <55D6F903.5010807@oracle.com> <55D70239.8020805@oracle.com> Message-ID: <55D70980.5010701@oracle.com> On 8/21/2015 1:49 PM, Sergey Bylokhov wrote: > I just double checked that if I compiles the subclass when the parent > class has not this method, then recompiles a new parent, the correct > method in subclass still called, so it seems fine. Probably there are > some other cases, which will be checked during ccc review. I mean the following case: ------------------------------- public class CustomComponent extends JComponent { class CustomComponentUI {} CustomComponentUI getUI() { return null; } } ------------------------------- Thanks, Alexandr. > > >> Could it break a binary compatibility if someone does not follow the >> javadoc specification and has in his program getUI() method which >> return type is not subclass of the ComponentUI? >> >> Thanks, >> Alexandr. >> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-4339584 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/4339584/webrev.00 >>> >> > > From Sergey.Bylokhov at oracle.com Fri Aug 21 11:37:49 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 21 Aug 2015 14:37:49 +0300 Subject: [9] Review Request: 4339584 Adding a getUI public method to JComponent In-Reply-To: <55D70980.5010701@oracle.com> References: <55D6F7B5.2080001@oracle.com> <55D6F903.5010807@oracle.com> <55D70239.8020805@oracle.com> <55D70980.5010701@oracle.com> Message-ID: <55D70D8D.20200@oracle.com> On 21.08.15 14:20, Alexander Scherbatiy wrote: > On 8/21/2015 1:49 PM, Sergey Bylokhov wrote: >> I just double checked that if I compiles the subclass when the parent >> class has not this method, then recompiles a new parent, the correct >> method in subclass still called, so it seems fine. Probably there are >> some other cases, which will be checked during ccc review. > Yes this case will be broken, since this getter contradicts the specification described in JComponent.setUI. > I mean the following case: > ------------------------------- > public class CustomComponent extends JComponent { > > class CustomComponentUI {} > > CustomComponentUI getUI() { > return null; > } > } > ------------------------------- > > Thanks, > Alexandr. > >> >> >>> Could it break a binary compatibility if someone does not follow the >>> javadoc specification and has in his program getUI() method which >>> return type is not subclass of the ComponentUI? >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4339584 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/4339584/webrev.00 >>>> >>> >> >> > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri Aug 21 11:41:38 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 21 Aug 2015 14:41:38 +0300 Subject: [9] Review Request: 4339584 Adding a getUI public method to JComponent In-Reply-To: <55D70D8D.20200@oracle.com> References: <55D6F7B5.2080001@oracle.com> <55D6F903.5010807@oracle.com> <55D70239.8020805@oracle.com> <55D70980.5010701@oracle.com> <55D70D8D.20200@oracle.com> Message-ID: <55D70E72.80300@oracle.com> The fix looks good to me. Thanks, Alexandr. On 8/21/2015 2:37 PM, Sergey Bylokhov wrote: > On 21.08.15 14:20, Alexander Scherbatiy wrote: >> On 8/21/2015 1:49 PM, Sergey Bylokhov wrote: >>> I just double checked that if I compiles the subclass when the >>> parent class has not this method, then recompiles a new parent, the >>> correct method in subclass still called, so it seems fine. Probably >>> there are some other cases, which will be checked during ccc review. >> > Yes this case will be broken, since this getter contradicts the > specification described in JComponent.setUI. > >> I mean the following case: >> ------------------------------- >> public class CustomComponent extends JComponent { >> >> class CustomComponentUI {} >> >> CustomComponentUI getUI() { >> return null; >> } >> } >> ------------------------------- >> >> Thanks, >> Alexandr. >> >>> >>> >>>> Could it break a binary compatibility if someone does not follow >>>> the javadoc specification and has in his program getUI() method >>>> which return type is not subclass of the ComponentUI? >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4339584 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/4339584/webrev.00 >>>>> >>>> >>> >>> >> > > From alexander.zvegintsev at oracle.com Fri Aug 21 11:44:29 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 21 Aug 2015 14:44:29 +0300 Subject: [9] Review Request: 4339584 Adding a getUI public method to JComponent In-Reply-To: <55D70E72.80300@oracle.com> References: <55D6F7B5.2080001@oracle.com> <55D6F903.5010807@oracle.com> <55D70239.8020805@oracle.com> <55D70980.5010701@oracle.com> <55D70D8D.20200@oracle.com> <55D70E72.80300@oracle.com> Message-ID: <55D70F1D.8060504@oracle.com> +1 Thanks, Alexander. On 08/21/2015 02:41 PM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 8/21/2015 2:37 PM, Sergey Bylokhov wrote: >> On 21.08.15 14:20, Alexander Scherbatiy wrote: >>> On 8/21/2015 1:49 PM, Sergey Bylokhov wrote: >>>> I just double checked that if I compiles the subclass when the >>>> parent class has not this method, then recompiles a new parent, the >>>> correct method in subclass still called, so it seems fine. Probably >>>> there are some other cases, which will be checked during ccc review. >>> >> Yes this case will be broken, since this getter contradicts the >> specification described in JComponent.setUI. >> >>> I mean the following case: >>> ------------------------------- >>> public class CustomComponent extends JComponent { >>> >>> class CustomComponentUI {} >>> >>> CustomComponentUI getUI() { >>> return null; >>> } >>> } >>> ------------------------------- >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> >>>>> Could it break a binary compatibility if someone does not follow >>>>> the javadoc specification and has in his program getUI() method >>>>> which return type is not subclass of the ComponentUI? >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4339584 >>>>>> Webrev can be found at: >>>>>> http://cr.openjdk.java.net/~serb/4339584/webrev.00 >>>>>> >>>>> >>>> >>>> >>> >> >> > From rajeev.chamyal at oracle.com Fri Aug 21 12:10:25 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Fri, 21 Aug 2015 05:10:25 -0700 (PDT) Subject: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button Message-ID: <369f7e0e-07a8-477e-aac8-7c5d1079db15@default> Hi, Please review the following fix for jdk9: Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 webrev: http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.00/ The highlight of selected text in JTextPane/JTextArea is lost if some other component (e.g. button clicked) gains focus. Added a method to update the selection ownership for caret when text is selected/unselected in the JTextPane/JTextArea. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Aug 21 13:12:27 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 21 Aug 2015 16:12:27 +0300 Subject: [9] Review request for 6302464 Allow programmatic enabling of subpixel anti-aliasing in Swing In-Reply-To: <55D70919.8030205@oracle.com> References: <55CC8873.7030202@oracle.com> <55D70919.8030205@oracle.com> Message-ID: <55D723BB.7020400@oracle.com> On 8/21/2015 2:18 PM, Sergey Bylokhov wrote: > Hi, Alexander. > It seems this is only a part of the request. It does not cover some > situations like java properties, which can be used to > enable/set/disable anti-aliasing. The awt.useSystemAAFontSettings property overrides the desktop font rendering hints which can be obtained from toolkit by awt.font.desktophints key. > Also it is unclear how and why our look and feels modify the desktop > properties, this api seems private also. I have filled an issue on it: JDK-8134146 Java L&Fs redefine Desktop Font Rendering Hints https://bugs.openjdk.java.net/browse/JDK-8134146 Thanks, Alexandr. > > On 13.08.15 15:07, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-6302464 >> webrev: http://cr.openjdk.java.net/~alexsch/6302464/webrev.00 >> >> Swing uses internal API to set antialiasing settings for L&Fs and >> components. >> >> SwingUtilities2.AATextInfo aaTextInfo = new >> SwingUtilities2.AATextInfo( >> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB, 140); >> >> UIManager.getDefaults().put(SwingUtilities2.AA_TEXT_PROPERTY_KEY, >> aaTextInfo); // set aa hints globally >> component.putClientProperty(SwingUtilities2.AA_TEXT_PROPERTY_KEY, >> aaTextInfo); // set aa hints for a JComponent >> >> >> There are some ways to provide a public mechanism for antialiasing >> enabling in Swing: >> >> 1. Setting antialiasing rendering hints into UI defaults and >> component client properties: >> >> UIManager.getDefaults().put(RenderingHints.KEY_TEXT_ANTIALIASING, >> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); >> component.putClientProperty(RenderingHints.KEY_TEXT_ANTIALIASING, >> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); >> >> 2. Setting a map which contains antialiasing hints: >> >> Map aaHintsMap = new HashMap<>(); >> aaHintsMap.put(RenderingHints.KEY_TEXT_ANTIALIASING, >> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); >> >> UIManager.getDefaults().put(AA_TEXT_PROPERTY_KEY, aaHintsMap); >> component.putClientProperty(AA_TEXT_PROPERTY_KEY, aaHintsMap); >> >> 3. Information about antialiasing hints can be stored in a public class >> >> AATextInfo aaTextInfo = new >> AATextInfo(RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB, 140); >> UIManager.getDefaults().put(AA_TEXT_PROPERTY_KEY, aaTextInfo); >> component.putClientProperty(AA_TEXT_PROPERTY_KEY, aaTextInfo); >> >> The proposed fix used the first approach. >> >> Thanks, >> Alexandr. >> > > From Sergey.Bylokhov at oracle.com Fri Aug 21 15:12:30 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 21 Aug 2015 18:12:30 +0300 Subject: [9] Review request for 6302464 Allow programmatic enabling of subpixel anti-aliasing in Swing In-Reply-To: <55D723BB.7020400@oracle.com> References: <55CC8873.7030202@oracle.com> <55D70919.8030205@oracle.com> <55D723BB.7020400@oracle.com> Message-ID: <55D73FDE.30406@oracle.com> On 21.08.15 16:12, Alexander Scherbatiy wrote: > On 8/21/2015 2:18 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> It seems this is only a part of the request. It does not cover some >> situations like java properties, which can be used to >> enable/set/disable anti-aliasing. > The awt.useSystemAAFontSettings property overrides the desktop font > rendering hints which can be obtained from toolkit by > awt.font.desktophints key. >> Also it is unclear how and why our look and feels modify the desktop >> properties, this api seems private also. > I have filled an issue on it: JDK-8134146 Java L&Fs redefine > Desktop Font Rendering Hints > https://bugs.openjdk.java.net/browse/JDK-8134146 Looks fine. > > Thanks, > Alexandr. > >> >> On 13.08.15 15:07, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-6302464 >>> webrev: http://cr.openjdk.java.net/~alexsch/6302464/webrev.00 >>> >>> Swing uses internal API to set antialiasing settings for L&Fs and >>> components. >>> >>> SwingUtilities2.AATextInfo aaTextInfo = new >>> SwingUtilities2.AATextInfo( >>> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB, 140); >>> >>> UIManager.getDefaults().put(SwingUtilities2.AA_TEXT_PROPERTY_KEY, >>> aaTextInfo); // set aa hints globally >>> component.putClientProperty(SwingUtilities2.AA_TEXT_PROPERTY_KEY, >>> aaTextInfo); // set aa hints for a JComponent >>> >>> >>> There are some ways to provide a public mechanism for antialiasing >>> enabling in Swing: >>> >>> 1. Setting antialiasing rendering hints into UI defaults and >>> component client properties: >>> >>> UIManager.getDefaults().put(RenderingHints.KEY_TEXT_ANTIALIASING, >>> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); >>> component.putClientProperty(RenderingHints.KEY_TEXT_ANTIALIASING, >>> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); >>> >>> 2. Setting a map which contains antialiasing hints: >>> >>> Map aaHintsMap = new HashMap<>(); >>> aaHintsMap.put(RenderingHints.KEY_TEXT_ANTIALIASING, >>> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); >>> >>> UIManager.getDefaults().put(AA_TEXT_PROPERTY_KEY, aaHintsMap); >>> component.putClientProperty(AA_TEXT_PROPERTY_KEY, aaHintsMap); >>> >>> 3. Information about antialiasing hints can be stored in a public class >>> >>> AATextInfo aaTextInfo = new >>> AATextInfo(RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB, 140); >>> UIManager.getDefaults().put(AA_TEXT_PROPERTY_KEY, aaTextInfo); >>> component.putClientProperty(AA_TEXT_PROPERTY_KEY, aaTextInfo); >>> >>> The proposed fix used the first approach. >>> >>> Thanks, >>> Alexandr. >>> >> >> > -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Fri Aug 21 16:10:27 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 21 Aug 2015 19:10:27 +0300 Subject: [9] Review request for 6302464 Allow programmatic enabling of subpixel anti-aliasing in Swing In-Reply-To: <55D73FDE.30406@oracle.com> References: <55CC8873.7030202@oracle.com> <55D70919.8030205@oracle.com> <55D723BB.7020400@oracle.com> <55D73FDE.30406@oracle.com> Message-ID: <55D74D73.8020103@oracle.com> +1 Thanks, Alexander. On 08/21/2015 06:12 PM, Sergey Bylokhov wrote: > On 21.08.15 16:12, Alexander Scherbatiy wrote: >> On 8/21/2015 2:18 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> It seems this is only a part of the request. It does not cover some >>> situations like java properties, which can be used to >>> enable/set/disable anti-aliasing. >> The awt.useSystemAAFontSettings property overrides the desktop >> font rendering hints which can be obtained from toolkit by >> awt.font.desktophints key. >>> Also it is unclear how and why our look and feels modify the desktop >>> properties, this api seems private also. >> I have filled an issue on it: JDK-8134146 Java L&Fs redefine >> Desktop Font Rendering Hints >> https://bugs.openjdk.java.net/browse/JDK-8134146 > Looks fine. >> >> Thanks, >> Alexandr. >> >>> >>> On 13.08.15 15:07, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-6302464 >>>> webrev: http://cr.openjdk.java.net/~alexsch/6302464/webrev.00 >>>> >>>> Swing uses internal API to set antialiasing settings for L&Fs and >>>> components. >>>> >>>> SwingUtilities2.AATextInfo aaTextInfo = new >>>> SwingUtilities2.AATextInfo( >>>> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB, 140); >>>> >>>> UIManager.getDefaults().put(SwingUtilities2.AA_TEXT_PROPERTY_KEY, >>>> aaTextInfo); // set aa hints globally >>>> component.putClientProperty(SwingUtilities2.AA_TEXT_PROPERTY_KEY, >>>> aaTextInfo); // set aa hints for a JComponent >>>> >>>> >>>> There are some ways to provide a public mechanism for antialiasing >>>> enabling in Swing: >>>> >>>> 1. Setting antialiasing rendering hints into UI defaults and >>>> component client properties: >>>> >>>> UIManager.getDefaults().put(RenderingHints.KEY_TEXT_ANTIALIASING, >>>> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); >>>> component.putClientProperty(RenderingHints.KEY_TEXT_ANTIALIASING, >>>> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); >>>> >>>> 2. Setting a map which contains antialiasing hints: >>>> >>>> Map aaHintsMap = new HashMap<>(); >>>> aaHintsMap.put(RenderingHints.KEY_TEXT_ANTIALIASING, >>>> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB); >>>> >>>> UIManager.getDefaults().put(AA_TEXT_PROPERTY_KEY, aaHintsMap); >>>> component.putClientProperty(AA_TEXT_PROPERTY_KEY, aaHintsMap); >>>> >>>> 3. Information about antialiasing hints can be stored in a public >>>> class >>>> >>>> AATextInfo aaTextInfo = new >>>> AATextInfo(RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB, 140); >>>> UIManager.getDefaults().put(AA_TEXT_PROPERTY_KEY, aaTextInfo); >>>> component.putClientProperty(AA_TEXT_PROPERTY_KEY, aaTextInfo); >>>> >>>> The proposed fix used the first approach. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >>> >> > > From prasanta.sadhukhan at oracle.com Mon Aug 24 11:23:08 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 24 Aug 2015 16:53:08 +0530 Subject: RFR: [JDK-8081491] The case print incomplete. Message-ID: <55DAFE9C.9030406@oracle.com> 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. 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 From shilpi.rastogi at oracle.com Mon Aug 24 11:47:12 2015 From: shilpi.rastogi at oracle.com (shilpi rastogi) Date: Mon, 24 Aug 2015 17:17:12 +0530 Subject: REM: Re: [9-client] Review request for bug 7124238 : [TEST_BUG] Font in BasicHTML document is bigger than it should be In-Reply-To: <55CD9E85.2070909@oracle.com> References: <55CC283F.2090901@oracle.com> <55CC4689.1070005@oracle.com> <55CC84AF.2000104@oracle.com> <55CCA49A.3000103@oracle.com> <55CD99D3.4060907@oracle.com> <55CD9E85.2070909@oracle.com> Message-ID: <55DB0440.4070803@oracle.com> Hi all, Gentle reminder. Thanks Shilpi On 8/14/2015 1:23 PM, Alexander Scherbatiy wrote: > > The fix looks good to me. > > Thanks, > Alexandr. > > On 8/14/2015 10:33 AM, shilpi rastogi wrote: >> Hi All, >> >> Thanks Alexander for comments! >> >> I tried to incorporate all changes suggested by you. >> >> Please have a look >> >> http://cr.openjdk.java.net/~sgupta/7124238/webrev.05/ >> http://cr.openjdk.java.net/~sgupta/7124238/webrev.04/ >> >> >> Thanks >> Shilpi >> >> On 8/13/2015 7:37 PM, Alexander Scherbatiy wrote: >>> On 8/13/2015 2:51 PM, shilpi rastogi wrote: >>>> Hi All, >>>> >>>> Please review updated webrev >>>> >>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.03/ >>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.02/ >>> >>> - I forgot to mention that the rule is to split line if it longer >>> than 80 characters. Long lines are annoying for side-by-side views. >>> IDEs usually allow to configure right margin settings in a editor >>> for this purposes. >>> - It is better to define that createAndShowGUI() method throws >>> Exception. In this case the try/catch block for L&F setting is >>> unnecessary. >>> - SwingUtilities.invokeAndWait() does not throw AWTException so >>> its declaration can be removed. >>> >>> Thanks, >>> Alexandr. >>> >>> >>>> >>>> Thanks, >>>> Shilpi >>>> >>>> >>>> On 8/13/2015 12:56 PM, Alexander Scherbatiy wrote: >>>>> On 8/13/2015 8:16 AM, shilpi rastogi wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review a test bug fix >>>>>> >>>>>> TEST : >>>>>> closed/javax/swing/plaf/basic/BasicHTML/4960629/bug4960629.java >>>>>> BUG ID - https://bugs.openjdk.java.net/browse/JDK-7124238 >>>>>> >>>>>> Pleasemove the test from closed repo to open repo. >>>>>> >>>>>> The webrev is: >>>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.01 add to open >>>>>> repo >>>>> >>>>> - The long lines should be split so they fit to a page >>>>> - Exceptions should be re-thrown. In other case they are just >>>>> printed but jtreg decides that a test is passed. >>>>> >>>>> 69 try { >>>>> 70 createAndShowGUI(); >>>>> 71 } catch (AWTException e) { >>>>> 72 e.printStackTrace(); >>>>> 73 } >>>>> >>>>> - The test methods can throw a general Exceptioninstead of >>>>> several concrete ones. This usually makes a test more readable. >>>>> It also allows to omit try/catch block for the the >>>>> UIManager.setLookAndFeel() call. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> >>>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.00/ >>>>>> - >>>>>> diff with previous version of the closed test. >>>>>> >>>>>> Thanks, >>>>>> Shilpi >>>>> >>>> >>> >> > From alexander.zvegintsev at oracle.com Mon Aug 24 14:14:27 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 24 Aug 2015 17:14:27 +0300 Subject: REM: Re: [9-client] Review request for bug 7124238 : [TEST_BUG] Font in BasicHTML document is bigger than it should be In-Reply-To: <55DB0440.4070803@oracle.com> References: <55CC283F.2090901@oracle.com> <55CC4689.1070005@oracle.com> <55CC84AF.2000104@oracle.com> <55CCA49A.3000103@oracle.com> <55CD99D3.4060907@oracle.com> <55CD9E85.2070909@oracle.com> <55DB0440.4070803@oracle.com> Message-ID: <55DB26C3.7080705@oracle.com> Hi Shilpi, 56 test(); 57 f.dispose(); In case of test failure runtime exception will be thrown, thus f.dispose() will not be called. So it would be better to call it from a finally block. The fix contains mixed tab/spaces indentation(we are using spaces), trailing whitespaces, this will prevent push to openjdk repository. Also there are a lot of empty lines at the end of file. Thanks, Alexander. On 08/24/2015 02:47 PM, shilpi rastogi wrote: > Hi all, > > Gentle reminder. > > Thanks > Shilpi > On 8/14/2015 1:23 PM, Alexander Scherbatiy wrote: >> >> The fix looks good to me. >> >> Thanks, >> Alexandr. >> >> On 8/14/2015 10:33 AM, shilpi rastogi wrote: >>> Hi All, >>> >>> Thanks Alexander for comments! >>> >>> I tried to incorporate all changes suggested by you. >>> >>> Please have a look >>> >>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.05/ >>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.04/ >>> >>> >>> Thanks >>> Shilpi >>> >>> On 8/13/2015 7:37 PM, Alexander Scherbatiy wrote: >>>> On 8/13/2015 2:51 PM, shilpi rastogi wrote: >>>>> Hi All, >>>>> >>>>> Please review updated webrev >>>>> >>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.03/ >>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.02/ >>>> >>>> - I forgot to mention that the rule is to split line if it longer >>>> than 80 characters. Long lines are annoying for side-by-side views. >>>> IDEs usually allow to configure right margin settings in a >>>> editor for this purposes. >>>> - It is better to define that createAndShowGUI() method throws >>>> Exception. In this case the try/catch block for L&F setting is >>>> unnecessary. >>>> - SwingUtilities.invokeAndWait() does not throw AWTException so >>>> its declaration can be removed. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>>> >>>>> Thanks, >>>>> Shilpi >>>>> >>>>> >>>>> On 8/13/2015 12:56 PM, Alexander Scherbatiy wrote: >>>>>> On 8/13/2015 8:16 AM, shilpi rastogi wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review a test bug fix >>>>>>> >>>>>>> TEST : >>>>>>> closed/javax/swing/plaf/basic/BasicHTML/4960629/bug4960629.java >>>>>>> BUG ID - https://bugs.openjdk.java.net/browse/JDK-7124238 >>>>>>> >>>>>>> Pleasemove the test from closed repo to open repo. >>>>>>> >>>>>>> The webrev is: >>>>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.01 add to open >>>>>>> repo >>>>>> >>>>>> - The long lines should be split so they fit to a page >>>>>> - Exceptions should be re-thrown. In other case they are just >>>>>> printed but jtreg decides that a test is passed. >>>>>> >>>>>> 69 try { >>>>>> 70 createAndShowGUI(); >>>>>> 71 } catch (AWTException e) { >>>>>> 72 e.printStackTrace(); >>>>>> 73 } >>>>>> >>>>>> - The test methods can throw a general Exceptioninstead of >>>>>> several concrete ones. This usually makes a test more readable. >>>>>> It also allows to omit try/catch block for the the >>>>>> UIManager.setLookAndFeel() call. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.00/ >>>>>>> - >>>>>>> diff with previous version of the closed test. >>>>>>> >>>>>>> Thanks, >>>>>>> Shilpi >>>>>> >>>>> >>>> >>> >> > From rajeev.chamyal at oracle.com Tue Aug 25 08:09:34 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Tue, 25 Aug 2015 01:09:34 -0700 (PDT) Subject: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button In-Reply-To: <369f7e0e-07a8-477e-aac8-7c5d1079db15@default> References: <369f7e0e-07a8-477e-aac8-7c5d1079db15@default> Message-ID: <99a5a6f0-05b3-4571-abaa-6f1b09d254a7@default> Hello All, Please review the below fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 webrev: http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.00/ Regards, Rajeev Chamyal From: Rajeev Chamyal Sent: Friday, August 21, 2015 5:40 PM To: swing-dev at openjdk.java.net Subject: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button Hi, Please review the following fix for jdk9: Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 webrev: http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.00/ The highlight of selected text in JTextPane/JTextArea is lost if some other component (e.g. button clicked) gains focus. Added a method to update the selection ownership for caret when text is selected/unselected in the JTextPane/JTextArea. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Tue Aug 25 08:57:45 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 25 Aug 2015 11:57:45 +0300 Subject: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button In-Reply-To: <369f7e0e-07a8-477e-aac8-7c5d1079db15@default> References: <369f7e0e-07a8-477e-aac8-7c5d1079db15@default> Message-ID: <55DC2E09.3040604@oracle.com> On 8/21/2015 3:10 PM, Rajeev Chamyal wrote: > Hi, > > Please review the following fix for jdk9: > > Bug:https://bugs.openjdk.java.net/browse/JDK-8025082 > > webrev: > http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.00/ > > > > The highlight of selected text in JTextPane/JTextArea is lost if some other component (e.g. button clicked) gains focus. > Added a method to update the selection ownership for caret when text is selected/unselected in the JTextPane/JTextArea. - The updateOwnsSelection() method can be shorter if use the conditional operator '?' https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.25 - SwingUtilities.invokeAndWait() should be used instead of invokeLater. In other case the system can suspend the EDT thread and robot will start its actions before the createUI() execution. - button.getLocationOnScreen() should be called on EDT in the test - The actionPerformed() method is not properly formatted - What is the reason to use double colons in the error messages? - System.out.println calls are not really necessary for the automated test. It also pollute the logs for SQE team when all tests are running. The only exception throwing can be left in the actionPerformed() method. - line 30 '* **/' - small formatting issue Thanks, Alexandr. > > Regards, > Rajeev Chamyal > > From alexandr.scherbatiy at oracle.com Tue Aug 25 10:23:09 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 25 Aug 2015 13:23:09 +0300 Subject: RFR: [JDK-8081491] The case print incomplete. In-Reply-To: <55DAFE9C.9030406@oracle.com> References: <55DAFE9C.9030406@oracle.com> Message-ID: <55DC420D.2070009@oracle.com> 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? Please, also mention in the email title JDK version for which the fix is provided. 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 From prasanta.sadhukhan at oracle.com Tue Aug 25 10:51:40 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 25 Aug 2015 16:21:40 +0530 Subject: RFR: [9] [JDK-8081491] The case print incomplete. In-Reply-To: <55DC420D.2070009@oracle.com> References: <55DAFE9C.9030406@oracle.com> <55DC420D.2070009@oracle.com> Message-ID: <55DC48BC.2070508@oracle.com> 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. > 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 > From rajeev.chamyal at oracle.com Wed Aug 26 07:20:05 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Wed, 26 Aug 2015 00:20:05 -0700 (PDT) Subject: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button In-Reply-To: <55DC2E09.3040604@oracle.com> References: <369f7e0e-07a8-477e-aac8-7c5d1079db15@default> <55DC2E09.3040604@oracle.com> Message-ID: Hello All, Please review the updated fix for bug JDK-8025082. Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 Webrev : http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.01/ Regards, Rajeev Chamyal -----Original Message----- From: Alexander Scherbatiy Sent: Tuesday, August 25, 2015 2:28 PM To: Rajeev Chamyal Cc: swing-dev at openjdk.java.net Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button On 8/21/2015 3:10 PM, Rajeev Chamyal wrote: > Hi, > > Please review the following fix for jdk9: > > Bug:https://bugs.openjdk.java.net/browse/JDK-8025082 > > webrev: > http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.00/ > > > > The highlight of selected text in JTextPane/JTextArea is lost if some other component (e.g. button clicked) gains focus. > Added a method to update the selection ownership for caret when text is selected/unselected in the JTextPane/JTextArea. - The updateOwnsSelection() method can be shorter if use the conditional operator '?' https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.25 - SwingUtilities.invokeAndWait() should be used instead of invokeLater. In other case the system can suspend the EDT thread and robot will start its actions before the createUI() execution. - button.getLocationOnScreen() should be called on EDT in the test - The actionPerformed() method is not properly formatted - What is the reason to use double colons in the error messages? - System.out.println calls are not really necessary for the automated test. It also pollute the logs for SQE team when all tests are running. The only exception throwing can be left in the actionPerformed() method. - line 30 '* **/' - small formatting issue Thanks, Alexandr. > > Regards, > Rajeev Chamyal > > From rajeev.chamyal at oracle.com Wed Aug 26 09:13:22 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Wed, 26 Aug 2015 02:13:22 -0700 (PDT) Subject: Bug : JDK-8078831 Mismatch of getPreferredSize() and getPreferredScrollableViewportSize() values in WindowsClassicLookAndFeel Message-ID: <1ecbe098-70b2-4f00-a9dd-0c5b455f1cb0@default> Hi, Please review the following fix for jdk9: Bug: https://bugs.openjdk.java.net/browse/JDK-8078831 Webrev : http://cr.openjdk.java.net/~psadhukhan/rajeev/5042886/webrev.00/ getPreferredScrollableViewportSize() must not return the same as getPreferredSize() but it should return equal or less size. Test condition was checking for inequality and throwing Runtime exception. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Wed Aug 26 12:54:37 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 26 Aug 2015 15:54:37 +0300 Subject: RFR: [9] [JDK-8081491] The case print incomplete. In-Reply-To: <55DC48BC.2070508@oracle.com> References: <55DAFE9C.9030406@oracle.com> <55DC420D.2070009@oracle.com> <55DC48BC.2070508@oracle.com> Message-ID: <55DDB70D.7010001@oracle.com> 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. 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 >> > From alexandr.scherbatiy at oracle.com Wed Aug 26 13:09:28 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 26 Aug 2015 16:09:28 +0300 Subject: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button In-Reply-To: References: <369f7e0e-07a8-477e-aac8-7c5d1079db15@default> <55DC2E09.3040604@oracle.com> Message-ID: <55DDBA88.6000305@oracle.com> On 8/26/2015 10:20 AM, Rajeev Chamyal wrote: > Hello All, > > Please review the updated fix for bug JDK-8025082. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 > Webrev : http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.01/ - the updateOwnsSelection method should be properly formatted See the Java Code Conventions: http://www.oracle.com/technetwork/java/codeconventions-150003.pdf and new discussed Java Style Guidelines: http://cr.openjdk.java.net/~alundblad/styleguide - lines which are longer than 80 characters should be split Thanks, Alexandr. > > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexander Scherbatiy > Sent: Tuesday, August 25, 2015 2:28 PM > To: Rajeev Chamyal > Cc: swing-dev at openjdk.java.net > Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button > > On 8/21/2015 3:10 PM, Rajeev Chamyal wrote: >> Hi, >> >> Please review the following fix for jdk9: >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8025082 >> >> webrev: >> http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.00/ >> >> >> >> The highlight of selected text in JTextPane/JTextArea is lost if some other component (e.g. button clicked) gains focus. >> Added a method to update the selection ownership for caret when text is selected/unselected in the JTextPane/JTextArea. > - The updateOwnsSelection() method can be shorter if use the conditional operator '?' > https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.25 > - SwingUtilities.invokeAndWait() should be used instead of invokeLater. In other case the system can suspend the EDT thread and robot will start its actions before the createUI() execution. > - button.getLocationOnScreen() should be called on EDT in the test > - The actionPerformed() method is not properly formatted > - What is the reason to use double colons in the error messages? > - System.out.println calls are not really necessary for the automated test. It also pollute the logs for SQE team when all tests are running. The only exception throwing can be left in the > actionPerformed() method. > - line 30 '* **/' - small formatting issue > > Thanks, > Alexandr. > >> >> Regards, >> Rajeev Chamyal >> >> From alexandr.scherbatiy at oracle.com Wed Aug 26 13:12:15 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 26 Aug 2015 16:12:15 +0300 Subject: Bug : JDK-8078831 Mismatch of getPreferredSize() and getPreferredScrollableViewportSize() values in WindowsClassicLookAndFeel In-Reply-To: <1ecbe098-70b2-4f00-a9dd-0c5b455f1cb0@default> References: <1ecbe098-70b2-4f00-a9dd-0c5b455f1cb0@default> Message-ID: <55DDBB2F.3030909@oracle.com> On 8/26/2015 12:13 PM, Rajeev Chamyal wrote: > Hi, > > Please review the following fix for jdk9: > > Bug:https://bugs.openjdk.java.net/browse/JDK-8078831 > > Webrev : > http://cr.openjdk.java.net/~psadhukhan/rajeev/5042886/webrev.00/ > > > getPreferredScrollableViewportSize() must not return the same as getPreferredSize() but it should return equal or less size. Test condition was checking for inequality and throwing Runtime exception. > Please, split lines which are longer than 80 characters. Thanks, Alexandr. > Regards, > Rajeev Chamyal > From pooja.chopra at oracle.com Thu Aug 27 10:12:49 2015 From: pooja.chopra at oracle.com (pooja chopra) Date: Thu, 27 Aug 2015 15:42:49 +0530 Subject: < Swing Dev> [9] Review Request:JDK-8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java failed with UnsupportedOperation exception In-Reply-To: <55C1D463.3090407@oracle.com> References: <55A62E46.3020504@oracle.com> <55A630DE.4080500@oracle.com> <55A6AE5A.3060408@oracle.com> <55B86ECA.20306@oracle.com> <55B8AC53.3070103@oracle.com> <55C1BBB4.3010801@oracle.com> <55C1D463.3090407@oracle.com> Message-ID: <55DEE2A1.8060104@oracle.com> Hi Alexandr, Please review updated webrev link :- http://cr.openjdk.java.net/~pchopra/8130481/webrev.06/ Regards, Pooja On 8/5/2015 2:46 PM, Alexander Scherbatiy wrote: > On 8/5/2015 10:31 AM, pooja chopra wrote: >> Hi Alexandr, >> >> Please review update webrev link :- >> >> The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.03/ > > This looks better. There are just minor issues: > - run swing components on EDT like: menu.show(frame, 0, 0) > - format the code in 'if' block or check the mercurial settings in > .hgrc file like diff = -w // ignore white space when comparing lines > > Thanks, > Alexandr. > >> >> Regards, >> Pooja >> On 7/29/2015 4:04 PM, Alexander Scherbatiy wrote: >>> On 7/29/2015 9:12 AM, pooja chopra wrote: >>>> Hello Sergey , >>>> Please review update webrev link below :- >>>> >>>> The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.02/ >>> >>> After the SystemTray.isSupported() is checked it is not expected >>> that the UnsupportedOperationException is thrown. The test should >>> fail in this case. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> Regards, >>>> Pooja >>>> On 7/16/2015 12:32 AM, Sergey Bylokhov wrote: >>>>> Hello, >>>>> I suggest to check support of systemTray at the beginning of the >>>>> test. >>>>> >>>>> On 15.07.15 13:07, pooja chopra wrote: >>>>>> Hello , >>>>>> >>>>>> Corrected the webrev link below . Please review. >>>>>> >>>>>> Regards, >>>>>> Pooja >>>>>> On 7/15/2015 3:26 PM, pooja chopra wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review a fix for issue :- >>>>>>> >>>>>>> 8130481 [TEST_BUG] >>>>>>> javax/swing/JPopupMenu/6583251/bug6583251.java failed with >>>>>>> UnsupportedOperation exception >>>>>>> Test bug fix. >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8130481 >>>>>>> The webrev is : >>>>>>> http://cr.openjdk.java.net/~pchopra/8130481/webrev.01/ >>>>>>> >>>>>>> Regards, >>>>>>> Pooja >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From rajeev.chamyal at oracle.com Thu Aug 27 10:34:20 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 27 Aug 2015 03:34:20 -0700 (PDT) Subject: Bug : JDK-8078831 Mismatch of getPreferredSize() and getPreferredScrollableViewportSize() values in WindowsClassicLookAndFeel In-Reply-To: <55DDBB2F.3030909@oracle.com> References: <1ecbe098-70b2-4f00-a9dd-0c5b455f1cb0@default> <55DDBB2F.3030909@oracle.com> Message-ID: <0b28ec21-ed8d-4650-a2a0-080e9f9427a4@default> Hello All, Please review the updated fix with latest review comments. http://cr.openjdk.java.net/~psadhukhan/rajeev/5042886/webrev.01/ Regards, Rajeev Chamyal -----Original Message----- From: Alexander Scherbatiy Sent: Wednesday, August 26, 2015 6:42 PM To: Rajeev Chamyal Cc: Alexander Zvegintsev; Sergey Bylokhov; swing-dev at openjdk.java.net Subject: Re: Bug : JDK-8078831 Mismatch of getPreferredSize() and getPreferredScrollableViewportSize() values in WindowsClassicLookAndFeel On 8/26/2015 12:13 PM, Rajeev Chamyal wrote: > Hi, > > Please review the following fix for jdk9: > > Bug:https://bugs.openjdk.java.net/browse/JDK-8078831 > > Webrev : > http://cr.openjdk.java.net/~psadhukhan/rajeev/5042886/webrev.00/ > > > getPreferredScrollableViewportSize() must not return the same as getPreferredSize() but it should return equal or less size. Test condition was checking for inequality and throwing Runtime exception. > Please, split lines which are longer than 80 characters. Thanks, Alexandr. > Regards, > Rajeev Chamyal > From rajeev.chamyal at oracle.com Thu Aug 27 10:37:28 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Thu, 27 Aug 2015 03:37:28 -0700 (PDT) Subject: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button In-Reply-To: <55DDBA88.6000305@oracle.com> References: <369f7e0e-07a8-477e-aac8-7c5d1079db15@default> <55DC2E09.3040604@oracle.com> <55DDBA88.6000305@oracle.com> Message-ID: <70f0e584-2ba1-4ca0-9157-aeb75fe8915b@default> Hello All, Please review the updated webrev. Webrev: http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 Regards, Rajeev Chamyal -----Original Message----- From: Alexander Scherbatiy Sent: Wednesday, August 26, 2015 6:39 PM To: Rajeev Chamyal Cc: Alexander Zvegintsev; Sergey Bylokhov; swing-dev at openjdk.java.net Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button On 8/26/2015 10:20 AM, Rajeev Chamyal wrote: > Hello All, > > Please review the updated fix for bug JDK-8025082. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 > Webrev : http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.01/ - the updateOwnsSelection method should be properly formatted See the Java Code Conventions: http://www.oracle.com/technetwork/java/codeconventions-150003.pdf and new discussed Java Style Guidelines: http://cr.openjdk.java.net/~alundblad/styleguide - lines which are longer than 80 characters should be split Thanks, Alexandr. > > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexander Scherbatiy > Sent: Tuesday, August 25, 2015 2:28 PM > To: Rajeev Chamyal > Cc: swing-dev at openjdk.java.net > Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button > > On 8/21/2015 3:10 PM, Rajeev Chamyal wrote: >> Hi, >> >> Please review the following fix for jdk9: >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8025082 >> >> webrev: >> http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.00/ >> >> >> >> The highlight of selected text in JTextPane/JTextArea is lost if some other component (e.g. button clicked) gains focus. >> Added a method to update the selection ownership for caret when text is selected/unselected in the JTextPane/JTextArea. > - The updateOwnsSelection() method can be shorter if use the conditional operator '?' > https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.25 > - SwingUtilities.invokeAndWait() should be used instead of invokeLater. In other case the system can suspend the EDT thread and robot will start its actions before the createUI() execution. > - button.getLocationOnScreen() should be called on EDT in the test > - The actionPerformed() method is not properly formatted > - What is the reason to use double colons in the error messages? > - System.out.println calls are not really necessary for the automated test. It also pollute the logs for SQE team when all tests are running. The only exception throwing can be left in the > actionPerformed() method. > - line 30 '* **/' - small formatting issue > > Thanks, > Alexandr. > >> >> Regards, >> Rajeev Chamyal >> >> From alexandr.scherbatiy at oracle.com Thu Aug 27 12:08:36 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 27 Aug 2015 15:08:36 +0300 Subject: < Swing Dev> [9] Review Request:JDK-8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java failed with UnsupportedOperation exception In-Reply-To: <55DEE2A1.8060104@oracle.com> References: <55A62E46.3020504@oracle.com> <55A630DE.4080500@oracle.com> <55A6AE5A.3060408@oracle.com> <55B86ECA.20306@oracle.com> <55B8AC53.3070103@oracle.com> <55C1BBB4.3010801@oracle.com> <55C1D463.3090407@oracle.com> <55DEE2A1.8060104@oracle.com> Message-ID: <55DEFDC4.8020606@oracle.com> On 8/27/2015 1:12 PM, pooja chopra wrote: > Hi Alexandr, > > Please review updated webrev link :- > > http://cr.openjdk.java.net/~pchopra/8130481/webrev.06/ There are some problems with the code indentation like : ------------------ if (SystemTray.isSupported()) { SwingUtilities.invokeAndWait(new Runnable() { public void run() { createGui(); } }); --------------- We have some requirements about it. See for example: Java Code Conventions: http://www.oracle.com/technetwork/java/codeconventions-150003.pdf new discussed Java Style Guidelines: http://cr.openjdk.java.net/~alundblad/styleguide You could also use code formatting in your IDE to properly format the code. Thanks, Alexandr. > > Regards, > Pooja > On 8/5/2015 2:46 PM, Alexander Scherbatiy wrote: >> On 8/5/2015 10:31 AM, pooja chopra wrote: >>> Hi Alexandr, >>> >>> Please review update webrev link :- >>> >>> The webrev is : http://cr.openjdk.java.net/~pchopra/8130481/webrev.03/ >> >> This looks better. There are just minor issues: >> - run swing components on EDT like: menu.show(frame, 0, 0) >> - format the code in 'if' block or check the mercurial settings >> in .hgrc file like diff = -w // ignore white space when comparing lines >> >> Thanks, >> Alexandr. >> >>> >>> Regards, >>> Pooja >>> On 7/29/2015 4:04 PM, Alexander Scherbatiy wrote: >>>> On 7/29/2015 9:12 AM, pooja chopra wrote: >>>>> Hello Sergey , >>>>> Please review update webrev link below :- >>>>> >>>>> The webrev is : >>>>> http://cr.openjdk.java.net/~pchopra/8130481/webrev.02/ >>>> >>>> After the SystemTray.isSupported() is checked it is not >>>> expected that the UnsupportedOperationException is thrown. The test >>>> should fail in this case. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> Regards, >>>>> Pooja >>>>> On 7/16/2015 12:32 AM, Sergey Bylokhov wrote: >>>>>> Hello, >>>>>> I suggest to check support of systemTray at the beginning of the >>>>>> test. >>>>>> >>>>>> On 15.07.15 13:07, pooja chopra wrote: >>>>>>> Hello , >>>>>>> >>>>>>> Corrected the webrev link below . Please review. >>>>>>> >>>>>>> Regards, >>>>>>> Pooja >>>>>>> On 7/15/2015 3:26 PM, pooja chopra wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review a fix for issue :- >>>>>>>> >>>>>>>> 8130481 [TEST_BUG] >>>>>>>> javax/swing/JPopupMenu/6583251/bug6583251.java failed with >>>>>>>> UnsupportedOperation exception >>>>>>>> Test bug fix. >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8130481 >>>>>>>> The webrev is : >>>>>>>> http://cr.openjdk.java.net/~pchopra/8130481/webrev.01/ >>>>>>>> >>>>>>>> Regards, >>>>>>>> Pooja >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Thu Aug 27 12:15:51 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 27 Aug 2015 15:15:51 +0300 Subject: Bug : JDK-8078831 Mismatch of getPreferredSize() and getPreferredScrollableViewportSize() values in WindowsClassicLookAndFeel In-Reply-To: <0b28ec21-ed8d-4650-a2a0-080e9f9427a4@default> References: <1ecbe098-70b2-4f00-a9dd-0c5b455f1cb0@default> <55DDBB2F.3030909@oracle.com> <0b28ec21-ed8d-4650-a2a0-080e9f9427a4@default> Message-ID: <55DEFF77.6020304@oracle.com> On 8/27/2015 1:34 PM, Rajeev Chamyal wrote: > Hello All, > > Please review the updated fix with latest review comments. > > http://cr.openjdk.java.net/~psadhukhan/rajeev/5042886/webrev.01/ This looks better. Please, move it to the open repository, add copyright and properly format the code: Java Code Conventions: http://www.oracle.com/technetwork/java/codeconventions-150003.pdf new discussed Java Style Guidelines: http://cr.openjdk.java.net/~alundblad/styleguide Thanks, Alexandr. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexander Scherbatiy > Sent: Wednesday, August 26, 2015 6:42 PM > To: Rajeev Chamyal > Cc: Alexander Zvegintsev; Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: Bug : JDK-8078831 Mismatch of getPreferredSize() and getPreferredScrollableViewportSize() values in WindowsClassicLookAndFeel > > On 8/26/2015 12:13 PM, Rajeev Chamyal wrote: >> Hi, >> >> Please review the following fix for jdk9: >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8078831 >> >> Webrev : >> http://cr.openjdk.java.net/~psadhukhan/rajeev/5042886/webrev.00/ >> >> >> getPreferredScrollableViewportSize() must not return the same as getPreferredSize() but it should return equal or less size. Test condition was checking for inequality and throwing Runtime exception. >> > Please, split lines which are longer than 80 characters. > > Thanks, > Alexandr. > >> Regards, >> Rajeev Chamyal >> From alexandr.scherbatiy at oracle.com Thu Aug 27 12:17:41 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 27 Aug 2015 15:17:41 +0300 Subject: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button In-Reply-To: <70f0e584-2ba1-4ca0-9157-aeb75fe8915b@default> References: <369f7e0e-07a8-477e-aac8-7c5d1079db15@default> <55DC2E09.3040604@oracle.com> <55DDBA88.6000305@oracle.com> <70f0e584-2ba1-4ca0-9157-aeb75fe8915b@default> Message-ID: <55DEFFE5.3000509@oracle.com> The fix looks good to me. Note, that it is necessary to have at least two approvals for the fix. Thanks, Alexandr. On 8/27/2015 1:37 PM, Rajeev Chamyal wrote: > Hello All, > > Please review the updated webrev. > > Webrev: http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 > > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexander Scherbatiy > Sent: Wednesday, August 26, 2015 6:39 PM > To: Rajeev Chamyal > Cc: Alexander Zvegintsev; Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button > > On 8/26/2015 10:20 AM, Rajeev Chamyal wrote: >> Hello All, >> >> Please review the updated fix for bug JDK-8025082. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 >> Webrev : http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.01/ > - the updateOwnsSelection method should be properly formatted > See the Java Code Conventions: > http://www.oracle.com/technetwork/java/codeconventions-150003.pdf > and new discussed Java Style Guidelines: > http://cr.openjdk.java.net/~alundblad/styleguide > - lines which are longer than 80 characters should be split > > Thanks, > Alexandr. >> >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Alexander Scherbatiy >> Sent: Tuesday, August 25, 2015 2:28 PM >> To: Rajeev Chamyal >> Cc: swing-dev at openjdk.java.net >> Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button >> >> On 8/21/2015 3:10 PM, Rajeev Chamyal wrote: >>> Hi, >>> >>> Please review the following fix for jdk9: >>> >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8025082 >>> >>> webrev: >>> http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.00/ >>> >>> >>> >>> The highlight of selected text in JTextPane/JTextArea is lost if some other component (e.g. button clicked) gains focus. >>> Added a method to update the selection ownership for caret when text is selected/unselected in the JTextPane/JTextArea. >> - The updateOwnsSelection() method can be shorter if use the conditional operator '?' >> https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.25 >> - SwingUtilities.invokeAndWait() should be used instead of invokeLater. In other case the system can suspend the EDT thread and robot will start its actions before the createUI() execution. >> - button.getLocationOnScreen() should be called on EDT in the test >> - The actionPerformed() method is not properly formatted >> - What is the reason to use double colons in the error messages? >> - System.out.println calls are not really necessary for the automated test. It also pollute the logs for SQE team when all tests are running. The only exception throwing can be left in the >> actionPerformed() method. >> - line 30 '* **/' - small formatting issue >> >> Thanks, >> Alexandr. >> >>> >>> Regards, >>> Rajeev Chamyal >>> >>> From alexander.zvegintsev at oracle.com Thu Aug 27 12:28:16 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 27 Aug 2015 15:28:16 +0300 Subject: < Swing Dev> [9] Review Request:JDK-8130481 [TEST_BUG] javax/swing/JPopupMenu/6583251/bug6583251.java failed with UnsupportedOperation exception In-Reply-To: <55DEFDC4.8020606@oracle.com> References: <55A62E46.3020504@oracle.com> <55A630DE.4080500@oracle.com> <55A6AE5A.3060408@oracle.com> <55B86ECA.20306@oracle.com> <55B8AC53.3070103@oracle.com> <55C1BBB4.3010801@oracle.com> <55C1D463.3090407@oracle.com> <55DEE2A1.8060104@oracle.com> <55DEFDC4.8020606@oracle.com> Message-ID: <55DF0260.1050905@oracle.com> BTW, there is no need in try/catch block. Thanks, Alexander. On 08/27/2015 03:08 PM, Alexander Scherbatiy wrote: > On 8/27/2015 1:12 PM, pooja chopra wrote: >> Hi Alexandr, >> >> Please review updated webrev link :- >> >> http://cr.openjdk.java.net/~pchopra/8130481/webrev.06/ > > > There are some problems with the code indentation like : > ------------------ > if (SystemTray.isSupported()) { > SwingUtilities.invokeAndWait(new Runnable() { > public void run() { > createGui(); > } > }); > --------------- > We have some requirements about it. See for example: > Java Code Conventions: > http://www.oracle.com/technetwork/java/codeconventions-150003.pdf > new discussed Java Style Guidelines: > http://cr.openjdk.java.net/~alundblad/styleguide > > You could also use code formatting in your IDE to properly format > the code. > > Thanks, > Alexandr. > >> >> Regards, >> Pooja >> On 8/5/2015 2:46 PM, Alexander Scherbatiy wrote: >>> On 8/5/2015 10:31 AM, pooja chopra wrote: >>>> Hi Alexandr, >>>> >>>> Please review update webrev link :- >>>> >>>> The webrev is : >>>> http://cr.openjdk.java.net/~pchopra/8130481/webrev.03/ >>> >>> This looks better. There are just minor issues: >>> - run swing components on EDT like: menu.show(frame, 0, 0) >>> - format the code in 'if' block or check the mercurial settings >>> in .hgrc file like diff = -w // ignore white space when comparing >>> lines >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> Regards, >>>> Pooja >>>> On 7/29/2015 4:04 PM, Alexander Scherbatiy wrote: >>>>> On 7/29/2015 9:12 AM, pooja chopra wrote: >>>>>> Hello Sergey , >>>>>> Please review update webrev link below :- >>>>>> >>>>>> The webrev is : >>>>>> http://cr.openjdk.java.net/~pchopra/8130481/webrev.02/ >>>>> >>>>> After the SystemTray.isSupported() is checked it is not >>>>> expected that the UnsupportedOperationException is thrown. The >>>>> test should fail in this case. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> >>>>>> Regards, >>>>>> Pooja >>>>>> On 7/16/2015 12:32 AM, Sergey Bylokhov wrote: >>>>>>> Hello, >>>>>>> I suggest to check support of systemTray at the beginning of the >>>>>>> test. >>>>>>> >>>>>>> On 15.07.15 13:07, pooja chopra wrote: >>>>>>>> Hello , >>>>>>>> >>>>>>>> Corrected the webrev link below . Please review. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Pooja >>>>>>>> On 7/15/2015 3:26 PM, pooja chopra wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review a fix for issue :- >>>>>>>>> >>>>>>>>> 8130481 [TEST_BUG] >>>>>>>>> javax/swing/JPopupMenu/6583251/bug6583251.java failed with >>>>>>>>> UnsupportedOperation exception >>>>>>>>> Test bug fix. >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8130481 >>>>>>>>> The webrev is : >>>>>>>>> http://cr.openjdk.java.net/~pchopra/8130481/webrev.01/ >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Pooja >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From Sergey.Bylokhov at oracle.com Thu Aug 27 12:48:02 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 27 Aug 2015 15:48:02 +0300 Subject: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button In-Reply-To: <70f0e584-2ba1-4ca0-9157-aeb75fe8915b@default> References: <369f7e0e-07a8-477e-aac8-7c5d1079db15@default> <55DC2E09.3040604@oracle.com> <55DDBA88.6000305@oracle.com> <70f0e584-2ba1-4ca0-9157-aeb75fe8915b@default> Message-ID: <55DF0702.9070301@oracle.com> Hi, Rajeev. A few comments about a tests: - The (SwingUtilities.isEventDispatchThread()) inside a invokeAndWait is not necessary, it is not a problem, but this is an overhead to validate this in each test. - I suggest to move the window to the center of the screen(frame.setLocationRelativeTo(null)) and clicks to the center of the button, otherwise the test can fail if the window will be opened under the dashboard(dock), which can be placed on the left side of the screen. - Please always close all resources, which were opened by the test. in your case this is a frame, which should be disposed at the end of the test. Small note about a style, probably this style will be a little bit readable? But this is up to you. /** * Updates ownsSelection based on text selection in the caret. */ private void updateOwnsSelection() { ownsSelection = selectionTag != null && SwingUtilities2.canAccessSystemClipboard(); } On 27.08.15 13:37, Rajeev Chamyal wrote: > Hello All, > > Please review the updated webrev. > > Webrev: http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 > > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexander Scherbatiy > Sent: Wednesday, August 26, 2015 6:39 PM > To: Rajeev Chamyal > Cc: Alexander Zvegintsev; Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button > > On 8/26/2015 10:20 AM, Rajeev Chamyal wrote: >> Hello All, >> >> Please review the updated fix for bug JDK-8025082. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 >> Webrev : http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.01/ > - the updateOwnsSelection method should be properly formatted > See the Java Code Conventions: > http://www.oracle.com/technetwork/java/codeconventions-150003.pdf > and new discussed Java Style Guidelines: > http://cr.openjdk.java.net/~alundblad/styleguide > - lines which are longer than 80 characters should be split > > Thanks, > Alexandr. >> >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Alexander Scherbatiy >> Sent: Tuesday, August 25, 2015 2:28 PM >> To: Rajeev Chamyal >> Cc: swing-dev at openjdk.java.net >> Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button >> >> On 8/21/2015 3:10 PM, Rajeev Chamyal wrote: >>> Hi, >>> >>> Please review the following fix for jdk9: >>> >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8025082 >>> >>> webrev: >>> http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.00/ >>> >>> >>> >>> The highlight of selected text in JTextPane/JTextArea is lost if some other component (e.g. button clicked) gains focus. >>> Added a method to update the selection ownership for caret when text is selected/unselected in the JTextPane/JTextArea. >> - The updateOwnsSelection() method can be shorter if use the conditional operator '?' >> https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.25 >> - SwingUtilities.invokeAndWait() should be used instead of invokeLater. In other case the system can suspend the EDT thread and robot will start its actions before the createUI() execution. >> - button.getLocationOnScreen() should be called on EDT in the test >> - The actionPerformed() method is not properly formatted >> - What is the reason to use double colons in the error messages? >> - System.out.println calls are not really necessary for the automated test. It also pollute the logs for SQE team when all tests are running. The only exception throwing can be left in the >> actionPerformed() method. >> - line 30 '* **/' - small formatting issue >> >> Thanks, >> Alexandr. >> >>> >>> Regards, >>> Rajeev Chamyal >>> >>> -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Fri Aug 28 11:18:39 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 28 Aug 2015 16:48:39 +0530 Subject: RFR: [9] [JDK-8081491] The case print incomplete. In-Reply-To: <55DDB70D.7010001@oracle.com> References: <55DAFE9C.9030406@oracle.com> <55DC420D.2070009@oracle.com> <55DC48BC.2070508@oracle.com> <55DDB70D.7010001@oracle.com> Message-ID: <55E0438F.6010407@oracle.com> 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 >>> >> > From rajeev.chamyal at oracle.com Mon Aug 31 06:27:11 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Sun, 30 Aug 2015 23:27:11 -0700 (PDT) Subject: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button In-Reply-To: <55DF0702.9070301@oracle.com> References: <369f7e0e-07a8-477e-aac8-7c5d1079db15@default> <55DC2E09.3040604@oracle.com> <55DDBA88.6000305@oracle.com> <70f0e584-2ba1-4ca0-9157-aeb75fe8915b@default> <55DF0702.9070301@oracle.com> Message-ID: Hello Sergey, Please review the updated webrev. http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.03/ Regards, Rajeev Chamyal -----Original Message----- From: Sergey Bylokhov Sent: Thursday, August 27, 2015 6:18 PM To: Rajeev Chamyal; Alexander Scherbatiy; Alexander Zvegintsev; swing-dev at openjdk.java.net Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button Hi, Rajeev. A few comments about a tests: - The (SwingUtilities.isEventDispatchThread()) inside a invokeAndWait is not necessary, it is not a problem, but this is an overhead to validate this in each test. - I suggest to move the window to the center of the screen(frame.setLocationRelativeTo(null)) and clicks to the center of the button, otherwise the test can fail if the window will be opened under the dashboard(dock), which can be placed on the left side of the screen. - Please always close all resources, which were opened by the test. in your case this is a frame, which should be disposed at the end of the test. Small note about a style, probably this style will be a little bit readable? But this is up to you. /** * Updates ownsSelection based on text selection in the caret. */ private void updateOwnsSelection() { ownsSelection = selectionTag != null && SwingUtilities2.canAccessSystemClipboard(); } On 27.08.15 13:37, Rajeev Chamyal wrote: > Hello All, > > Please review the updated webrev. > > Webrev: http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 > > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexander Scherbatiy > Sent: Wednesday, August 26, 2015 6:39 PM > To: Rajeev Chamyal > Cc: Alexander Zvegintsev; Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button > > On 8/26/2015 10:20 AM, Rajeev Chamyal wrote: >> Hello All, >> >> Please review the updated fix for bug JDK-8025082. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 >> Webrev : http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.01/ > - the updateOwnsSelection method should be properly formatted > See the Java Code Conventions: > http://www.oracle.com/technetwork/java/codeconventions-150003.pdf > and new discussed Java Style Guidelines: > http://cr.openjdk.java.net/~alundblad/styleguide > - lines which are longer than 80 characters should be split > > Thanks, > Alexandr. >> >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Alexander Scherbatiy >> Sent: Tuesday, August 25, 2015 2:28 PM >> To: Rajeev Chamyal >> Cc: swing-dev at openjdk.java.net >> Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button >> >> On 8/21/2015 3:10 PM, Rajeev Chamyal wrote: >>> Hi, >>> >>> Please review the following fix for jdk9: >>> >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8025082 >>> >>> webrev: >>> http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.00/ >>> >>> >>> >>> The highlight of selected text in JTextPane/JTextArea is lost if some other component (e.g. button clicked) gains focus. >>> Added a method to update the selection ownership for caret when text is selected/unselected in the JTextPane/JTextArea. >> - The updateOwnsSelection() method can be shorter if use the conditional operator '?' >> https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.25 >> - SwingUtilities.invokeAndWait() should be used instead of invokeLater. In other case the system can suspend the EDT thread and robot will start its actions before the createUI() execution. >> - button.getLocationOnScreen() should be called on EDT in the test >> - The actionPerformed() method is not properly formatted >> - What is the reason to use double colons in the error messages? >> - System.out.println calls are not really necessary for the automated test. It also pollute the logs for SQE team when all tests are running. The only exception throwing can be left in the >> actionPerformed() method. >> - line 30 '* **/' - small formatting issue >> >> Thanks, >> Alexandr. >> >>> >>> Regards, >>> Rajeev Chamyal >>> >>> -- Best regards, Sergey. From shilpi.rastogi at oracle.com Mon Aug 31 09:00:33 2015 From: shilpi.rastogi at oracle.com (shilpi rastogi) Date: Mon, 31 Aug 2015 14:30:33 +0530 Subject: REM: Re: [9-client] Review request for bug 7124238 : [TEST_BUG] Font in BasicHTML document is bigger than it should be In-Reply-To: <55DB26C3.7080705@oracle.com> References: <55CC283F.2090901@oracle.com> <55CC4689.1070005@oracle.com> <55CC84AF.2000104@oracle.com> <55CCA49A.3000103@oracle.com> <55CD99D3.4060907@oracle.com> <55CD9E85.2070909@oracle.com> <55DB0440.4070803@oracle.com> <55DB26C3.7080705@oracle.com> Message-ID: <55E417B1.4080407@oracle.com> Hi All, Please review updated webrev open: http://cr.openjdk.java.net/~psadhukhan/shilpi/webrev-7124238/open-7124238/webrev/ closed: http://cr.openjdk.java.net/~psadhukhan/shilpi/webrev-7124238/closed-7124238/webrev/ Thanks Shilpi On 8/24/2015 7:44 PM, Alexander Zvegintsev wrote: > Hi Shilpi, > > 56 test(); > 57 f.dispose(); > > > In case of test failure runtime exception will be thrown, thus > f.dispose() will not be called. > So it would be better to call it from a finally block. > > The fix contains mixed tab/spaces indentation(we are using spaces), > trailing whitespaces, > this will prevent push to openjdk repository. > > Also there are a lot of empty lines at the end of file. > > Thanks, > > Alexander. > > On 08/24/2015 02:47 PM, shilpi rastogi wrote: >> Hi all, >> >> Gentle reminder. >> >> Thanks >> Shilpi >> On 8/14/2015 1:23 PM, Alexander Scherbatiy wrote: >>> >>> The fix looks good to me. >>> >>> Thanks, >>> Alexandr. >>> >>> On 8/14/2015 10:33 AM, shilpi rastogi wrote: >>>> Hi All, >>>> >>>> Thanks Alexander for comments! >>>> >>>> I tried to incorporate all changes suggested by you. >>>> >>>> Please have a look >>>> >>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.05/ >>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.04/ >>>> >>>> >>>> Thanks >>>> Shilpi >>>> >>>> On 8/13/2015 7:37 PM, Alexander Scherbatiy wrote: >>>>> On 8/13/2015 2:51 PM, shilpi rastogi wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review updated webrev >>>>>> >>>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.03/ >>>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.02/ >>>>> >>>>> - I forgot to mention that the rule is to split line if it >>>>> longer than 80 characters. Long lines are annoying for >>>>> side-by-side views. >>>>> IDEs usually allow to configure right margin settings in a >>>>> editor for this purposes. >>>>> - It is better to define that createAndShowGUI() method throws >>>>> Exception. In this case the try/catch block for L&F setting is >>>>> unnecessary. >>>>> - SwingUtilities.invokeAndWait() does not throw AWTException so >>>>> its declaration can be removed. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Shilpi >>>>>> >>>>>> >>>>>> On 8/13/2015 12:56 PM, Alexander Scherbatiy wrote: >>>>>>> On 8/13/2015 8:16 AM, shilpi rastogi wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review a test bug fix >>>>>>>> >>>>>>>> TEST : >>>>>>>> closed/javax/swing/plaf/basic/BasicHTML/4960629/bug4960629.java >>>>>>>> BUG ID - https://bugs.openjdk.java.net/browse/JDK-7124238 >>>>>>>> >>>>>>>> Pleasemove the test from closed repo to open repo. >>>>>>>> >>>>>>>> The webrev is: >>>>>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.01 add to >>>>>>>> open repo >>>>>>> >>>>>>> - The long lines should be split so they fit to a page >>>>>>> - Exceptions should be re-thrown. In other case they are >>>>>>> just printed but jtreg decides that a test is passed. >>>>>>> >>>>>>> 69 try { >>>>>>> 70 createAndShowGUI(); >>>>>>> 71 } catch (AWTException e) { >>>>>>> 72 e.printStackTrace(); >>>>>>> 73 } >>>>>>> >>>>>>> - The test methods can throw a general Exceptioninstead of >>>>>>> several concrete ones. This usually makes a test more readable. >>>>>>> It also allows to omit try/catch block for the the >>>>>>> UIManager.setLookAndFeel() call. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.00/ >>>>>>>> - >>>>>>>> diff with previous version of the closed test. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Shilpi >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexander.zvegintsev at oracle.com Mon Aug 31 11:07:37 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 31 Aug 2015 14:07:37 +0300 Subject: REM: Re: [9-client] Review request for bug 7124238 : [TEST_BUG] Font in BasicHTML document is bigger than it should be In-Reply-To: <55E417B1.4080407@oracle.com> References: <55CC283F.2090901@oracle.com> <55CC4689.1070005@oracle.com> <55CC84AF.2000104@oracle.com> <55CCA49A.3000103@oracle.com> <55CD99D3.4060907@oracle.com> <55CD9E85.2070909@oracle.com> <55DB0440.4070803@oracle.com> <55DB26C3.7080705@oracle.com> <55E417B1.4080407@oracle.com> Message-ID: <55E43579.5020606@oracle.com> Hi Shilpi, the fix looks good to me Thanks, Alexander. On 08/31/2015 12:00 PM, shilpi rastogi wrote: > Hi All, > > Please review updated webrev > > open: > http://cr.openjdk.java.net/~psadhukhan/shilpi/webrev-7124238/open-7124238/webrev/ > > closed: > http://cr.openjdk.java.net/~psadhukhan/shilpi/webrev-7124238/closed-7124238/webrev/ > > > > Thanks > Shilpi > > On 8/24/2015 7:44 PM, Alexander Zvegintsev wrote: >> Hi Shilpi, >> >> 56 test(); >> 57 f.dispose(); >> >> >> In case of test failure runtime exception will be thrown, thus >> f.dispose() will not be called. >> So it would be better to call it from a finally block. >> >> The fix contains mixed tab/spaces indentation(we are using spaces), >> trailing whitespaces, >> this will prevent push to openjdk repository. >> >> Also there are a lot of empty lines at the end of file. >> >> Thanks, >> >> Alexander. >> >> On 08/24/2015 02:47 PM, shilpi rastogi wrote: >>> Hi all, >>> >>> Gentle reminder. >>> >>> Thanks >>> Shilpi >>> On 8/14/2015 1:23 PM, Alexander Scherbatiy wrote: >>>> >>>> The fix looks good to me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 8/14/2015 10:33 AM, shilpi rastogi wrote: >>>>> Hi All, >>>>> >>>>> Thanks Alexander for comments! >>>>> >>>>> I tried to incorporate all changes suggested by you. >>>>> >>>>> Please have a look >>>>> >>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.05/ >>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.04/ >>>>> >>>>> >>>>> Thanks >>>>> Shilpi >>>>> >>>>> On 8/13/2015 7:37 PM, Alexander Scherbatiy wrote: >>>>>> On 8/13/2015 2:51 PM, shilpi rastogi wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Please review updated webrev >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.03/ >>>>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.02/ >>>>>> >>>>>> - I forgot to mention that the rule is to split line if it >>>>>> longer than 80 characters. Long lines are annoying for >>>>>> side-by-side views. >>>>>> IDEs usually allow to configure right margin settings in a >>>>>> editor for this purposes. >>>>>> - It is better to define that createAndShowGUI() method throws >>>>>> Exception. In this case the try/catch block for L&F setting is >>>>>> unnecessary. >>>>>> - SwingUtilities.invokeAndWait() does not throw AWTException so >>>>>> its declaration can be removed. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Shilpi >>>>>>> >>>>>>> >>>>>>> On 8/13/2015 12:56 PM, Alexander Scherbatiy wrote: >>>>>>>> On 8/13/2015 8:16 AM, shilpi rastogi wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review a test bug fix >>>>>>>>> >>>>>>>>> TEST : >>>>>>>>> closed/javax/swing/plaf/basic/BasicHTML/4960629/bug4960629.java >>>>>>>>> BUG ID - https://bugs.openjdk.java.net/browse/JDK-7124238 >>>>>>>>> >>>>>>>>> Pleasemove the test from closed repo to open repo. >>>>>>>>> >>>>>>>>> The webrev is: >>>>>>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.01 add to >>>>>>>>> open repo >>>>>>>> >>>>>>>> - The long lines should be split so they fit to a page >>>>>>>> - Exceptions should be re-thrown. In other case they are >>>>>>>> just printed but jtreg decides that a test is passed. >>>>>>>> >>>>>>>> 69 try { >>>>>>>> 70 createAndShowGUI(); >>>>>>>> 71 } catch (AWTException e) { >>>>>>>> 72 e.printStackTrace(); >>>>>>>> 73 } >>>>>>>> >>>>>>>> - The test methods can throw a general Exceptioninstead of >>>>>>>> several concrete ones. This usually makes a test more readable. >>>>>>>> It also allows to omit try/catch block for the the >>>>>>>> UIManager.setLookAndFeel() call. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~sgupta/7124238/webrev.00/ >>>>>>>>> - >>>>>>>>> diff with previous version of the closed test. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Shilpi >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From Sergey.Bylokhov at oracle.com Mon Aug 31 11:10:19 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 31 Aug 2015 14:10:19 +0300 Subject: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button In-Reply-To: References: <369f7e0e-07a8-477e-aac8-7c5d1079db15@default> <55DC2E09.3040604@oracle.com> <55DDBA88.6000305@oracle.com> <70f0e584-2ba1-4ca0-9157-aeb75fe8915b@default> <55DF0702.9070301@oracle.com> Message-ID: <55E4361B.8030207@oracle.com> The fix looks fine. Thanks. Please fix this typo in the test before the push: 25 * @test @bug 8025082 On 31.08.15 9:27, Rajeev Chamyal wrote: > Hello Sergey, > > Please review the updated webrev. > > http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.03/ > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Sergey Bylokhov > Sent: Thursday, August 27, 2015 6:18 PM > To: Rajeev Chamyal; Alexander Scherbatiy; Alexander Zvegintsev; swing-dev at openjdk.java.net > Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button > > Hi, Rajeev. > A few comments about a tests: > - The (SwingUtilities.isEventDispatchThread()) inside a invokeAndWait is not necessary, it is not a problem, but this is an overhead to validate this in each test. > - I suggest to move the window to the center of the > screen(frame.setLocationRelativeTo(null)) and clicks to the center of the button, otherwise the test can fail if the window will be opened under the dashboard(dock), which can be placed on the left side of the screen. > - Please always close all resources, which were opened by the test. in your case this is a frame, which should be disposed at the end of the test. > > Small note about a style, probably this style will be a little bit readable? But this is up to you. > /** > * Updates ownsSelection based on text selection in the caret. > */ > private void updateOwnsSelection() { > ownsSelection = selectionTag != null > && SwingUtilities2.canAccessSystemClipboard(); > } > > > > On 27.08.15 13:37, Rajeev Chamyal wrote: >> Hello All, >> >> Please review the updated webrev. >> >> Webrev: http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.02/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 >> >> >> Regards, >> Rajeev Chamyal >> >> -----Original Message----- >> From: Alexander Scherbatiy >> Sent: Wednesday, August 26, 2015 6:39 PM >> To: Rajeev Chamyal >> Cc: Alexander Zvegintsev; Sergey Bylokhov; swing-dev at openjdk.java.net >> Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button >> >> On 8/26/2015 10:20 AM, Rajeev Chamyal wrote: >>> Hello All, >>> >>> Please review the updated fix for bug JDK-8025082. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025082 >>> Webrev : http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.01/ >> - the updateOwnsSelection method should be properly formatted >> See the Java Code Conventions: >> http://www.oracle.com/technetwork/java/codeconventions-150003.pdf >> and new discussed Java Style Guidelines: >> http://cr.openjdk.java.net/~alundblad/styleguide >> - lines which are longer than 80 characters should be split >> >> Thanks, >> Alexandr. >>> >>> Regards, >>> Rajeev Chamyal >>> >>> -----Original Message----- >>> From: Alexander Scherbatiy >>> Sent: Tuesday, August 25, 2015 2:28 PM >>> To: Rajeev Chamyal >>> Cc: swing-dev at openjdk.java.net >>> Subject: Re: RFR: [JDK-8025082] The behaviour of the highlight will be lost after clicking the set button >>> >>> On 8/21/2015 3:10 PM, Rajeev Chamyal wrote: >>>> Hi, >>>> >>>> Please review the following fix for jdk9: >>>> >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8025082 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~psadhukhan/rajeev/8025082/webrev.00/ >>>> >>>> >>>> >>>> The highlight of selected text in JTextPane/JTextArea is lost if some other component (e.g. button clicked) gains focus. >>>> Added a method to update the selection ownership for caret when text is selected/unselected in the JTextPane/JTextArea. >>> - The updateOwnsSelection() method can be shorter if use the conditional operator '?' >>> https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.25 >>> - SwingUtilities.invokeAndWait() should be used instead of invokeLater. In other case the system can suspend the EDT thread and robot will start its actions before the createUI() execution. >>> - button.getLocationOnScreen() should be called on EDT in the test >>> - The actionPerformed() method is not properly formatted >>> - What is the reason to use double colons in the error messages? >>> - System.out.println calls are not really necessary for the automated test. It also pollute the logs for SQE team when all tests are running. The only exception throwing can be left in the >>> actionPerformed() method. >>> - line 30 '* **/' - small formatting issue >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> Regards, >>>> Rajeev Chamyal >>>> >>>> > > -- Best regards, Sergey. From rajeev.chamyal at oracle.com Mon Aug 31 12:19:49 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Mon, 31 Aug 2015 05:19:49 -0700 (PDT) Subject: Bug : JDK-8078831 Mismatch of getPreferredSize() and getPreferredScrollableViewportSize() values in WindowsClassicLookAndFeel In-Reply-To: <55DEFF77.6020304@oracle.com> References: <1ecbe098-70b2-4f00-a9dd-0c5b455f1cb0@default> <55DDBB2F.3030909@oracle.com> <0b28ec21-ed8d-4650-a2a0-080e9f9427a4@default> <55DEFF77.6020304@oracle.com> Message-ID: Hi All, Please review the following webrev. http://cr.openjdk.java.net/~psadhukhan/rajeev/5042886/webrev.open/ http://cr.openjdk.java.net/~psadhukhan/rajeev/5042886/webrev.closed/ Test has been moved to open repository. Regards, Rajeev Chamyal -----Original Message----- From: Alexander Scherbatiy Sent: Thursday, August 27, 2015 5:46 PM To: Rajeev Chamyal Cc: Alexander Zvegintsev; Sergey Bylokhov; swing-dev at openjdk.java.net Subject: Re: Bug : JDK-8078831 Mismatch of getPreferredSize() and getPreferredScrollableViewportSize() values in WindowsClassicLookAndFeel On 8/27/2015 1:34 PM, Rajeev Chamyal wrote: > Hello All, > > Please review the updated fix with latest review comments. > > http://cr.openjdk.java.net/~psadhukhan/rajeev/5042886/webrev.01/ This looks better. Please, move it to the open repository, add copyright and properly format the code: Java Code Conventions: http://www.oracle.com/technetwork/java/codeconventions-150003.pdf new discussed Java Style Guidelines: http://cr.openjdk.java.net/~alundblad/styleguide Thanks, Alexandr. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Alexander Scherbatiy > Sent: Wednesday, August 26, 2015 6:42 PM > To: Rajeev Chamyal > Cc: Alexander Zvegintsev; Sergey Bylokhov; swing-dev at openjdk.java.net > Subject: Re: Bug : JDK-8078831 Mismatch of getPreferredSize() and > getPreferredScrollableViewportSize() values in > WindowsClassicLookAndFeel > > On 8/26/2015 12:13 PM, Rajeev Chamyal wrote: >> Hi, >> >> Please review the following fix for jdk9: >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8078831 >> >> Webrev : >> http://cr.openjdk.java.net/~psadhukhan/rajeev/5042886/webrev.00/ >> >> >> getPreferredScrollableViewportSize() must not return the same as getPreferredSize() but it should return equal or less size. Test condition was checking for inequality and throwing Runtime exception. >> > Please, split lines which are longer than 80 characters. > > Thanks, > Alexandr. > >> Regards, >> Rajeev Chamyal >> From alexandr.scherbatiy at oracle.com Mon Aug 31 12:19:03 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 31 Aug 2015 15:19:03 +0300 Subject: [9] Review request for 8134721 NPE in SwingUtilities2.drawChars after JDK-6302464 Message-ID: <55E44637.4050102@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8134721 webrev: http://cr.openjdk.java.net/~alexsch/8134721/webrev.00 The component is checked to be non null. Thanks, Alexandr. From rajeev.chamyal at oracle.com Mon Aug 31 12:44:29 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Mon, 31 Aug 2015 05:44:29 -0700 (PDT) Subject: Bug: JDK-7190596 Nimbus: preferred sizes of components not less than that of tabbed pane Message-ID: <0e6f2481-a710-4467-8b35-de4be71323e8@default> Hi, Please review the following fix for jdk9: Bug: https://bugs.openjdk.java.net/browse/JDK-7190596 Webrev : http://cr.openjdk.java.net/~psadhukhan/rajeev/7190596/webrev.00/ Nimbus looks and feel is not setting default Insets for the parent component which results in same size for parent and child components. Added a default Insets value for Nimbus look and feel, similar to other layouts. Regards, Rajeev Chamyal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Aug 31 13:54:41 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 31 Aug 2015 16:54:41 +0300 Subject: [9] Review request for 8134721 NPE in SwingUtilities2.drawChars after JDK-6302464 In-Reply-To: <55E44637.4050102@oracle.com> References: <55E44637.4050102@oracle.com> Message-ID: <55E45CA1.7020204@oracle.com> Looks fine. On 31.08.15 15:19, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8134721 > webrev: http://cr.openjdk.java.net/~alexsch/8134721/webrev.00 > > > The component is checked to be non null. > > Thanks, > Alexandr. > -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Mon Aug 31 14:17:47 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 31 Aug 2015 17:17:47 +0300 Subject: [9] Review request for 8134721 NPE in SwingUtilities2.drawChars after JDK-6302464 In-Reply-To: <55E45CA1.7020204@oracle.com> References: <55E44637.4050102@oracle.com> <55E45CA1.7020204@oracle.com> Message-ID: <55E4620B.2070004@oracle.com> +1 Thanks, Alexander. On 08/31/2015 04:54 PM, Sergey Bylokhov wrote: > Looks fine. > > On 31.08.15 15:19, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8134721 >> webrev: http://cr.openjdk.java.net/~alexsch/8134721/webrev.00 >> >> >> The component is checked to be non null. >> >> Thanks, >> Alexandr. >> > >