From holger.brands at googlemail.com Sat Mar 1 11:57:36 2014 From: holger.brands at googlemail.com (Holger Brands) Date: Sat, 1 Mar 2014 12:57:36 +0100 Subject: Another incarnation of the EventQueue NPE In-Reply-To: <8583BE90-FF1D-45B0-9215-960C7CA9A2D4@oracle.com> References: <8583BE90-FF1D-45B0-9215-960C7CA9A2D4@oracle.com> Message-ID: Hello Petr, is there a known workaround for this particular issue? If not, this regression should be fixed ASAP in my opinion. FileChooser operations are essential for a lot of webstart applications. It would be great if this issue could be found in JIRA sonewhere so it doesn't get lost... Thanks, Holger 2014-02-20 20:20 GMT+01:00 Petr Pchelko : > Hello, Holger. > > Thank you for the report. > > The reason is that the ThreadPool is creating a thread in a ThreadGroup > which is not associated with any AppContext. > I suppose that the fix for JDK-8019274 would also resolve this issue, but > this should be checked. I'll write back as I have a chance to check this. > > With best regards. Petr. > > 20 ????. 2014 ?., ? 11:01 ????? ???????, Holger Brands < > holger.brands at googlemail.com> ???????(?): > > Hi there, > > this is meant as a comment to issue > https://bugs.openjdk.java.net/browse/JDK-8019274 > which describes a problem of RMI threads calling out to > java.awt.EventQueue in a java webstart app. > > I think it's a more general problem, not only related to RMI threads. > Another scenario is the following: > When you open a JFileChooser in a Java Webstart application, change the > view to "Details" such that column headers appear and then click on the > name column to sort the shown entries, I get the > following exception on Windows 7, both with Java 7u45 and Java 7u51: > > java.lang.NullPointerException > at sun.awt.SunToolkit.getSystemEventQueueImplPP(Unknown Source) > at sun.awt.SunToolkit.getSystemEventQueueImplPP(Unknown Source) > at sun.awt.SunToolkit.getSystemEventQueueImpl(Unknown Source) > at java.awt.Toolkit.getEventQueue(Unknown Source) > at java.awt.EventQueue.isDispatchThread(Unknown Source) > at javax.swing.SwingUtilities.isEventDispatchThread(Unknown Source) > at javax.swing.JComponent.revalidate(Unknown Source) > at javax.swing.JTable.resizeAndRepaint(Unknown Source) > at javax.swing.JTable.sortedTableChanged(Unknown Source) > at javax.swing.JTable.sorterChanged(Unknown Source) > at javax.swing.RowSorter.fireRowSorterChanged(Unknown Source) > at javax.swing.RowSorter.fireRowSorterChanged(Unknown Source) > at javax.swing.DefaultRowSorter.sort(Unknown Source) > at sun.swing.FilePane$DetailsTableRowSorter.access$1601(Unknown > Source) > at sun.swing.FilePane$DetailsTableRowSorter$1.call(Unknown Source) > at sun.swing.FilePane$DetailsTableRowSorter$1.call(Unknown Source) > at java.util.concurrent.FutureTask.run(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Unknown > Source) > at java.lang.Thread.run(Unknown Source) > > It's a similiar stacktrace but not quite the same. > But I bet it's the same cause. > > Please ensure when fixing JDK-8019274 that this variant is also fixed. > Also, I would be interested in a workaround for this FileChooser sorting > issue. > > Thanks, > Holger > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Mar 3 13:24:41 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 03 Mar 2014 17:24:41 +0400 Subject: [9] Review request for 8034955 JLabel/JToolTip throw ClassCastException for "a" Message-ID: <53148299.7060607@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8034955 webrev: http://cr.openjdk.java.net/~alexsch/8034955/webrev.00 The missed 'instanceof check' is added in the fix. Thanks, Alexandr. From sergey.malenkov at oracle.com Tue Mar 4 14:19:33 2014 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Tue, 04 Mar 2014 18:19:33 +0400 Subject: <Swing Dev> Approved: [9] Review request for 8034955 JLabel/JToolTip throw ClassCastException for "<html>a<title>" In-Reply-To: <53148299.7060607@oracle.com> References: <53148299.7060607@oracle.com> Message-ID: <5315E0F5.1020008@oracle.com> The fix looks good to me. SAM On 03.03.2014 17:24, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8034955 > webrev: http://cr.openjdk.java.net/~alexsch/8034955/webrev.00 > > The missed 'instanceof check' is added in the fix. > > Thanks, > Alexandr. > From petr.pchelko at oracle.com Tue Mar 4 14:27:28 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Tue, 4 Mar 2014 18:27:28 +0400 Subject: <Swing Dev> Approved: [9] Review request for 8034955 JLabel/JToolTip throw ClassCastException for "<html>a<title>" In-Reply-To: <5315E0F5.1020008@oracle.com> References: <53148299.7060607@oracle.com> <5315E0F5.1020008@oracle.com> Message-ID: <FBCF40F3-7065-42D3-9A4F-DCD695E2BECF@oracle.com> And to me. With best regards. Petr. On 04.03.2014, at 18:19, sergey malenkov <sergey.malenkov at oracle.com> wrote: > The fix looks good to me. > > SAM > > On 03.03.2014 17:24, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8034955 >> webrev: http://cr.openjdk.java.net/~alexsch/8034955/webrev.00 >> >> The missed 'instanceof check' is added in the fix. >> >> Thanks, >> Alexandr. >> > From joe.darcy at oracle.com Wed Mar 5 20:30:44 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 05 Mar 2014 12:30:44 -0800 Subject: <Swing Dev> JDK 9 RFR of JDK-8035692 : Fix serial lint warnings in mac-specific code Message-ID: <53178974.1050706@oracle.com> Hello, Please review this webrev which addresses serial warnings in mac-specific code: JDK-8035692 : Fix serial lint warnings in mac-specific code http://cr.openjdk.java.net/~darcy/8035692.0/ Thanks, -Joe From Alan.Bateman at oracle.com Wed Mar 5 21:19:04 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Mar 2014 21:19:04 +0000 Subject: <Swing Dev> JDK 9 RFR of JDK-8035692 : Fix serial lint warnings in mac-specific code In-Reply-To: <53178974.1050706@oracle.com> References: <53178974.1050706@oracle.com> Message-ID: <531794C8.6040007@oracle.com> On 05/03/2014 20:30, Joe Darcy wrote: > Hello, > > Please review this webrev which addresses serial warnings in > mac-specific code: > > JDK-8035692 : Fix serial lint warnings in mac-specific code > http://cr.openjdk.java.net/~darcy/8035692.0/ > This looks okay to me on the assumption that nothing of these types leak into the serialized stream when serializing a supported type that has serialization compatibility guarantees. Also double check LWCToolkit.java before you push as there is a spurious character in the webrev at L145. -Alan. From xiaoyuandlg at hotmail.com Thu Mar 6 04:22:26 2014 From: xiaoyuandlg at hotmail.com (xiaoyuandlg) Date: Wed, 5 Mar 2014 20:22:26 -0800 (PST) Subject: <Swing Dev> JComboBox with dynamic ComboBoxModel In-Reply-To: <CAC1knhfAu3Cgpr_xP_dhczEnhybvbQdD_aD8Rz7BJebp6Lm6PA@mail.gmail.com> References: <CAC1knhfAu3Cgpr_xP_dhczEnhybvbQdD_aD8Rz7BJebp6Lm6PA@mail.gmail.com> Message-ID: <1394079746562-180571.post@n7.nabble.com> My first time to see such kind of question. You may consider to shift to other combobox control <http://www.kettic.com/winforms_ui/multi_column_combobox.shtml> ? -- View this message in context: http://openjdk.5641.n7.nabble.com/Swing-Dev-JComboBox-with-dynamic-ComboBoxModel-tp118497p180571.html Sent from the OpenJDK Swing Development mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20140305/51176a08/attachment.html> From xiaoyuandlg at hotmail.com Thu Mar 6 06:12:37 2014 From: xiaoyuandlg at hotmail.com (xiaoyuandlg) Date: Wed, 5 Mar 2014 22:12:37 -0800 (PST) Subject: <Swing Dev> [9] Review request for 7094099: DropDown List of JComboBox detached In-Reply-To: <5302059A.7020403@oracle.com> References: <52FE35D8.2020701@oracle.com> <5302059A.7020403@oracle.com> Message-ID: <1394086357000-180575.post@n7.nabble.com> Nice fix, I also found the dropdown list of combobox <http://www.kettic.com/winforms_ui/csharp_guide/multi_column_combobox_dropdown.shtml> be really nice to me. -- View this message in context: http://openjdk.5641.n7.nabble.com/Swing-Dev-9-Review-request-for-7094099-DropDown-List-of-JComboBox-detached-tp178094p180575.html Sent from the OpenJDK Swing Development mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20140305/0ffe8ca9/attachment.html> From damage3025 at gmail.com Thu Mar 6 13:48:33 2014 From: damage3025 at gmail.com (Ma Xiaojun) Date: Thu, 6 Mar 2014 21:48:33 +0800 Subject: <Swing Dev> Support Unity Global Menu? Message-ID: <CAGVx7UUKycqVFgy8fk1moW3Lr09T7EciRJhHdSJpCZaJWDakbQ@mail.gmail.com> A link tells everything: http://www.webupd8.org/2014/02/get-unity-global-menu-hud-support-for.html I wonder how this kind of fundamental stuff is handled by third-party... From anthony.petrov at oracle.com Thu Mar 6 20:36:21 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 07 Mar 2014 00:36:21 +0400 Subject: <Swing Dev> Support Unity Global Menu? In-Reply-To: <CAGVx7UUKycqVFgy8fk1moW3Lr09T7EciRJhHdSJpCZaJWDakbQ@mail.gmail.com> References: <CAGVx7UUKycqVFgy8fk1moW3Lr09T7EciRJhHdSJpCZaJWDakbQ@mail.gmail.com> Message-ID: <5318DC45.4070508@oracle.com> Hi Ma, If [1] was fixed already, I'd suggest you to migrate to JavaFX right away. But alas, it isn't implemented yet. Nonetheless, I still suggest you to migrate, because it is unlikely that Swing/AWT will ever support this feature on X11. [1] https://javafx-jira.kenai.com/browse/RT-28202 -- best regards, Anthony On 3/6/2014 5:48 PM, Ma Xiaojun wrote: > A link tells everything: > http://www.webupd8.org/2014/02/get-unity-global-menu-hud-support-for.html > > I wonder how this kind of fundamental stuff is handled by third-party... > From joe.darcy at oracle.com Mon Mar 10 06:55:54 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 09 Mar 2014 23:55:54 -0700 Subject: <Swing Dev> JDK 9 RFR of JDK-8033908: Fix serial lint warnings in com.sun.java.swing.plaf In-Reply-To: <52F5399F.6000903@oracle.com> References: <52F490F7.3090500@oracle.com> <52F4A883.1010804@oracle.com> <52F5399F.6000903@oracle.com> Message-ID: <531D61FA.9090806@oracle.com> Hello, I've adjusted the patch based on changes to the client repo in the interim: http://cr.openjdk.java.net/~darcy/8033908.1/ Please review. Thanks, -Joe On 02/07/2014 11:53 AM, Joe Darcy wrote: > On 02/07/2014 01:33 AM, Alan Bateman wrote: >> On 07/02/2014 07:53, Joe Darcy wrote: >>> Hello, >>> >>> Please review the webrev to address >>> >>> JDK-8033908: Fix serial lint warnings in com.sun.java.swing.plaf >>> http://cr.openjdk.java.net/~darcy/8033908.0/ >> This looks fine although for cases where you comment that the >> supertypes aren't serial compatible across versions then I didn't >> check that the supertypes document it (I assume they do). >> > > Right, the supertypes in question are generally those covered in > > 8032627: Add @SuppressWarnings("serial") to appropriate > javax.swing classes > > which are the Swing type which say "I'm serializable on the same > version, but not across versions." Some of the types in question are > subtypes of types in com.sun.* which directly document this constraint > too. > > Thanks for the review, > > -Joe > From Alan.Bateman at oracle.com Mon Mar 10 10:30:52 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Mar 2014 10:30:52 +0000 Subject: <Swing Dev> JDK 9 RFR of JDK-8033908: Fix serial lint warnings in com.sun.java.swing.plaf In-Reply-To: <531D61FA.9090806@oracle.com> References: <52F490F7.3090500@oracle.com> <52F4A883.1010804@oracle.com> <52F5399F.6000903@oracle.com> <531D61FA.9090806@oracle.com> Message-ID: <531D945C.0@oracle.com> On 10/03/2014 06:55, Joe Darcy wrote: > Hello, > > I've adjusted the patch based on changes to the client repo in the > interim: > > http://cr.openjdk.java.net/~darcy/8033908.1/ > > Please review. > This looks okay to me. A minor inconsistency is tmp, tmp2, .. in one file whereas it's tmp1, tmp2, .. in another. -Alan From Sergey.Bylokhov at oracle.com Mon Mar 10 11:05:56 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 10 Mar 2014 15:05:56 +0400 Subject: <Swing Dev> JDK 9 RFR of JDK-8033908: Fix serial lint warnings in com.sun.java.swing.plaf In-Reply-To: <531D61FA.9090806@oracle.com> References: <52F490F7.3090500@oracle.com> <52F4A883.1010804@oracle.com> <52F5399F.6000903@oracle.com> <531D61FA.9090806@oracle.com> Message-ID: <531D9C94.7030309@oracle.com> Hi, Joe. The fix looks good to me. On 10.03.2014 10:55, Joe Darcy wrote: > Hello, > > I've adjusted the patch based on changes to the client repo in the > interim: > > http://cr.openjdk.java.net/~darcy/8033908.1/ > > Please review. > > Thanks, > > -Joe > > On 02/07/2014 11:53 AM, Joe Darcy wrote: >> On 02/07/2014 01:33 AM, Alan Bateman wrote: >>> On 07/02/2014 07:53, Joe Darcy wrote: >>>> Hello, >>>> >>>> Please review the webrev to address >>>> >>>> JDK-8033908: Fix serial lint warnings in com.sun.java.swing.plaf >>>> http://cr.openjdk.java.net/~darcy/8033908.0/ >>> This looks fine although for cases where you comment that the >>> supertypes aren't serial compatible across versions then I didn't >>> check that the supertypes document it (I assume they do). >>> >> >> Right, the supertypes in question are generally those covered in >> >> 8032627: Add @SuppressWarnings("serial") to appropriate >> javax.swing classes >> >> which are the Swing type which say "I'm serializable on the same >> version, but not across versions." Some of the types in question are >> subtypes of types in com.sun.* which directly document this >> constraint too. >> >> Thanks for the review, >> >> -Joe >> > -- Best regards, Sergey. From joe.darcy at oracle.com Mon Mar 10 21:14:58 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 10 Mar 2014 14:14:58 -0700 Subject: <Swing Dev> JDK 9 RFR of JDK-8035692 : Fix serial lint warnings in mac-specific code In-Reply-To: <531794C8.6040007@oracle.com> References: <53178974.1050706@oracle.com> <531794C8.6040007@oracle.com> Message-ID: <531E2B52.3050505@oracle.com> *ping* Any other comments on this changeset? Thanks, -Joe On 03/05/2014 01:19 PM, Alan Bateman wrote: > On 05/03/2014 20:30, Joe Darcy wrote: >> Hello, >> >> Please review this webrev which addresses serial warnings in >> mac-specific code: >> >> JDK-8035692 : Fix serial lint warnings in mac-specific code >> http://cr.openjdk.java.net/~darcy/8035692.0/ >> > This looks okay to me on the assumption that nothing of these types > leak into the serialized stream when serializing a supported type that > has serialization compatibility guarantees. > > Also double check LWCToolkit.java before you push as there is a > spurious character in the webrev at L145. > > -Alan. From joe.darcy at oracle.com Tue Mar 11 04:42:28 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 10 Mar 2014 21:42:28 -0700 Subject: <Swing Dev> JDK 9 RFR of JDK-8034169: Fix serial lint warnings in javax.swing In-Reply-To: <53054CFF.4010305@oracle.com> References: <52FC7BA2.7010805@oracle.com> <52FD0F82.7010701@oracle.com> <53041894.9080008@oracle.com> <530515EC.5060801@oracle.com> <53054CFF.4010305@oracle.com> Message-ID: <531E9434.8090709@oracle.com> Hello, I've generated a new version of the webrev: http://cr.openjdk.java.net/~darcy/8034169.1 Compared to the earlier version, this one exclusively uses @SuppressWarnings("serial") rather than adding serialVersionUID fields and it has been updated to account for changes made in the client libraries since the earlier version was sent for review. Thanks, -Joe On 02/19/2014 04:31 PM, Joseph Darcy wrote: > On 2/19/2014 12:37 PM, Phil Race wrote: >> >> >In a small percentage of cases, a serialVersionUID field was added. >> > When such a field was added, the serialver computation was checked >> for consistency on JDK6 and JDK 8. >> >> I'm rather unsure about adding a serialVersionUID to some of these, >> eg RowSorterEvent. >> Looks like all the other javax.swing.event Event types have the usual >> Swing warning that :- >> >> *Warning:* Serialized objects of this class will not be compatible >> with future Swing releases. The current serialization support is >> appropriate for short term storage or RMI between applications >> running the same version of Swing >> >> I think where ever in Swing you did not see that warning it was >> probably an oversight rather >> than implying long-term persistence is supported >> >> In other words where ever I see the annotation added I think there's >> no harm. I'm more worried >> about where I see serialVersionUID added. >> >> So in these cases would be good to have a Swing engineer confirm that >> it is so, for example >> for the Layout classes which also have a serialVersionUID added. I >> don't see how these >> on their own are useful. > > There are about 23 cases in this patch where a serialVersionUID was > added in lieu of a @SuppressWarnings("serial") annotation. > > If the swing team can provide a definitive ruling, I'm happy to swap > these out to be annotations instead. > > Thanks, > > -Joe > From philip.race at oracle.com Thu Mar 13 18:52:18 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 13 Mar 2014 11:52:18 -0700 Subject: <Swing Dev> JDK 9 RFR of JDK-8034169: Fix serial lint warnings in javax.swing In-Reply-To: <531E9434.8090709@oracle.com> References: <52FC7BA2.7010805@oracle.com> <52FD0F82.7010701@oracle.com> <53041894.9080008@oracle.com> <530515EC.5060801@oracle.com> <53054CFF.4010305@oracle.com> <531E9434.8090709@oracle.com> Message-ID: <5321FE62.2030808@oracle.com> Joe, When I open up the patch http://cr.openjdk.java.net/~darcy/8034169.1/jdk.patch and search I see multiple new serialVersionUIDs. Did you miss updating these or do I misunderstand you ? -phil. On 3/10/14 9:42 PM, Joe Darcy wrote: > Hello, > > I've generated a new version of the webrev: > > http://cr.openjdk.java.net/~darcy/8034169.1 > > Compared to the earlier version, this one exclusively uses > @SuppressWarnings("serial") rather than adding serialVersionUID fields > and it has been updated to account for changes made in the client > libraries since the earlier version was sent for review. > > Thanks, > > -Joe > > On 02/19/2014 04:31 PM, Joseph Darcy wrote: >> On 2/19/2014 12:37 PM, Phil Race wrote: >>> >>> >In a small percentage of cases, a serialVersionUID field was added. >>> > When such a field was added, the serialver computation was checked >>> for consistency on JDK6 and JDK 8. >>> >>> I'm rather unsure about adding a serialVersionUID to some of these, >>> eg RowSorterEvent. >>> Looks like all the other javax.swing.event Event types have the >>> usual Swing warning that :- >>> >>> *Warning:* Serialized objects of this class will not be compatible >>> with future Swing releases. The current serialization support is >>> appropriate for short term storage or RMI between applications >>> running the same version of Swing >>> >>> I think where ever in Swing you did not see that warning it was >>> probably an oversight rather >>> than implying long-term persistence is supported >>> >>> In other words where ever I see the annotation added I think there's >>> no harm. I'm more worried >>> about where I see serialVersionUID added. >>> >>> So in these cases would be good to have a Swing engineer confirm >>> that it is so, for example >>> for the Layout classes which also have a serialVersionUID added. I >>> don't see how these >>> on their own are useful. >> >> There are about 23 cases in this patch where a serialVersionUID was >> added in lieu of a @SuppressWarnings("serial") annotation. >> >> If the swing team can provide a definitive ruling, I'm happy to swap >> these out to be annotations instead. >> >> Thanks, >> >> -Joe >> > From philip.race at oracle.com Thu Mar 13 18:55:03 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 13 Mar 2014 11:55:03 -0700 Subject: <Swing Dev> JDK 9 RFR of JDK-8035692 : Fix serial lint warnings in mac-specific code In-Reply-To: <531E2B52.3050505@oracle.com> References: <53178974.1050706@oracle.com> <531794C8.6040007@oracle.com> <531E2B52.3050505@oracle.com> Message-ID: <5321FF07.10001@oracle.com> Looks OK to me -phil. On 3/10/14 2:14 PM, Joe Darcy wrote: > *ping* > > Any other comments on this changeset? > > Thanks, > > -Joe > > On 03/05/2014 01:19 PM, Alan Bateman wrote: >> On 05/03/2014 20:30, Joe Darcy wrote: >>> Hello, >>> >>> Please review this webrev which addresses serial warnings in >>> mac-specific code: >>> >>> JDK-8035692 : Fix serial lint warnings in mac-specific code >>> http://cr.openjdk.java.net/~darcy/8035692.0/ >>> >> This looks okay to me on the assumption that nothing of these types >> leak into the serialized stream when serializing a supported type >> that has serialization compatibility guarantees. >> >> Also double check LWCToolkit.java before you push as there is a >> spurious character in the webrev at L145. >> >> -Alan. > From joe.darcy at oracle.com Thu Mar 13 19:01:15 2014 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 13 Mar 2014 12:01:15 -0700 Subject: <Swing Dev> JDK 9 RFR of JDK-8034169: Fix serial lint warnings in javax.swing In-Reply-To: <5321FE62.2030808@oracle.com> References: <52FC7BA2.7010805@oracle.com> <52FD0F82.7010701@oracle.com> <53041894.9080008@oracle.com> <530515EC.5060801@oracle.com> <53054CFF.4010305@oracle.com> <531E9434.8090709@oracle.com> <5321FE62.2030808@oracle.com> Message-ID: <5322007B.309@oracle.com> Phil, Hmmm. I must have mis-generated the webrev. Let me give it another try. Sorry for the mix-up, -Joe On 3/13/2014 11:52 AM, Phil Race wrote: > Joe, > > When I open up the patch > http://cr.openjdk.java.net/~darcy/8034169.1/jdk.patch > and search I see multiple new serialVersionUIDs. > Did you miss updating these or do I misunderstand you ? > > -phil. > > > On 3/10/14 9:42 PM, Joe Darcy wrote: >> Hello, >> >> I've generated a new version of the webrev: >> >> http://cr.openjdk.java.net/~darcy/8034169.1 >> >> Compared to the earlier version, this one exclusively uses >> @SuppressWarnings("serial") rather than adding serialVersionUID >> fields and it has been updated to account for changes made in the >> client libraries since the earlier version was sent for review. >> >> Thanks, >> >> -Joe >> >> On 02/19/2014 04:31 PM, Joseph Darcy wrote: >>> On 2/19/2014 12:37 PM, Phil Race wrote: >>>> >>>> >In a small percentage of cases, a serialVersionUID field was added. >>>> > When such a field was added, the serialver computation was >>>> checked for consistency on JDK6 and JDK 8. >>>> >>>> I'm rather unsure about adding a serialVersionUID to some of these, >>>> eg RowSorterEvent. >>>> Looks like all the other javax.swing.event Event types have the >>>> usual Swing warning that :- >>>> >>>> *Warning:* Serialized objects of this class will not be compatible >>>> with future Swing releases. The current serialization support is >>>> appropriate for short term storage or RMI between applications >>>> running the same version of Swing >>>> >>>> I think where ever in Swing you did not see that warning it was >>>> probably an oversight rather >>>> than implying long-term persistence is supported >>>> >>>> In other words where ever I see the annotation added I think >>>> there's no harm. I'm more worried >>>> about where I see serialVersionUID added. >>>> >>>> So in these cases would be good to have a Swing engineer confirm >>>> that it is so, for example >>>> for the Layout classes which also have a serialVersionUID added. I >>>> don't see how these >>>> on their own are useful. >>> >>> There are about 23 cases in this patch where a serialVersionUID was >>> added in lieu of a @SuppressWarnings("serial") annotation. >>> >>> If the swing team can provide a definitive ruling, I'm happy to swap >>> these out to be annotations instead. >>> >>> Thanks, >>> >>> -Joe >>> >> > From joe.darcy at oracle.com Fri Mar 14 02:04:31 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 13 Mar 2014 19:04:31 -0700 Subject: <Swing Dev> JDK 9 RFR of JDK-8034169: Fix serial lint warnings in javax.swing In-Reply-To: <5322007B.309@oracle.com> References: <52FC7BA2.7010805@oracle.com> <52FD0F82.7010701@oracle.com> <53041894.9080008@oracle.com> <530515EC.5060801@oracle.com> <53054CFF.4010305@oracle.com> <531E9434.8090709@oracle.com> <5321FE62.2030808@oracle.com> <5322007B.309@oracle.com> Message-ID: <532263AF.8070802@oracle.com> Unfortunately, I had to regenerate the corrected form of the changes: http://cr.openjdk.java.net/~darcy/8034169.2/ http://cr.openjdk.java.net/~darcy/8034169.2/jdk.patch With this patch, javax.swing.* compiles without serial lint warnings. This should be the last large patch needed to get the build of the jdk repo completely free of serial warnings :-) Thanks, -Joe On 03/13/2014 12:01 PM, Joseph Darcy wrote: > Phil, > > Hmmm. I must have mis-generated the webrev. Let me give it another try. > > Sorry for the mix-up, > > -Joe > > On 3/13/2014 11:52 AM, Phil Race wrote: >> Joe, >> >> When I open up the patch >> http://cr.openjdk.java.net/~darcy/8034169.1/jdk.patch >> and search I see multiple new serialVersionUIDs. >> Did you miss updating these or do I misunderstand you ? >> >> -phil. >> >> >> On 3/10/14 9:42 PM, Joe Darcy wrote: >>> Hello, >>> >>> I've generated a new version of the webrev: >>> >>> http://cr.openjdk.java.net/~darcy/8034169.1 >>> >>> Compared to the earlier version, this one exclusively uses >>> @SuppressWarnings("serial") rather than adding serialVersionUID >>> fields and it has been updated to account for changes made in the >>> client libraries since the earlier version was sent for review. >>> >>> Thanks, >>> >>> -Joe >>> >>> On 02/19/2014 04:31 PM, Joseph Darcy wrote: >>>> On 2/19/2014 12:37 PM, Phil Race wrote: >>>>> >>>>> >In a small percentage of cases, a serialVersionUID field was added. >>>>> > When such a field was added, the serialver computation was >>>>> checked for consistency on JDK6 and JDK 8. >>>>> >>>>> I'm rather unsure about adding a serialVersionUID to some of >>>>> these, eg RowSorterEvent. >>>>> Looks like all the other javax.swing.event Event types have the >>>>> usual Swing warning that :- >>>>> >>>>> *Warning:* Serialized objects of this class will not be compatible >>>>> with future Swing releases. The current serialization support is >>>>> appropriate for short term storage or RMI between applications >>>>> running the same version of Swing >>>>> >>>>> I think where ever in Swing you did not see that warning it was >>>>> probably an oversight rather >>>>> than implying long-term persistence is supported >>>>> >>>>> In other words where ever I see the annotation added I think >>>>> there's no harm. I'm more worried >>>>> about where I see serialVersionUID added. >>>>> >>>>> So in these cases would be good to have a Swing engineer confirm >>>>> that it is so, for example >>>>> for the Layout classes which also have a serialVersionUID added. I >>>>> don't see how these >>>>> on their own are useful. >>>> >>>> There are about 23 cases in this patch where a serialVersionUID was >>>> added in lieu of a @SuppressWarnings("serial") annotation. >>>> >>>> If the swing team can provide a definitive ruling, I'm happy to >>>> swap these out to be annotations instead. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>> >> > From alexey.ivanov at oracle.com Fri Mar 14 11:23:41 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 14 Mar 2014 15:23:41 +0400 Subject: <Swing Dev> [9] Review Request: JDK-8032878: Editable combos in table do not behave as expected Message-ID: <5322E6BD.9080301@oracle.com> Hello, Could you please review the fix for jdk9: bug: https://bugs.openjdk.java.net/browse/JDK-8032878 webrev: http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.00/ Problem description: If editable JComboBox is used as cell editor in JTable, its value does not change when user types keys. If JTable.setSurrendersFocusOnKeystroke(true) is in effect, then JComboBox (usually) loses the first key press before it gets the input focus. Fix: If JComboBox is table cell editor and is editable, it will forward TextActions to its editor component. The action binding is obtained from InputMap of the editor component with WHEN_FOCUSED condition, as if the editor had focus. Thanks, Alexey. From alexandr.scherbatiy at oracle.com Mon Mar 17 11:48:48 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 17 Mar 2014 15:48:48 +0400 Subject: <Swing Dev> [9] Review Request: JDK-8032878: Editable combos in table do not behave as expected In-Reply-To: <5322E6BD.9080301@oracle.com> References: <5322E6BD.9080301@oracle.com> Message-ID: <5326E120.5070903@oracle.com> - It seems that the "JComboBox.isTableCellEditor" client property can have null value which should be treated as false but it does not pass the check Boolean.FALSE.equals(null). - I am not able to use arrows during JComboBox editing because it moves the focus to another component. The same is for table cells which use TextComponent. May be it have sense to create a separate issue that it should be possible to use arrows in the component during editing. Otherwise the fix looks good for me. Thanks, Alexandr. On 3/14/2014 3:23 PM, Alexey Ivanov wrote: > Hello, > > Could you please review the fix for jdk9: > bug: https://bugs.openjdk.java.net/browse/JDK-8032878 > webrev: http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.00/ > > Problem description: > If editable JComboBox is used as cell editor in JTable, its value does > not change when user types keys. > > If JTable.setSurrendersFocusOnKeystroke(true) is in effect, then > JComboBox (usually) loses the first key press before it gets the input > focus. > > > Fix: > If JComboBox is table cell editor and is editable, it will forward > TextActions to its editor component. The action binding is obtained > from InputMap of the editor component with WHEN_FOCUSED condition, as > if the editor had focus. > > > Thanks, > Alexey. From alexey.ivanov at oracle.com Mon Mar 17 13:32:00 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 17 Mar 2014 17:32:00 +0400 Subject: <Swing Dev> [9] Review Request: JDK-8032878: Editable combos in table do not behave as expected In-Reply-To: <5326E120.5070903@oracle.com> References: <5322E6BD.9080301@oracle.com> <5326E120.5070903@oracle.com> Message-ID: <5326F950.7020303@oracle.com> Hi Alexandr, I've corrected the condition, please find the updated webrev at http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.01/ <http://cr.openjdk.java.net/%7Edmarkov/8032878/jdk9/webrev.01/> - You're right! The correct condition must have been !Boolean.TRUE.equals(getClientProperty("JComboBox.isTableCellEditor")) - It's expected. JTable has two cell editing modes: * if surrendersFocusOnKeystroke is false (the default), then the table owns the input focus, and "forwards" keys to the editor. Arrow keys will move selection to another cell in this case. * if surrendersFocusOnKeystroke is true, the cell editor will be the focus owner and therefore arrow keys could be used for moving cursor inside the edited text as well as selecting text. So to fix the issue with arrow keys, the default value of JTable.surrendersFocusOnKeystroke has to be changed to true. It may break some applications. As far as I understand, the current behavior is similar to spreadsheet applications where arrow keys move selection to another cell unless you press F2 or double-click to start cell editing. I think it's safer to preserve the current behavior with regards to arrow keys. What do you think? Thanks, Alexey. On 17.03.2014 15:48, Alexander Scherbatiy wrote: > > > - It seems that the "JComboBox.isTableCellEditor" client property > can have null value which should be treated as false > but it does not pass the check Boolean.FALSE.equals(null). > - I am not able to use arrows during JComboBox editing because it > moves the focus to another component. > The same is for table cells which use TextComponent. May be it have > sense to create a separate issue that it should be > possible to use arrows in the component during editing. > > Otherwise the fix looks good for me. > > Thanks, > Alexandr. > > > On 3/14/2014 3:23 PM, Alexey Ivanov wrote: >> Hello, >> >> Could you please review the fix for jdk9: >> bug: https://bugs.openjdk.java.net/browse/JDK-8032878 >> webrev: http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.00/ >> >> Problem description: >> If editable JComboBox is used as cell editor in JTable, its value >> does not change when user types keys. >> >> If JTable.setSurrendersFocusOnKeystroke(true) is in effect, then >> JComboBox (usually) loses the first key press before it gets the >> input focus. >> >> >> Fix: >> If JComboBox is table cell editor and is editable, it will forward >> TextActions to its editor component. The action binding is obtained >> from InputMap of the editor component with WHEN_FOCUSED condition, as >> if the editor had focus. >> >> >> Thanks, >> Alexey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20140317/501fd6fe/attachment.html> From alexandr.scherbatiy at oracle.com Mon Mar 17 14:12:27 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 17 Mar 2014 18:12:27 +0400 Subject: <Swing Dev> [9] Review Request: JDK-8032878: Editable combos in table do not behave as expected In-Reply-To: <5326F950.7020303@oracle.com> References: <5322E6BD.9080301@oracle.com> <5326E120.5070903@oracle.com> <5326F950.7020303@oracle.com> Message-ID: <532702CB.1090204@oracle.com> The fix looks good for me. On 3/17/2014 5:32 PM, Alexey Ivanov wrote: > Hi Alexandr, > > I've corrected the condition, please find the updated webrev at > http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.01/ > <http://cr.openjdk.java.net/%7Edmarkov/8032878/jdk9/webrev.01/> > > > - You're right! The correct condition must have been > !Boolean.TRUE.equals(getClientProperty("JComboBox.isTableCellEditor")) > > - It's expected. JTable has two cell editing modes: > * if surrendersFocusOnKeystroke is false (the default), then the table > owns the input focus, and "forwards" keys to the editor. Arrow keys > will move selection to another cell in this case. > * if surrendersFocusOnKeystroke is true, the cell editor will be the > focus owner and therefore arrow keys could be used for moving > cursor inside the edited text as well as selecting text. > > So to fix the issue with arrow keys, the default value of > JTable.surrendersFocusOnKeystroke has to be changed to true. It may > break some applications. > As far as I understand, the current behavior is similar to spreadsheet > applications where arrow keys move selection to another cell unless > you press F2 or double-click to start cell editing. > > I think it's safer to preserve the current behavior with regards to > arrow keys. What do you think? > I see. Yes, it is better to leave it as is. Thanks, Alexandr. > > Thanks, > Alexey. > > On 17.03.2014 15:48, Alexander Scherbatiy wrote: >> >> >> - It seems that the "JComboBox.isTableCellEditor" client property >> can have null value which should be treated as false >> but it does not pass the check Boolean.FALSE.equals(null). >> - I am not able to use arrows during JComboBox editing because it >> moves the focus to another component. >> The same is for table cells which use TextComponent. May be it >> have sense to create a separate issue that it should be >> possible to use arrows in the component during editing. >> >> Otherwise the fix looks good for me. >> >> Thanks, >> Alexandr. >> >> >> On 3/14/2014 3:23 PM, Alexey Ivanov wrote: >>> Hello, >>> >>> Could you please review the fix for jdk9: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8032878 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.00/ >>> >>> Problem description: >>> If editable JComboBox is used as cell editor in JTable, its value >>> does not change when user types keys. >>> >>> If JTable.setSurrendersFocusOnKeystroke(true) is in effect, then >>> JComboBox (usually) loses the first key press before it gets the >>> input focus. >>> >>> >>> Fix: >>> If JComboBox is table cell editor and is editable, it will forward >>> TextActions to its editor component. The action binding is obtained >>> from InputMap of the editor component with WHEN_FOCUSED condition, >>> as if the editor had focus. >>> >>> >>> Thanks, >>> Alexey. >> > From alexey.ivanov at oracle.com Thu Mar 20 06:18:40 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 20 Mar 2014 10:18:40 +0400 Subject: <Swing Dev> [9] Review Request: JDK-8032878: Editable combos in table do not behave as expected In-Reply-To: <532702CB.1090204@oracle.com> References: <5322E6BD.9080301@oracle.com> <5326E120.5070903@oracle.com> <5326F950.7020303@oracle.com> <532702CB.1090204@oracle.com> Message-ID: <532A8840.9030201@oracle.com> Reminder. Could you please review the fix for jdk9: bug: https://bugs.openjdk.java.net/browse/JDK-8032878 webrev: http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.01/ Thank you, Alexey. On 17.03.2014 18:12, Alexander Scherbatiy wrote: > > The fix looks good for me. > > On 3/17/2014 5:32 PM, Alexey Ivanov wrote: >> Hi Alexandr, >> >> I've corrected the condition, please find the updated webrev at >> http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.01/ >> <http://cr.openjdk.java.net/%7Edmarkov/8032878/jdk9/webrev.01/> >> >> >> - You're right! The correct condition must have been >> !Boolean.TRUE.equals(getClientProperty("JComboBox.isTableCellEditor")) >> >> - It's expected. JTable has two cell editing modes: >> * if surrendersFocusOnKeystroke is false (the default), then the table >> owns the input focus, and "forwards" keys to the editor. Arrow keys >> will move selection to another cell in this case. >> * if surrendersFocusOnKeystroke is true, the cell editor will be the >> focus owner and therefore arrow keys could be used for moving >> cursor inside the edited text as well as selecting text. >> >> So to fix the issue with arrow keys, the default value of >> JTable.surrendersFocusOnKeystroke has to be changed to true. It may >> break some applications. >> As far as I understand, the current behavior is similar to >> spreadsheet applications where arrow keys move selection to another >> cell unless you press F2 or double-click to start cell editing. >> >> I think it's safer to preserve the current behavior with regards to >> arrow keys. What do you think? >> > I see. Yes, it is better to leave it as is. > > Thanks, > Alexandr. > >> >> Thanks, >> Alexey. >> >> On 17.03.2014 15:48, Alexander Scherbatiy wrote: >>> >>> >>> - It seems that the "JComboBox.isTableCellEditor" client property >>> can have null value which should be treated as false >>> but it does not pass the check Boolean.FALSE.equals(null). >>> - I am not able to use arrows during JComboBox editing because it >>> moves the focus to another component. >>> The same is for table cells which use TextComponent. May be it >>> have sense to create a separate issue that it should be >>> possible to use arrows in the component during editing. >>> >>> Otherwise the fix looks good for me. >>> >>> Thanks, >>> Alexandr. >>> >>> >>> On 3/14/2014 3:23 PM, Alexey Ivanov wrote: >>>> Hello, >>>> >>>> Could you please review the fix for jdk9: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032878 >>>> webrev: http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.00/ >>>> >>>> Problem description: >>>> If editable JComboBox is used as cell editor in JTable, its value >>>> does not change when user types keys. >>>> >>>> If JTable.setSurrendersFocusOnKeystroke(true) is in effect, then >>>> JComboBox (usually) loses the first key press before it gets the >>>> input focus. >>>> >>>> >>>> Fix: >>>> If JComboBox is table cell editor and is editable, it will forward >>>> TextActions to its editor component. The action binding is obtained >>>> from InputMap of the editor component with WHEN_FOCUSED condition, >>>> as if the editor had focus. >>>> >>>> >>>> Thanks, >>>> Alexey. >>> >> > From alexander.potochkin at oracle.com Thu Mar 20 10:43:20 2014 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Thu, 20 Mar 2014 14:43:20 +0400 Subject: <Swing Dev> [9] Review Request: JDK-8032878: Editable combos in table do not behave as expected In-Reply-To: <532A8840.9030201@oracle.com> References: <5322E6BD.9080301@oracle.com> <5326E120.5070903@oracle.com> <5326F950.7020303@oracle.com> <532702CB.1090204@oracle.com> <532A8840.9030201@oracle.com> Message-ID: <532AC648.7050506@oracle.com> Hello Alexey Please add /** * {@inheritDoc} */ to the overridden protected method. Could you also try to callprocessKeyBinding on the editor component to avoid copy/paste the action processing code Thanks alexp On 3/20/2014 10:18 AM, Alexey Ivanov wrote: > Reminder. > > Could you please review the fix for jdk9: > bug: https://bugs.openjdk.java.net/browse/JDK-8032878 > webrev: http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.01/ > > > Thank you, > Alexey. > > > On 17.03.2014 18:12, Alexander Scherbatiy wrote: >> >> The fix looks good for me. >> >> On 3/17/2014 5:32 PM, Alexey Ivanov wrote: >>> Hi Alexandr, >>> >>> I've corrected the condition, please find the updated webrev at >>> http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.01/ >>> <http://cr.openjdk.java.net/%7Edmarkov/8032878/jdk9/webrev.01/> >>> >>> >>> - You're right! The correct condition must have been >>> !Boolean.TRUE.equals(getClientProperty("JComboBox.isTableCellEditor")) >>> >>> - It's expected. JTable has two cell editing modes: >>> * if surrendersFocusOnKeystroke is false (the default), then the >>> table >>> owns the input focus, and "forwards" keys to the editor. Arrow keys >>> will move selection to another cell in this case. >>> * if surrendersFocusOnKeystroke is true, the cell editor will be the >>> focus owner and therefore arrow keys could be used for moving >>> cursor inside the edited text as well as selecting text. >>> >>> So to fix the issue with arrow keys, the default value of >>> JTable.surrendersFocusOnKeystroke has to be changed to true. It may >>> break some applications. >>> As far as I understand, the current behavior is similar to >>> spreadsheet applications where arrow keys move selection to another >>> cell unless you press F2 or double-click to start cell editing. >>> >>> I think it's safer to preserve the current behavior with regards to >>> arrow keys. What do you think? >>> >> I see. Yes, it is better to leave it as is. >> >> Thanks, >> Alexandr. >> >>> >>> Thanks, >>> Alexey. >>> >>> On 17.03.2014 15:48, Alexander Scherbatiy wrote: >>>> >>>> >>>> - It seems that the "JComboBox.isTableCellEditor" client property >>>> can have null value which should be treated as false >>>> but it does not pass the check Boolean.FALSE.equals(null). >>>> - I am not able to use arrows during JComboBox editing because it >>>> moves the focus to another component. >>>> The same is for table cells which use TextComponent. May be it >>>> have sense to create a separate issue that it should be >>>> possible to use arrows in the component during editing. >>>> >>>> Otherwise the fix looks good for me. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> On 3/14/2014 3:23 PM, Alexey Ivanov wrote: >>>>> Hello, >>>>> >>>>> Could you please review the fix for jdk9: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032878 >>>>> webrev: http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.00/ >>>>> >>>>> Problem description: >>>>> If editable JComboBox is used as cell editor in JTable, its value >>>>> does not change when user types keys. >>>>> >>>>> If JTable.setSurrendersFocusOnKeystroke(true) is in effect, then >>>>> JComboBox (usually) loses the first key press before it gets the >>>>> input focus. >>>>> >>>>> >>>>> Fix: >>>>> If JComboBox is table cell editor and is editable, it will forward >>>>> TextActions to its editor component. The action binding is >>>>> obtained from InputMap of the editor component with WHEN_FOCUSED >>>>> condition, as if the editor had focus. >>>>> >>>>> >>>>> Thanks, >>>>> Alexey. >>>> >>> >> > From alexey.ivanov at oracle.com Thu Mar 20 12:58:07 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 20 Mar 2014 16:58:07 +0400 Subject: <Swing Dev> [9] Review Request: JDK-8032878: Editable combos in table do not behave as expected In-Reply-To: <532AC648.7050506@oracle.com> References: <5322E6BD.9080301@oracle.com> <5326E120.5070903@oracle.com> <5326F950.7020303@oracle.com> <532702CB.1090204@oracle.com> <532A8840.9030201@oracle.com> <532AC648.7050506@oracle.com> Message-ID: <532AE5DF.7020706@oracle.com> Hello Alex, all, Please find the updated webrev: http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.02/ I added @inheritDoc tag to the overridden method javadoc and replaced the code inside 'if' with the call to component.processKeyBinding. It works this way too, and code duplication is eliminated. Thank you for your suggestion, Alex: The code is cleaner. Regards, Alexey. On 20.03.2014 14:43, Alexander Potochkin wrote: > Hello Alexey > > Please add > /** > * {@inheritDoc} > */ > to the overridden protected method. > > Could you also try to callprocessKeyBinding on the editor component > to avoid copy/paste the action processing code > > Thanks > alexp > > On 3/20/2014 10:18 AM, Alexey Ivanov wrote: >> Reminder. >> >> Could you please review the fix for jdk9: >> bug: https://bugs.openjdk.java.net/browse/JDK-8032878 >> webrev: http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.01/ >> >> >> Thank you, >> Alexey. >> >> >> On 17.03.2014 18:12, Alexander Scherbatiy wrote: >>> >>> The fix looks good for me. >>> >>> On 3/17/2014 5:32 PM, Alexey Ivanov wrote: >>>> Hi Alexandr, >>>> >>>> I've corrected the condition, please find the updated webrev at >>>> http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.01/ >>>> <http://cr.openjdk.java.net/%7Edmarkov/8032878/jdk9/webrev.01/> >>>> >>>> >>>> - You're right! The correct condition must have been >>>> !Boolean.TRUE.equals(getClientProperty("JComboBox.isTableCellEditor")) >>>> >>>> - It's expected. JTable has two cell editing modes: >>>> * if surrendersFocusOnKeystroke is false (the default), then the >>>> table >>>> owns the input focus, and "forwards" keys to the editor. Arrow >>>> keys >>>> will move selection to another cell in this case. >>>> * if surrendersFocusOnKeystroke is true, the cell editor will be the >>>> focus owner and therefore arrow keys could be used for moving >>>> cursor inside the edited text as well as selecting text. >>>> >>>> So to fix the issue with arrow keys, the default value of >>>> JTable.surrendersFocusOnKeystroke has to be changed to true. It may >>>> break some applications. >>>> As far as I understand, the current behavior is similar to >>>> spreadsheet applications where arrow keys move selection to another >>>> cell unless you press F2 or double-click to start cell editing. >>>> >>>> I think it's safer to preserve the current behavior with regards to >>>> arrow keys. What do you think? >>>> >>> I see. Yes, it is better to leave it as is. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> Thanks, >>>> Alexey. >>>> >>>> On 17.03.2014 15:48, Alexander Scherbatiy wrote: >>>>> >>>>> >>>>> - It seems that the "JComboBox.isTableCellEditor" client >>>>> property can have null value which should be treated as false >>>>> but it does not pass the check Boolean.FALSE.equals(null). >>>>> - I am not able to use arrows during JComboBox editing because >>>>> it moves the focus to another component. >>>>> The same is for table cells which use TextComponent. May be it >>>>> have sense to create a separate issue that it should be >>>>> possible to use arrows in the component during editing. >>>>> >>>>> Otherwise the fix looks good for me. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>> On 3/14/2014 3:23 PM, Alexey Ivanov wrote: >>>>>> Hello, >>>>>> >>>>>> Could you please review the fix for jdk9: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032878 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.00/ >>>>>> >>>>>> Problem description: >>>>>> If editable JComboBox is used as cell editor in JTable, its value >>>>>> does not change when user types keys. >>>>>> >>>>>> If JTable.setSurrendersFocusOnKeystroke(true) is in effect, then >>>>>> JComboBox (usually) loses the first key press before it gets the >>>>>> input focus. >>>>>> >>>>>> >>>>>> Fix: >>>>>> If JComboBox is table cell editor and is editable, it will >>>>>> forward TextActions to its editor component. The action binding >>>>>> is obtained from InputMap of the editor component with >>>>>> WHEN_FOCUSED condition, as if the editor had focus. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Alexey. >>>>> >>>> >>> >> > From alexander.potochkin at oracle.com Fri Mar 21 10:45:13 2014 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Fri, 21 Mar 2014 14:45:13 +0400 Subject: <Swing Dev> [9] Review Request: JDK-8032878: Editable combos in table do not behave as expected In-Reply-To: <532AE5DF.7020706@oracle.com> References: <5322E6BD.9080301@oracle.com> <5326E120.5070903@oracle.com> <5326F950.7020303@oracle.com> <532702CB.1090204@oracle.com> <532A8840.9030201@oracle.com> <532AC648.7050506@oracle.com> <532AE5DF.7020706@oracle.com> Message-ID: <532C1839.7020700@oracle.com> Hello Alexey Looks good now! Thanks much alexp On 3/20/2014 4:58 PM, Alexey Ivanov wrote: > Hello Alex, all, > > Please find the updated webrev: > http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.02/ > > I added @inheritDoc tag to the overridden method javadoc and replaced > the code inside 'if' with the call to component.processKeyBinding. It > works this way too, and code duplication is eliminated. > > Thank you for your suggestion, Alex: The code is cleaner. > > > Regards, > Alexey. > > On 20.03.2014 14:43, Alexander Potochkin wrote: >> Hello Alexey >> >> Please add >> /** >> * {@inheritDoc} >> */ >> to the overridden protected method. >> >> Could you also try to callprocessKeyBinding on the editor component >> to avoid copy/paste the action processing code >> >> Thanks >> alexp >> >> On 3/20/2014 10:18 AM, Alexey Ivanov wrote: >>> Reminder. >>> >>> Could you please review the fix for jdk9: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8032878 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.01/ >>> >>> >>> Thank you, >>> Alexey. >>> >>> >>> On 17.03.2014 18:12, Alexander Scherbatiy wrote: >>>> >>>> The fix looks good for me. >>>> >>>> On 3/17/2014 5:32 PM, Alexey Ivanov wrote: >>>>> Hi Alexandr, >>>>> >>>>> I've corrected the condition, please find the updated webrev at >>>>> http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.01/ >>>>> <http://cr.openjdk.java.net/%7Edmarkov/8032878/jdk9/webrev.01/> >>>>> >>>>> >>>>> - You're right! The correct condition must have been >>>>> !Boolean.TRUE.equals(getClientProperty("JComboBox.isTableCellEditor")) >>>>> >>>>> >>>>> - It's expected. JTable has two cell editing modes: >>>>> * if surrendersFocusOnKeystroke is false (the default), then the >>>>> table >>>>> owns the input focus, and "forwards" keys to the editor. Arrow >>>>> keys >>>>> will move selection to another cell in this case. >>>>> * if surrendersFocusOnKeystroke is true, the cell editor will be >>>>> the >>>>> focus owner and therefore arrow keys could be used for moving >>>>> cursor inside the edited text as well as selecting text. >>>>> >>>>> So to fix the issue with arrow keys, the default value of >>>>> JTable.surrendersFocusOnKeystroke has to be changed to true. It >>>>> may break some applications. >>>>> As far as I understand, the current behavior is similar to >>>>> spreadsheet applications where arrow keys move selection to >>>>> another cell unless you press F2 or double-click to start cell >>>>> editing. >>>>> >>>>> I think it's safer to preserve the current behavior with regards >>>>> to arrow keys. What do you think? >>>>> >>>> I see. Yes, it is better to leave it as is. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> Thanks, >>>>> Alexey. >>>>> >>>>> On 17.03.2014 15:48, Alexander Scherbatiy wrote: >>>>>> >>>>>> >>>>>> - It seems that the "JComboBox.isTableCellEditor" client >>>>>> property can have null value which should be treated as false >>>>>> but it does not pass the check Boolean.FALSE.equals(null). >>>>>> - I am not able to use arrows during JComboBox editing because >>>>>> it moves the focus to another component. >>>>>> The same is for table cells which use TextComponent. May be it >>>>>> have sense to create a separate issue that it should be >>>>>> possible to use arrows in the component during editing. >>>>>> >>>>>> Otherwise the fix looks good for me. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>>> On 3/14/2014 3:23 PM, Alexey Ivanov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you please review the fix for jdk9: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032878 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.00/ >>>>>>> >>>>>>> Problem description: >>>>>>> If editable JComboBox is used as cell editor in JTable, its >>>>>>> value does not change when user types keys. >>>>>>> >>>>>>> If JTable.setSurrendersFocusOnKeystroke(true) is in effect, then >>>>>>> JComboBox (usually) loses the first key press before it gets the >>>>>>> input focus. >>>>>>> >>>>>>> >>>>>>> Fix: >>>>>>> If JComboBox is table cell editor and is editable, it will >>>>>>> forward TextActions to its editor component. The action binding >>>>>>> is obtained from InputMap of the editor component with >>>>>>> WHEN_FOCUSED condition, as if the editor had focus. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Alexey. >>>>>> >>>>> >>>> >>> >> > From alexandr.scherbatiy at oracle.com Fri Mar 21 10:55:59 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 21 Mar 2014 14:55:59 +0400 Subject: <Swing Dev> [9] Review Request: JDK-8032878: Editable combos in table do not behave as expected In-Reply-To: <532AE5DF.7020706@oracle.com> References: <5322E6BD.9080301@oracle.com> <5326E120.5070903@oracle.com> <5326F950.7020303@oracle.com> <532702CB.1090204@oracle.com> <532A8840.9030201@oracle.com> <532AC648.7050506@oracle.com> <532AE5DF.7020706@oracle.com> Message-ID: <532C1ABF.2010102@oracle.com> The fix looks good. Thanks, Alexandr. On 3/20/2014 4:58 PM, Alexey Ivanov wrote: > Hello Alex, all, > > Please find the updated webrev: > http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.02/ > > I added @inheritDoc tag to the overridden method javadoc and replaced > the code inside 'if' with the call to component.processKeyBinding. It > works this way too, and code duplication is eliminated. > > Thank you for your suggestion, Alex: The code is cleaner. > > > Regards, > Alexey. > > On 20.03.2014 14:43, Alexander Potochkin wrote: >> Hello Alexey >> >> Please add >> /** >> * {@inheritDoc} >> */ >> to the overridden protected method. >> >> Could you also try to callprocessKeyBinding on the editor component >> to avoid copy/paste the action processing code >> >> Thanks >> alexp >> >> On 3/20/2014 10:18 AM, Alexey Ivanov wrote: >>> Reminder. >>> >>> Could you please review the fix for jdk9: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8032878 >>> webrev: http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.01/ >>> >>> >>> Thank you, >>> Alexey. >>> >>> >>> On 17.03.2014 18:12, Alexander Scherbatiy wrote: >>>> >>>> The fix looks good for me. >>>> >>>> On 3/17/2014 5:32 PM, Alexey Ivanov wrote: >>>>> Hi Alexandr, >>>>> >>>>> I've corrected the condition, please find the updated webrev at >>>>> http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.01/ >>>>> <http://cr.openjdk.java.net/%7Edmarkov/8032878/jdk9/webrev.01/> >>>>> >>>>> >>>>> - You're right! The correct condition must have been >>>>> !Boolean.TRUE.equals(getClientProperty("JComboBox.isTableCellEditor")) >>>>> >>>>> >>>>> - It's expected. JTable has two cell editing modes: >>>>> * if surrendersFocusOnKeystroke is false (the default), then the >>>>> table >>>>> owns the input focus, and "forwards" keys to the editor. Arrow >>>>> keys >>>>> will move selection to another cell in this case. >>>>> * if surrendersFocusOnKeystroke is true, the cell editor will be >>>>> the >>>>> focus owner and therefore arrow keys could be used for moving >>>>> cursor inside the edited text as well as selecting text. >>>>> >>>>> So to fix the issue with arrow keys, the default value of >>>>> JTable.surrendersFocusOnKeystroke has to be changed to true. It >>>>> may break some applications. >>>>> As far as I understand, the current behavior is similar to >>>>> spreadsheet applications where arrow keys move selection to >>>>> another cell unless you press F2 or double-click to start cell >>>>> editing. >>>>> >>>>> I think it's safer to preserve the current behavior with regards >>>>> to arrow keys. What do you think? >>>>> >>>> I see. Yes, it is better to leave it as is. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>> >>>>> Thanks, >>>>> Alexey. >>>>> >>>>> On 17.03.2014 15:48, Alexander Scherbatiy wrote: >>>>>> >>>>>> >>>>>> - It seems that the "JComboBox.isTableCellEditor" client >>>>>> property can have null value which should be treated as false >>>>>> but it does not pass the check Boolean.FALSE.equals(null). >>>>>> - I am not able to use arrows during JComboBox editing because >>>>>> it moves the focus to another component. >>>>>> The same is for table cells which use TextComponent. May be it >>>>>> have sense to create a separate issue that it should be >>>>>> possible to use arrows in the component during editing. >>>>>> >>>>>> Otherwise the fix looks good for me. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>>> On 3/14/2014 3:23 PM, Alexey Ivanov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you please review the fix for jdk9: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032878 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~dmarkov/8032878/jdk9/webrev.00/ >>>>>>> >>>>>>> Problem description: >>>>>>> If editable JComboBox is used as cell editor in JTable, its >>>>>>> value does not change when user types keys. >>>>>>> >>>>>>> If JTable.setSurrendersFocusOnKeystroke(true) is in effect, then >>>>>>> JComboBox (usually) loses the first key press before it gets the >>>>>>> input focus. >>>>>>> >>>>>>> >>>>>>> Fix: >>>>>>> If JComboBox is table cell editor and is editable, it will >>>>>>> forward TextActions to its editor component. The action binding >>>>>>> is obtained from InputMap of the editor component with >>>>>>> WHEN_FOCUSED condition, as if the editor had focus. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Alexey. >>>>>> >>>>> >>>> >>> >> > From philip.race at oracle.com Fri Mar 21 15:41:23 2014 From: philip.race at oracle.com (Phil Race) Date: Fri, 21 Mar 2014 08:41:23 -0700 Subject: <Swing Dev> JDK 9 RFR of JDK-8034169: Fix serial lint warnings in javax.swing In-Reply-To: <532263AF.8070802@oracle.com> References: <52FC7BA2.7010805@oracle.com> <52FD0F82.7010701@oracle.com> <53041894.9080008@oracle.com> <530515EC.5060801@oracle.com> <53054CFF.4010305@oracle.com> <531E9434.8090709@oracle.com> <5321FE62.2030808@oracle.com> <5322007B.309@oracle.com> <532263AF.8070802@oracle.com> Message-ID: <532C5DA3.2040704@oracle.com> One more was still missed class CenterLayout implements LayoutManager, Serializable { + private static final long serialVersionUID = 6948189423011048265L; + Just fix that one and you are good to go. -phil. On 3/13/14 7:04 PM, Joe Darcy wrote: > Unfortunately, I had to regenerate the corrected form of the changes: > > http://cr.openjdk.java.net/~darcy/8034169.2/ > http://cr.openjdk.java.net/~darcy/8034169.2/jdk.patch > > With this patch, javax.swing.* compiles without serial lint warnings. > This should be the last large patch needed to get the build of the jdk > repo completely free of serial warnings :-) > > Thanks, > > -Joe > > On 03/13/2014 12:01 PM, Joseph Darcy wrote: >> Phil, >> >> Hmmm. I must have mis-generated the webrev. Let me give it another try. >> >> Sorry for the mix-up, >> >> -Joe >> >> On 3/13/2014 11:52 AM, Phil Race wrote: >>> Joe, >>> >>> When I open up the patch >>> http://cr.openjdk.java.net/~darcy/8034169.1/jdk.patch >>> and search I see multiple new serialVersionUIDs. >>> Did you miss updating these or do I misunderstand you ? >>> >>> -phil. >>> >>> >>> On 3/10/14 9:42 PM, Joe Darcy wrote: >>>> Hello, >>>> >>>> I've generated a new version of the webrev: >>>> >>>> http://cr.openjdk.java.net/~darcy/8034169.1 >>>> >>>> Compared to the earlier version, this one exclusively uses >>>> @SuppressWarnings("serial") rather than adding serialVersionUID >>>> fields and it has been updated to account for changes made in the >>>> client libraries since the earlier version was sent for review. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> On 02/19/2014 04:31 PM, Joseph Darcy wrote: >>>>> On 2/19/2014 12:37 PM, Phil Race wrote: >>>>>> >>>>>> >In a small percentage of cases, a serialVersionUID field was added. >>>>>> > When such a field was added, the serialver computation was >>>>>> checked for consistency on JDK6 and JDK 8. >>>>>> >>>>>> I'm rather unsure about adding a serialVersionUID to some of >>>>>> these, eg RowSorterEvent. >>>>>> Looks like all the other javax.swing.event Event types have the >>>>>> usual Swing warning that :- >>>>>> >>>>>> *Warning:* Serialized objects of this class will not be >>>>>> compatible with future Swing releases. The current serialization >>>>>> support is appropriate for short term storage or RMI between >>>>>> applications running the same version of Swing >>>>>> >>>>>> I think where ever in Swing you did not see that warning it was >>>>>> probably an oversight rather >>>>>> than implying long-term persistence is supported >>>>>> >>>>>> In other words where ever I see the annotation added I think >>>>>> there's no harm. I'm more worried >>>>>> about where I see serialVersionUID added. >>>>>> >>>>>> So in these cases would be good to have a Swing engineer confirm >>>>>> that it is so, for example >>>>>> for the Layout classes which also have a serialVersionUID added. >>>>>> I don't see how these >>>>>> on their own are useful. >>>>> >>>>> There are about 23 cases in this patch where a serialVersionUID >>>>> was added in lieu of a @SuppressWarnings("serial") annotation. >>>>> >>>>> If the swing team can provide a definitive ruling, I'm happy to >>>>> swap these out to be annotations instead. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>> >>> >> > From sergey.malenkov at oracle.com Tue Mar 25 16:31:54 2014 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Tue, 25 Mar 2014 20:31:54 +0400 Subject: <Swing Dev> [9] RFR 4763438: Replace uses of @beaninfo with meta facility in core j2se Message-ID: <5331AF7A.4090501@oracle.com> Hello, Could you please review the following fix: fix: http://cr.openjdk.java.net/~malenkov/4763438.9.0/ bug: http://bugs.openjdk.java.net/browse/JDK-4763438 This is the first step of replacing @beaninfo support with annotations. We should implement this functionality before the following issue: http://bugs.openjdk.java.net/browse/JDK-7179078 which is needed for Java modularization. Could you please to review this code? Note, that the javadoc for new annotations is not ready yet. I'll submit a CCC request when it is ready. Thanks, SAM From Sergey.Bylokhov at oracle.com Sun Mar 30 22:13:11 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 31 Mar 2014 02:13:11 +0400 Subject: <Swing Dev> [9] Review Request: 8038657 javax.swing.BufferStrategyPaintManager has unused imports Message-ID: <533896F7.4020108@oracle.com> Hello. Please review a small fix for jdk 9. Bug: https://bugs.openjdk.java.net/browse/JDK-8038657 Webrev can be found at: http://cr.openjdk.java.net/~serb/8038657/webrev.00 -- Best regards, Sergey. From petr.pchelko at oracle.com Mon Mar 31 06:21:16 2014 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Mon, 31 Mar 2014 10:21:16 +0400 Subject: <Swing Dev> [9] Review Request: 8038657 javax.swing.BufferStrategyPaintManager has unused imports In-Reply-To: <533896F7.4020108@oracle.com> References: <533896F7.4020108@oracle.com> Message-ID: <8D88B6B3-93CB-44F0-A799-652A565D3C6D@oracle.com> Hello, Sergey. Looks good to me. With best regards. Petr. With best regards. Petr. On 31.03.2014, at 2:13, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote: > Hello. > Please review a small fix for jdk 9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8038657 > Webrev can be found at: http://cr.openjdk.java.net/~serb/8038657/webrev.00 > > -- > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20140331/defe397a/attachment.html> From sergey.malenkov at oracle.com Mon Mar 31 12:25:16 2014 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Mon, 31 Mar 2014 16:25:16 +0400 Subject: <Swing Dev> Approved: [9] Review Request: 8038657 javax.swing.BufferStrategyPaintManager has unused imports In-Reply-To: <533896F7.4020108@oracle.com> References: <533896F7.4020108@oracle.com> Message-ID: <53395EAC.40607@oracle.com> The fix looks good to me. Thanks, SAM On 31.03.2014 2:13, Sergey Bylokhov wrote: > Hello. > Please review a small fix for jdk 9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8038657 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8038657/webrev.00 > From damage3025 at gmail.com Thu Mar 6 13:41:41 2014 From: damage3025 at gmail.com (Ma Xiaojun) Date: Thu, 06 Mar 2014 13:41:41 -0000 Subject: <Swing Dev> Support Ubuntu global menu in Ubuntu? Message-ID: <CAGVx7UWeE5OHNO=ZckJ1m3Kmx8LRgtdgTf89AeJ_CP-C3O7pDg@mail.gmail.com> http://www.webupd8.org/2014/02/get-unity-global-menu-hud-support-for.html I wonder how this kind of fundamental thing is handled by third-party...