From alexandr.scherbatiy at oracle.com Mon Dec 1 14:17:09 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 01 Dec 2014 17:17:09 +0300 Subject: [9] Review request for 8066142 closed/javax/swing/JComboBox/4212498/bug4212498.java:Edit the value in the text field and then press the tab key, the number don't increase Message-ID: <547C7865.8010203@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8066142 webrev: http://cr.openjdk.java.net/~alexsch/8066142/webrev.00 This is a regression from the fix 8057893. The BasicComboBoxUI.focusLost() uses combobox editor as the ActionEvent sources. The JTextField uses the combobox editor componenr as the ActionEvent sources. It seems both JComboBox editor and editor component can be used as an ActionEvent source. The fix compares the event source with both combobox editor and combobox editor component. Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Mon Dec 1 16:45:52 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 01 Dec 2014 19:45:52 +0300 Subject: [9] Review request for 8066142 closed/javax/swing/JComboBox/4212498/bug4212498.java:Edit the value in the text field and then press the tab key, the number don't increase In-Reply-To: <547C7865.8010203@oracle.com> References: <547C7865.8010203@oracle.com> Message-ID: <547C9B40.1040007@oracle.com> Hi, Alexander. The fix looks fine. I assume that tests from 8057893 and 8019180 are passed. On 01.12.2014 17:17, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8066142 > webrev: http://cr.openjdk.java.net/~alexsch/8066142/webrev.00 > > This is a regression from the fix 8057893. > The BasicComboBoxUI.focusLost() uses combobox editor as the > ActionEvent sources. > The JTextField uses the combobox editor componenr as the ActionEvent > sources. > > It seems both JComboBox editor and editor component can be used as > an ActionEvent source. > > The fix compares the event source with both combobox editor and > combobox editor component. > > Thanks, > Alexandr. > -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Wed Dec 3 10:06:25 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 03 Dec 2014 13:06:25 +0300 Subject: [9] Review request for 8066142 closed/javax/swing/JComboBox/4212498/bug4212498.java:Edit the value in the text field and then press the tab key, the number don't increase In-Reply-To: <547C7865.8010203@oracle.com> References: <547C7865.8010203@oracle.com> Message-ID: <547EE0A1.5020000@oracle.com> Hello Alexandr, the fix looks good to me. Thanks, Alexander. On 12/01/2014 05:17 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8066142 > webrev: http://cr.openjdk.java.net/~alexsch/8066142/webrev.00 > > This is a regression from the fix 8057893. > The BasicComboBoxUI.focusLost() uses combobox editor as the > ActionEvent sources. > The JTextField uses the combobox editor componenr as the ActionEvent > sources. > > It seems both JComboBox editor and editor component can be used as > an ActionEvent source. > > The fix compares the event source with both combobox editor and > combobox editor component. > > Thanks, > Alexandr. > From Sergey.Bylokhov at oracle.com Wed Dec 3 13:30:21 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 03 Dec 2014 16:30:21 +0300 Subject: Review request: JDK-8055723 Replace concat String to append in StringBuilder parameters In-Reply-To: References: Message-ID: <547F106D.5000107@oracle.com> Hello, The changes in java.desktop looks good. On 18.11.2014 11:58, Ot?vio Gon?alves de Santana wrote: > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055723 > WEBREV: http://cr.openjdk.java.net/~weijun/8055723/webrev.01/ > > > -- > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: _http://about.me/otaviojava_ > 55 (11) 98255-3513 -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Dec 3 14:40:52 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 3 Dec 2014 22:40:52 +0800 Subject: Review request: JDK-8055723 Replace concat String to append in StringBuilder parameters In-Reply-To: <547F106D.5000107@oracle.com> References: <547F106D.5000107@oracle.com> Message-ID: <27DD7DEF-8C2A-48E5-A385-F6F17CC04AAF@oracle.com> Hi Sergey Thanks for reviewing the codes. I am the sponsor for this bug. Do you think it's OK for me to push the changes for java.desktop to jdk9/dev/jdk? Otherwise, can I push to jdk9/client/jdk myself or do I need to find someone in your group doing it? I am on the corelibs side and has only been working with the jdk9/dev forest. Thanks Max > On Dec 3, 2014, at 21:30, Sergey Bylokhov wrote: > > Hello, > The changes in java.desktop looks good. > > On 18.11.2014 11:58, Ot?vio Gon?alves de Santana wrote: >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055723 >> WEBREV: http://cr.openjdk.java.net/~weijun/8055723/webrev.01/ >> >> -- >> >> Ot?vio Gon?alves de Santana >> >> blog: http://otaviosantana.blogspot.com.br/ >> twitter: http://twitter.com/otaviojava >> site: http://about.me/otaviojava >> 55 (11) 98255-3513 > > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Wed Dec 3 14:47:04 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 03 Dec 2014 17:47:04 +0300 Subject: Review request: JDK-8055723 Replace concat String to append in StringBuilder parameters In-Reply-To: <27DD7DEF-8C2A-48E5-A385-F6F17CC04AAF@oracle.com> References: <547F106D.5000107@oracle.com> <27DD7DEF-8C2A-48E5-A385-F6F17CC04AAF@oracle.com> Message-ID: <547F2268.2060105@oracle.com> Hello. On 03.12.2014 17:40, Wang Weijun wrote: > Thanks for reviewing the codes. I am the sponsor for this bug. Do you think it's OK for me to push the changes for java.desktop to jdk9/dev/jdk? Otherwise, can I push to jdk9/client/jdk myself Yes, you can push it yourself to the jdk9/client/jdk > > Thanks > Max > >> On Dec 3, 2014, at 21:30, Sergey Bylokhov wrote: >> >> Hello, >> The changes in java.desktop looks good. >> >> On 18.11.2014 11:58, Ot?vio Gon?alves de Santana wrote: >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055723 >>> WEBREV: http://cr.openjdk.java.net/~weijun/8055723/webrev.01/ >>> >>> -- >>> >>> Ot?vio Gon?alves de Santana >>> >>> blog: http://otaviosantana.blogspot.com.br/ >>> twitter: http://twitter.com/otaviojava >>> site: http://about.me/otaviojava >>> 55 (11) 98255-3513 >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From joe.darcy at oracle.com Wed Dec 3 18:52:08 2014 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 03 Dec 2014 10:52:08 -0800 Subject: JDK 9 RFR of JDK-8055059: JDK9b22 public API exposes package private classes In-Reply-To: References: <53F2A970.4060500@oracle.com> Message-ID: <547F5BD8.7000206@oracle.com> Hi Petr, On 11/25/2014 12:50 AM, Petr Pchelko wrote: > Hello, Joe. > > The fix looks good. > > With best regards. Petr. Thanks for the review. While I wouldn't mind pushing this version, Phil and Anthony previously raised concerns that these types shouldn't be exposed at all: http://mail.openjdk.java.net/pipermail/swing-dev/2014-August/003829.html http://mail.openjdk.java.net/pipermail/swing-dev/2014-August/003830.html I haven't gotten around to preparing an alternate version using raw types, but I intend to do so. Cheers, -Joe > > On 19 ???. 2014 ?., at 5:33, Joe Darcy wrote: > >> Hello, >> >> Please review my proposed changes to address: >> >> JDK-8055059: JDK9b22 public API exposes package private classes >> http://cr.openjdk.java.net/~darcy/8055059.0/ >> >> Bug JDK-8055059 that the generification of swing added package-private types to the signatures of several protected methods. The solution is to the make the formerly package-private types also be protected. >> >> Patch below. >> >> Thanks, >> >> -Joe >> >> --- old/src/share/classes/javax/swing/text/GapContent.java 2014-08-18 18:27:50.000000000 -0700 >> +++ new/src/share/classes/javax/swing/text/GapContent.java 2014-08-18 18:27:49.000000000 -0700 >> @@ -826,7 +826,7 @@ >> * Used to hold a reference to a Mark that is being reset as the >> * result of removing from the content. >> */ >> - final class UndoPosRef { >> + protected final class UndoPosRef { >> UndoPosRef(MarkData rec) { >> this.rec = rec; >> this.undoLocation = rec.getOffset(); >> @@ -839,7 +839,7 @@ >> * @param endOffset end location of inserted string. >> * @param g1 resulting end of gap. >> */ >> - protected void resetLocation(int endOffset, int g1) { >> + void resetLocation(int endOffset, int g1) { >> if (undoLocation != endOffset) { >> this.rec.index = undoLocation; >> } >> @@ -849,9 +849,9 @@ >> } >> >> /** Previous Offset of rec. */ >> - protected int undoLocation; >> + private int undoLocation; >> /** Mark to reset offset. */ >> - protected MarkData rec; >> + private MarkData rec; >> } // End of GapContent.UndoPosRef >> >> >> --- old/src/share/classes/javax/swing/text/StringContent.java 2014-08-18 18:27:50.000000000 -0700 >> +++ new/src/share/classes/javax/swing/text/StringContent.java 2014-08-18 18:27:50.000000000 -0700 >> @@ -366,7 +366,7 @@ >> * Used to hold a reference to a Position that is being reset as the >> * result of removing from the content. >> */ >> - final class UndoPosRef { >> + protected final class UndoPosRef { >> UndoPosRef(PosRec rec) { >> this.rec = rec; >> this.undoLocation = rec.offset; >> @@ -376,14 +376,14 @@ >> * Resets the location of the Position to the offset when the >> * receiver was instantiated. >> */ >> - protected void resetLocation() { >> + void resetLocation() { >> rec.offset = undoLocation; >> } >> >> /** Location to reset to when resetLocatino is invoked. */ >> - protected int undoLocation; >> + private int undoLocation; >> /** Position to reset offset. */ >> - protected PosRec rec; >> + private PosRec rec; >> } >> >> /** >> From weijun.wang at oracle.com Thu Dec 4 03:20:46 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 4 Dec 2014 11:20:46 +0800 Subject: Review request: JDK-8055723 Replace concat String to append in StringBuilder parameters In-Reply-To: <547F2268.2060105@oracle.com> References: <547F106D.5000107@oracle.com> <27DD7DEF-8C2A-48E5-A385-F6F17CC04AAF@oracle.com> <547F2268.2060105@oracle.com> Message-ID: > > On Dec 3, 2014, at 22:47, Sergey Bylokhov wrote: > > Hello. > On 03.12.2014 17:40, Wang Weijun wrote: >> Thanks for reviewing the codes. I am the sponsor for this bug. Do you think it's OK for me to push the changes for java.desktop to jdk9/dev/jdk? You didn't answer the question above, or do you mean no? There is only one bug id now. If I have to push core changes to jdk9/dev and client ones to jdk9/client, I'll need to create a separate bug. Thanks Max >> Otherwise, can I push to jdk9/client/jdk myself > Yes, you can push it yourself to the jdk9/client/jdk >> >> Thanks >> Max > -- > Best regards, Sergey. From otaviojava at java.net Thu Dec 4 07:25:54 2014 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Thu, 4 Dec 2014 05:25:54 -0200 Subject: Review request: JDK-8055723 Replace concat String to append in StringBuilder parameters In-Reply-To: References: <547F106D.5000107@oracle.com> <27DD7DEF-8C2A-48E5-A385-F6F17CC04AAF@oracle.com> <547F2268.2060105@oracle.com> Message-ID: Yes, He did. On Thu, Dec 4, 2014 at 1:20 AM, Wang Weijun wrote: > > > > On Dec 3, 2014, at 22:47, Sergey Bylokhov > wrote: > > > > Hello. > > On 03.12.2014 17:40, Wang Weijun wrote: > >> Thanks for reviewing the codes. I am the sponsor for this bug. Do you > think it's OK for me to push the changes for java.desktop to jdk9/dev/jdk? > > You didn't answer the question above, or do you mean no? > > There is only one bug id now. If I have to push core changes to jdk9/dev > and client ones to jdk9/client, I'll need to create a separate bug. > > Thanks > Max > > >> Otherwise, can I push to jdk9/client/jdk myself > > Yes, you can push it yourself to the jdk9/client/jdk > <---------------here > Above: > >> Thanks > >> Max > > -- > > Best regards, Sergey. > > -- Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava * 55 (11) 98255-3513 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Thu Dec 4 13:55:37 2014 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 04 Dec 2014 16:55:37 +0300 Subject: [7u-dev] Request for approval for 8065098: JColorChooser no longer supports drag and drop between two JVM instances Message-ID: <548067D9.3070401@oracle.com> Hello, Could you please approve the following backport of the fix to jdk7u-dev? The patch doesn't apply cleanly automatically, code in DataTransferer.java differs. Yet there are no local changes in the code. Swing team, Could you also review the updated patch? http://cr.openjdk.java.net/~aivanov/8065098/jdk7/webrev.00/ JBS bug: https://bugs.openjdk.java.net/browse/JDK-8065098 Webrev: http://cr.openjdk.java.net/~alexsch/8065098/webrev.02/ Review: http://mail.openjdk.java.net/pipermail/swing-dev/2014-November/004028.html JDK9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/675344f2c1b6 JDK8 changeset: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/342b86d4ee27 Thank you in advance, Alexey From sean.coffey at oracle.com Thu Dec 4 14:01:39 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 04 Dec 2014 14:01:39 +0000 Subject: [7u-dev] Request for approval for 8065098: JColorChooser no longer supports drag and drop between two JVM instances In-Reply-To: <548067D9.3070401@oracle.com> References: <548067D9.3070401@oracle.com> Message-ID: <54806943.3070001@oracle.com> Approved with the condition that this gets a peer code review. regards, Sean. On 04/12/2014 13:55, Alexey Ivanov wrote: > Hello, > > Could you please approve the following backport of the fix to jdk7u-dev? > > The patch doesn't apply cleanly automatically, code in > DataTransferer.java differs. > Yet there are no local changes in the code. > > Swing team, > > Could you also review the updated patch? > http://cr.openjdk.java.net/~aivanov/8065098/jdk7/webrev.00/ > > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8065098 > Webrev: http://cr.openjdk.java.net/~alexsch/8065098/webrev.02/ > Review: > http://mail.openjdk.java.net/pipermail/swing-dev/2014-November/004028.html > > JDK9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/675344f2c1b6 > JDK8 changeset: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/342b86d4ee27 > > > Thank you in advance, > Alexey From neugens at redhat.com Fri Dec 5 13:29:29 2014 From: neugens at redhat.com (Mario Torre) Date: Fri, 05 Dec 2014 14:29:29 +0100 Subject: RFD: JEP: Modernize the GTK3 Look and Feel implementation for OpenJDK In-Reply-To: <1417090181.32571.27.camel@nirvana.localdomain> References: <1409155016.25913.6.camel@nirvana.localdomain> <1409220286.25913.8.camel@nirvana.localdomain> <1416583608.22846.43.camel@nirvana.localdomain> <1416584817.22846.49.camel@nirvana.localdomain> <54748C88.6080501@oracle.com> <1416926389.32571.5.camel@nirvana.localdomain> <54749E4F.2020903@oracle.com> <1416929665.32571.7.camel@nirvana.localdomain> <1417090181.32571.27.camel@nirvana.localdomain> Message-ID: <1417786169.25606.0.camel@nirvana.localdomain> On Thu, 2014-11-27 at 13:09 +0100, Mario Torre wrote: > On Tue, 2014-11-25 at 16:34 +0100, Mario Torre wrote: > > On Tue, 2014-11-25 at 18:20 +0300, Sergey Bylokhov wrote: > > > Hi, Mario. > > > You are talking about low level using of gtk2/3, I am sure it will be > > > good if two look&feels will share some code, but I was talking about the > > > high level, from the users point of view. It can be one LookAndFeel, but > > > with different implementations(an old one can be dropped easily later): > > > Note that if it will be different l&f, the user will be able to set one > > > of them and later the second one. This is resulting in gtk2 getting > > > loaded into a process having gtk3 already loaded, in this case we can > > > get errors like this: > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=431330 > > > > Right, I see now what you mean. > > > > Indeed, it makes totally sense. I'll amend the JEP with this > > information. > > I updated the JEP with your feedback: > > https://bugs.openjdk.java.net/browse/JDK-8065658 > > Thanks! > > Cheers, > Mario > Hi all, Any more comments on that? I would like to move the process forward if possible. Thanks! Cheers, Mario From sergey.bylokhov at oracle.com Mon Dec 8 15:08:06 2014 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 8 Dec 2014 07:08:06 -0800 (PST) Subject: [7u-dev] Request for approval for 8065098: JColorChooser no longer supports drag and drop between two JVM instances Message-ID: Hi, Alexey. The fix looks good. ----- sean.coffey at oracle.com wrote: > Approved with the condition that this gets a peer code review. > > regards, > Sean. > > On 04/12/2014 13:55, Alexey Ivanov wrote: > > Hello, > > > > Could you please approve the following backport of the fix to > jdk7u-dev? > > > > The patch doesn't apply cleanly automatically, code in > > DataTransferer.java differs. > > Yet there are no local changes in the code. > > > > Swing team, > > > > Could you also review the updated patch? > > http://cr.openjdk.java.net/~aivanov/8065098/jdk7/webrev.00/ > > > > > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8065098 > > Webrev: http://cr.openjdk.java.net/~alexsch/8065098/webrev.02/ > > Review: > > > http://mail.openjdk.java.net/pipermail/swing-dev/2014-November/004028.html > > > > JDK9 changeset: > > http://hg.openjdk.java.net/jdk9/client/jdk/rev/675344f2c1b6 > > JDK8 changeset: > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/342b86d4ee27 > > > > > > Thank you in advance, > > Alexey From alexandr.scherbatiy at oracle.com Mon Dec 8 15:27:47 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 08 Dec 2014 18:27:47 +0300 Subject: [7u-dev] Request for approval for 8065098: JColorChooser no longer supports drag and drop between two JVM instances In-Reply-To: References: Message-ID: <5485C373.3040806@oracle.com> The fix looks good. Thanks, Alexandr. On 12/8/2014 6:08 PM, Sergey Bylokhov wrote: > Hi, Alexey. > The fix looks good. > > ----- sean.coffey at oracle.com wrote: > >> Approved with the condition that this gets a peer code review. >> >> regards, >> Sean. >> >> On 04/12/2014 13:55, Alexey Ivanov wrote: >>> Hello, >>> >>> Could you please approve the following backport of the fix to >> jdk7u-dev? >>> The patch doesn't apply cleanly automatically, code in >>> DataTransferer.java differs. >>> Yet there are no local changes in the code. >>> >>> Swing team, >>> >>> Could you also review the updated patch? >>> http://cr.openjdk.java.net/~aivanov/8065098/jdk7/webrev.00/ >>> >>> >>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8065098 >>> Webrev: http://cr.openjdk.java.net/~alexsch/8065098/webrev.02/ >>> Review: >>> >> http://mail.openjdk.java.net/pipermail/swing-dev/2014-November/004028.html >>> JDK9 changeset: >>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/675344f2c1b6 >>> JDK8 changeset: >>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/342b86d4ee27 >>> >>> >>> Thank you in advance, >>> Alexey From joe.darcy at oracle.com Wed Dec 10 00:41:34 2014 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 09 Dec 2014 16:41:34 -0800 Subject: JDK 9 RFR of JDK-8066621: Suppress deprecation warnings in java.desktop module Message-ID: <548796BE.2030504@oracle.com> Hello, In support of JEP 212: Resolve Lint and Doclint Warnings (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, please review the large but straightforward set of changes in the webrev: http://cr.openjdk.java.net/~darcy/8066621.0/ Some background of the approach being taken to address this part of JEP 212 was discussed on core-libs: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html Briefly, to allow the deprecation warnings to be dealt with and that sole remaining lint warning category enabled in the build, a two-step approach is being taken. The first step is to suppress the deprecation warnings and the second step is for area-experts to examine the specific uses of deprecated APIs in their code. This webrev only attempts to cover the first step. The webrev is based off of the JDK 9 "dev" forest rather than the "client" forest. Since the change only involves copyright updates and adding annotations, there would be no functional modification in the changeset. Therefore, I would strongly prefer to push these changes directly to dev rather than pushing them to client and waiting for them to propagate to dev to expedite the time when the build warning can be enabled. (If a warning is not enabled in the build, new instances of the warning tend to creep into the code base.) Thanks, -Joe From victor.dyakov at oracle.com Thu Dec 11 06:20:05 2014 From: victor.dyakov at oracle.com (Victor D'yakov) Date: Thu, 11 Dec 2014 09:20:05 +0300 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation warnings in java.desktop module In-Reply-To: <548796BE.2030504@oracle.com> References: <548796BE.2030504@oracle.com> Message-ID: <54893795.6070800@oracle.com> Do we need to split it to AWT, Swing and 2D? The email is to 3 lists and its not clear who would pick up reviewing it. Also please use "client" forest this is our repo for pre-integration testing all together with Client SQE we are following to avoid regression cases. Victor On 10.12.2014 3:41, joe darcy wrote: > Hello, > > In support of JEP 212: Resolve Lint and Doclint Warnings > (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, please > review the large but straightforward set of changes in the webrev: > > http://cr.openjdk.java.net/~darcy/8066621.0/ > > Some background of the approach being taken to address this part of > JEP 212 was discussed on core-libs: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html > > > Briefly, to allow the deprecation warnings to be dealt with and that > sole remaining lint warning category enabled in the build, a two-step > approach is being taken. The first step is to suppress the deprecation > warnings and the second step is for area-experts to examine the > specific uses of deprecated APIs in their code. This webrev only > attempts to cover the first step. > > The webrev is based off of the JDK 9 "dev" forest rather than the > "client" forest. Since the change only involves copyright updates and > adding annotations, there would be no functional modification in the > changeset. Therefore, I would strongly prefer to push these changes > directly to dev rather than pushing them to client and waiting for > them to propagate to dev to expedite the time when the build warning > can be enabled. (If a warning is not enabled in the build, new > instances of the warning tend to creep into the code base.) > > Thanks, > > -Joe From joe.darcy at oracle.com Thu Dec 11 06:40:16 2014 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 10 Dec 2014 22:40:16 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation warnings in java.desktop module In-Reply-To: <54893795.6070800@oracle.com> References: <548796BE.2030504@oracle.com> <54893795.6070800@oracle.com> Message-ID: <54893C50.3080504@oracle.com> On 12/10/2014 10:20 PM, Victor D'yakov wrote: > Do we need to split it to AWT, Swing and 2D? I would not find that helpful. > The email is to 3 lists and its not clear who would pick up reviewing it. I assume the people in each are would review their piece of the change. > > Also please use "client" forest this is our repo for pre-integration > testing all together with Client SQE we are following to avoid > regression cases. As I explained below, since the code changes involve only copyright updates (in comments) and annotations (which don't affect the generated bytecode), there will no be functional change in the output based on this changeset. Therefore, as long as a build succeeds, I don't see what difference client SQE testing would make in this particular case. -Joe > > Victor > > On 10.12.2014 3:41, joe darcy wrote: >> Hello, >> >> In support of JEP 212: Resolve Lint and Doclint Warnings >> (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, >> please review the large but straightforward set of changes in the >> webrev: >> >> http://cr.openjdk.java.net/~darcy/8066621.0/ >> >> Some background of the approach being taken to address this part of >> JEP 212 was discussed on core-libs: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html >> >> >> Briefly, to allow the deprecation warnings to be dealt with and that >> sole remaining lint warning category enabled in the build, a two-step >> approach is being taken. The first step is to suppress the >> deprecation warnings and the second step is for area-experts to >> examine the specific uses of deprecated APIs in their code. This >> webrev only attempts to cover the first step. >> >> The webrev is based off of the JDK 9 "dev" forest rather than the >> "client" forest. Since the change only involves copyright updates and >> adding annotations, there would be no functional modification in the >> changeset. Therefore, I would strongly prefer to push these changes >> directly to dev rather than pushing them to client and waiting for >> them to propagate to dev to expedite the time when the build warning >> can be enabled. (If a warning is not enabled in the build, new >> instances of the warning tend to creep into the code base.) >> >> Thanks, >> >> -Joe > From Alan.Bateman at oracle.com Thu Dec 11 10:25:29 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Dec 2014 10:25:29 +0000 Subject: JDK 9 RFR of JDK-8066621: Suppress deprecation warnings in java.desktop module In-Reply-To: <548796BE.2030504@oracle.com> References: <548796BE.2030504@oracle.com> Message-ID: <54897119.4080307@oracle.com> On 10/12/2014 00:41, joe darcy wrote: > Hello, > > In support of JEP 212: Resolve Lint and Doclint Warnings > (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, please > review the large but straightforward set of changes in the webrev: > > http://cr.openjdk.java.net/~darcy/8066621.0/ > > Some background of the approach being taken to address this part of > JEP 212 was discussed on core-libs: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html > > > Briefly, to allow the deprecation warnings to be dealt with and that > sole remaining lint warning category enabled in the build, a two-step > approach is being taken. The first step is to suppress the deprecation > warnings and the second step is for area-experts to examine the > specific uses of deprecated APIs in their code. This webrev only > attempts to cover the first step. > > The webrev is based off of the JDK 9 "dev" forest rather than the > "client" forest. Since the change only involves copyright updates and > adding annotations, there would be no functional modification in the > changeset. Therefore, I would strongly prefer to push these changes > directly to dev rather than pushing them to client and waiting for > them to propagate to dev to expedite the time when the build warning > can be enabled. (If a warning is not enabled in the build, new > instances of the warning tend to creep into the code base.) I've skimmed through the changes and they look okay to me. Clearly it would be nice to get some of these addresses so that the @SuppressWarnings can be removed in time. As you've pointed out, the changes don't impact the generated code. -Alan. From Sergey.Bylokhov at oracle.com Fri Dec 12 12:54:07 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 12 Dec 2014 15:54:07 +0300 Subject: [9] Review Request: 6470361 Swing's Threading Policy example does not compile Message-ID: <548AE56F.4020906@oracle.com> Hello. Please review the small documentation fix for jdk 9. Bug: https://bugs.openjdk.java.net/browse/JDK-6470361 Webrev can be found at: http://cr.openjdk.java.net/~serb/6470361/webrev.00 -- Best regards, Sergey. From philip.race at oracle.com Fri Dec 12 20:46:44 2014 From: philip.race at oracle.com (Phil Race) Date: Fri, 12 Dec 2014 12:46:44 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation warnings in java.desktop module In-Reply-To: <548796BE.2030504@oracle.com> References: <548796BE.2030504@oracle.com> Message-ID: <548B5434.4020609@oracle.com> Hi, You did not provide a direct reference to the set of warnings that were generated. fortunately I found it here :- https://bugs.openjdk.java.net/browse/JDK-8066622 A couple of things I find 'unfortunate' are 1) In order to avoid a deprecation warning on one call/line of a 100 line method, the entire method is subject to the annotation. Eg :- dev/jdk/src/java.desktop/share/classes/javax/print/ServiceUI.java:226: warning: [deprecation] show() in Dialog has been deprecated Other deprecated uses could silently creep into such a body of code. 2) Some significant fraction of all the warnings are for getPeer() :- dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821: warning: [deprecation] getPeer() in Component has been deprecated The issue here is that the deprecation javadoc tag is unable to distinguish deprecated for external usage vs legitimate internal usage. There is no problem with code inside the desktop module calling getPeer() which is defined in this same module. There may not be many other APIs that have this similar issue, but if there are it might be better to find some way to make it clear that we aren't suppressing warnings until we fix the code : rather we really should not be receiving a warning here anyway since there is nothing to fix. Perhaps "Component. getPeer()" could acquire an annotation like "module-nodeprecation" which automatically suppresses the annotation processor warnings for all such cases. If javac doesn't know about modules perhaps we could utilise a javac flag that's used only by the JDK build to indicate that an annotation like that should apply. Regarding the show() case above I came across a puzzle. show() is first defined on Component, as is its 'replacement' setVisible(boolean). It turns out that what we have in Component is public void setVisible(boolean b) { show(b); } @Deprecated public void show(boolean b) { if (b) { show(); } else { hide(); } @Deprecated public void show() { ... } So I am puzzled why those uses within Component aren't suppressed in your webrev ? Is there some automatic suppression of the warnings within the class that does the deprecation ? If so then perhaps the module idea above can be considered an extension of this. If that isn't what's happening, then what is ? -phil. On 12/9/2014 4:41 PM, joe darcy wrote: > Hello, > > In support of JEP 212: Resolve Lint and Doclint Warnings > (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, please > review the large but straightforward set of changes in the webrev: > > http://cr.openjdk.java.net/~darcy/8066621.0/ > > Some background of the approach being taken to address this part of > JEP 212 was discussed on core-libs: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html > > > Briefly, to allow the deprecation warnings to be dealt with and that > sole remaining lint warning category enabled in the build, a two-step > approach is being taken. The first step is to suppress the deprecation > warnings and the second step is for area-experts to examine the > specific uses of deprecated APIs in their code. This webrev only > attempts to cover the first step. > > The webrev is based off of the JDK 9 "dev" forest rather than the > "client" forest. Since the change only involves copyright updates and > adding annotations, there would be no functional modification in the > changeset. Therefore, I would strongly prefer to push these changes > directly to dev rather than pushing them to client and waiting for > them to propagate to dev to expedite the time when the build warning > can be enabled. (If a warning is not enabled in the build, new > instances of the warning tend to creep into the code base.) > > Thanks, > > -Joe From joe.darcy at oracle.com Sat Dec 13 01:35:17 2014 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 12 Dec 2014 17:35:17 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation warnings in java.desktop module In-Reply-To: <548B5434.4020609@oracle.com> References: <548796BE.2030504@oracle.com> <548B5434.4020609@oracle.com> Message-ID: <548B97D5.9050408@oracle.com> Hi Phil, On 12/12/2014 12:46 PM, Phil Race wrote: > Hi, > You did not provide a direct reference to the set of warnings that > were generated. > fortunately I found it here :- > https://bugs.openjdk.java.net/browse/JDK-8066622 Each "Suppress deprecations warnings in foo" bug is linked to a "Fix deprecation warnings in foo" bug which lists the exact warnings. > > A couple of things I find 'unfortunate' are > 1) In order to avoid a deprecation warning on one call/line of a 100 > line method, > the entire method is subject to the annotation. Eg :- > dev/jdk/src/java.desktop/share/classes/javax/print/ServiceUI.java:226: > warning: [deprecation] show() in Dialog has been deprecated > > Other deprecated uses could silently creep into such a body of code. That is true, but today deprecations warnings can (and do) creep into the entirely of the JDK without notice. Turning on the deprecation lint warning in the build will prevent that for the vast majority of code, which is why I want to get the remaining warning suppression bugs quickly pushed into JDK 9 so the build warning can be enabled. (This suppression effort was on hold until a small language change was recently implemented in JDK 9 to eliminate deprecation warnings just for importing a deprecated type.) For the "fix the warning" companion bug to this bug, I would recommend factoring out the deprecated method call into its own private method to limit the scope of the @SuppressWarning annotation. For this changeset, I didn't want to actually modify the contents or structure of any methods I so didn't undertake that kind of transformation. > > 2) Some significant fraction of all the warnings are for getPeer() :- > dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821: > warning: [deprecation] getPeer() in Component has been deprecated Yes, I also noticed that a sizeable percentage of the warnings were for uses of that one method. > > The issue here is that the deprecation javadoc tag is unable to > distinguish deprecated for > external usage vs legitimate internal usage. FYI, Stuart Mark / Dr. Deprecator gave an interesting talk at JavaOne this year covering the nuances of deprecation in the JDK: https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=6377 > There is no problem with code inside the desktop module > calling getPeer() which is defined in this same module. There may not > be many other APIs that > have this similar issue, but if there are it might be better to find > some way to make it clear > that we aren't suppressing warnings until we fix the code : rather we > really should not be > receiving a warning here anyway since there is nothing to fix. Well, the @SuppressWarnings annotation can be used to convey that information, perhaps supplemented by a comment or a wrapper method around getPeer; something like /** * Package-access method somewhere in java.awt */ @SuppressWarnings("deprecation") static java.awt Component privilegeOfPeerage(java.awt Component c) { return c.getPeer(); } > Perhaps "Component. getPeer()" > could acquire an annotation like "module-nodeprecation" which > automatically suppresses the > annotation processor warnings for all such cases. If javac doesn't > know about modules perhaps > we could utilise a javac flag that's used only by the JDK build to > indicate that an annotation > like that should apply. At this point, I think that level of solution would be overkill (especially given the JDK's historical lack of discipline around deprecation warnings). > > Regarding the show() case above I came across a puzzle. > show() is first defined on Component, as is its 'replacement' > setVisible(boolean). > It turns out that what we have in Component is > > public void setVisible(boolean b) { > show(b); > } > > @Deprecated > public void show(boolean b) { > if (b) { > show(); > } else { > hide(); > } > > @Deprecated > public void show() { > ... > } > > So I am puzzled why those uses within Component aren't suppressed in > your webrev ? > Is there some automatic suppression of the warnings within the class > that does > the deprecation ? Yes, quoting from the JLS: "A Java compiler must produce a deprecation warning when a type, method, field, or constructor whose declaration is annotated with |@Deprecated| is used (overridden, invoked, or referenced by name) in a construct which is explicitly or implicitly declared, unless: * [...] * The use and declaration are both within the same outermost class. " http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.4.6 Thanks for the review, -Joe > If so then perhaps the module idea above can be considered > an extension of this. If that isn't what's happening, then what is ? > > -phil. > > > > > > On 12/9/2014 4:41 PM, joe darcy wrote: >> Hello, >> >> In support of JEP 212: Resolve Lint and Doclint Warnings >> (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, >> please review the large but straightforward set of changes in the >> webrev: >> >> http://cr.openjdk.java.net/~darcy/8066621.0/ >> >> Some background of the approach being taken to address this part of >> JEP 212 was discussed on core-libs: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html >> >> >> Briefly, to allow the deprecation warnings to be dealt with and that >> sole remaining lint warning category enabled in the build, a two-step >> approach is being taken. The first step is to suppress the >> deprecation warnings and the second step is for area-experts to >> examine the specific uses of deprecated APIs in their code. This >> webrev only attempts to cover the first step. >> >> The webrev is based off of the JDK 9 "dev" forest rather than the >> "client" forest. Since the change only involves copyright updates and >> adding annotations, there would be no functional modification in the >> changeset. Therefore, I would strongly prefer to push these changes >> directly to dev rather than pushing them to client and waiting for >> them to propagate to dev to expedite the time when the build warning >> can be enabled. (If a warning is not enabled in the build, new >> instances of the warning tend to creep into the code base.) >> >> Thanks, >> >> -Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Dec 13 09:11:08 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 13 Dec 2014 09:11:08 +0000 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation warnings in java.desktop module In-Reply-To: <548B5434.4020609@oracle.com> References: <548796BE.2030504@oracle.com> <548B5434.4020609@oracle.com> Message-ID: <548C02AC.4020301@oracle.com> On 12/12/2014 20:46, Phil Race wrote: > : > > 2) Some significant fraction of all the warnings are for getPeer() :- > dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821: > warning: [deprecation] getPeer() in Component has been deprecated > > The issue here is that the deprecation javadoc tag is unable to > distinguish deprecated for > external usage vs legitimate internal usage. There is no problem with > code inside the desktop module > calling getPeer() which is defined in this same module. In our modularization effort then the highest priority issue for the client libraries area is JDK-8037739. This issue is about examining the supportness of the peer APIs, and assuming they aren't meant to be exported, then removing all references from the Java SE APIs (which might mean removing methods). Assuming that java.awt.peer and java.awt.dnd.peer are JDK-internal then you could drop the @Deprecated tags. -Alan From alexandr.scherbatiy at oracle.com Mon Dec 15 11:09:16 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 15 Dec 2014 14:09:16 +0300 Subject: [9] Review Request: 6470361 Swing's Threading Policy example does not compile In-Reply-To: <548AE56F.4020906@oracle.com> References: <548AE56F.4020906@oracle.com> Message-ID: <548EC15C.9020909@oracle.com> The fix looks good to me. Thanks, Alexandr. On 12/12/2014 3:54 PM, Sergey Bylokhov wrote: > Hello. > Please review the small documentation fix for jdk 9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6470361 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/6470361/webrev.00 > From alexandr.scherbatiy at oracle.com Mon Dec 15 12:24:51 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 15 Dec 2014 15:24:51 +0300 Subject: [9] Review request for 6219960 null reference in ToolTipManager In-Reply-To: <53D66034.7080000@oracle.com> References: <53D65C13.8040600@oracle.com> <53D66034.7080000@oracle.com> Message-ID: <548ED313.6080001@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/6219960/webrev.01/ - The test has been added Thanks, Alexandr. On 7/28/2014 5:37 PM, Sergey Bylokhov wrote: > Hi, Alexander. > What about the test? I see that it was added to the bug comment. > > On 7/28/14 6:20 PM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-6219960 >> webrev: http://cr.openjdk.java.net/~alexsch/6219960/webrev.00 >> >> >> The NPE is fixed. >> >> Thanks, >> Alexandr. >> > > From alexander.zvegintsev at oracle.com Mon Dec 15 12:54:07 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 15 Dec 2014 15:54:07 +0300 Subject: [9] Review request for 6219960 null reference in ToolTipManager In-Reply-To: <548ED313.6080001@oracle.com> References: <53D65C13.8040600@oracle.com> <53D66034.7080000@oracle.com> <548ED313.6080001@oracle.com> Message-ID: <548ED9EF.20203@oracle.com> Hi Alexandr, the fix looks good to me. Thanks, Alexander. On 12/15/2014 03:24 PM, Alexander Scherbatiy wrote: > > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/6219960/webrev.01/ > > - The test has been added > > Thanks, > Alexandr. > > On 7/28/2014 5:37 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> What about the test? I see that it was added to the bug comment. >> >> On 7/28/14 6:20 PM, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-6219960 >>> webrev: http://cr.openjdk.java.net/~alexsch/6219960/webrev.00 >>> >>> >>> The NPE is fixed. >>> >>> Thanks, >>> Alexandr. >>> >> >> > From alexander.zvegintsev at oracle.com Mon Dec 15 14:39:36 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 15 Dec 2014 17:39:36 +0300 Subject: [9] Review Request: 6470361 Swing's Threading Policy example does not compile In-Reply-To: <548AE56F.4020906@oracle.com> References: <548AE56F.4020906@oracle.com> Message-ID: <548EF2A8.8060307@oracle.com> Hello Sergey, I think that we should not use lambda expression here. Someone who skimmed through these samples may not notice a lambda expression, and write something like this later: public class SomeClass implements Runnable { private final JFrame f = new JFrame(); // invoked on the main thread public SomeClass() { f.setBounds(100, 100, 100, 100); // invoked on the main thread } @Override public void run() { f.setVisible(true); } public static void main(String[] args) { SwingUtilities.invokeLater(new SomeClass()); } } Or even better: we should clarify this somewhere explicitly. Thanks, Alexander. On 12/12/2014 03:54 PM, Sergey Bylokhov wrote: > Hello. > Please review the small documentation fix for jdk 9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6470361 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/6470361/webrev.00 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Dec 15 15:46:07 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 15 Dec 2014 18:46:07 +0300 Subject: [9] Review request for 8067441 Some tests fails with error: cannot find symbol getSystemMnemonicKeyCodes() Message-ID: <548F023F.3010706@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8067441 webrev: http://cr.openjdk.java.net/~alexsch/8067441/webrev.00 The getSystemMnemonicKeyCodes() has been removed from the Util.java class during the fix JDK-8063104. But the hitMnemonics(Robot robot, int... keys) still uses the getSystemMnemonicKeyCodes() method. The fix returns the getSystemMnemonicKeyCodes() method back. Thanks, Alexandr. From alexander.zvegintsev at oracle.com Mon Dec 15 16:04:37 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 15 Dec 2014 19:04:37 +0300 Subject: [9] Review request for 8067441 Some tests fails with error: cannot find symbol getSystemMnemonicKeyCodes() In-Reply-To: <548F023F.3010706@oracle.com> References: <548F023F.3010706@oracle.com> Message-ID: <548F0695.9010708@oracle.com> Hello Alexandr, the fix looks good to me. Thanks, Alexander. On 12/15/2014 06:46 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8067441 > webrev: http://cr.openjdk.java.net/~alexsch/8067441/webrev.00 > > The getSystemMnemonicKeyCodes() has been removed from the Util.java > class during the fix JDK-8063104. > But the hitMnemonics(Robot robot, int... keys) still uses the > getSystemMnemonicKeyCodes() method. > The fix returns the getSystemMnemonicKeyCodes() method back. > > > Thanks, > Alexandr. > From Sergey.Bylokhov at oracle.com Mon Dec 15 16:10:42 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 15 Dec 2014 19:10:42 +0300 Subject: [9] Review request for 8067441 Some tests fails with error: cannot find symbol getSystemMnemonicKeyCodes() In-Reply-To: <548F0695.9010708@oracle.com> References: <548F023F.3010706@oracle.com> <548F0695.9010708@oracle.com> Message-ID: <548F0802.80200@oracle.com> Looks fine. On 15.12.2014 19:04, Alexander Zvegintsev wrote: > Hello Alexandr, > > the fix looks good to me. > > Thanks, > > Alexander. > > On 12/15/2014 06:46 PM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8067441 >> webrev: http://cr.openjdk.java.net/~alexsch/8067441/webrev.00 >> >> The getSystemMnemonicKeyCodes() has been removed from the Util.java >> class during the fix JDK-8063104. >> But the hitMnemonics(Robot robot, int... keys) still uses the >> getSystemMnemonicKeyCodes() method. >> The fix returns the getSystemMnemonicKeyCodes() method back. >> >> >> Thanks, >> Alexandr. >> > -- Best regards, Sergey. From jason_mehrens at hotmail.com Mon Dec 15 18:14:00 2014 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Mon, 15 Dec 2014 12:14:00 -0600 Subject: [9] Review request for 6219960 null reference in ToolTipManager In-Reply-To: <548ED313.6080001@oracle.com> References: <53D65C13.8040600@oracle.com> <53D66034.7080000@oracle.com>,<548ED313.6080001@oracle.com> Message-ID: Alexandr, The fix looks good. The root cause of this error is that mouseExited is not fired on the focused container when a modal dialog is shown. I'm surprised that there isn't a linked issue against AWT to either fix the toolkit to fire the mouseExited (via the Z axis) on modal dialog, suppress the 2nd call to mouseEntered after dialog is closed, or fix the MousListener documentation to state that how the mouse cursor enters or leaves a component has some exceptional conditions. My preference would be to fire mouseExited on modal dialog shown. Jason ---------------------------------------- > Date: Mon, 15 Dec 2014 15:24:51 +0300 > From: alexandr.scherbatiy at oracle.com > To: Sergey.Bylokhov at oracle.com > CC: swing-dev at openjdk.java.net > Subject: Re: [9] Review request for 6219960 null reference in ToolTipManager > > > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/6219960/webrev.01/ > > - The test has been added > > Thanks, > Alexandr. > > On 7/28/2014 5:37 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> What about the test? I see that it was added to the bug comment. >> >> On 7/28/14 6:20 PM, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-6219960 >>> webrev: http://cr.openjdk.java.net/~alexsch/6219960/webrev.00 >>> >>> >>> The NPE is fixed. >>> >>> Thanks, >>> Alexandr. >>> >> >> > From philip.race at oracle.com Mon Dec 15 19:48:37 2014 From: philip.race at oracle.com (Phil Race) Date: Mon, 15 Dec 2014 11:48:37 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation warnings in java.desktop module In-Reply-To: <548B97D5.9050408@oracle.com> References: <548796BE.2030504@oracle.com> <548B5434.4020609@oracle.com> <548B97D5.9050408@oracle.com> Message-ID: <548F3B15.1050300@oracle.com> On 12/12/14 5:35 PM, joe darcy wrote: > Hi Phil, > > On 12/12/2014 12:46 PM, Phil Race wrote: >> Hi, >> You did not provide a direct reference to the set of warnings that >> were generated. >> fortunately I found it here :- >> https://bugs.openjdk.java.net/browse/JDK-8066622 > > Each "Suppress deprecations warnings in foo" bug is linked to a "Fix > deprecation warnings in foo" bug which lists the exact warnings. > OK .. direct link would have helped. >> >> A couple of things I find 'unfortunate' are >> 1) In order to avoid a deprecation warning on one call/line of a 100 >> line method, >> the entire method is subject to the annotation. Eg :- >> dev/jdk/src/java.desktop/share/classes/javax/print/ServiceUI.java:226: warning: >> [deprecation] show() in Dialog has been deprecated >> >> Other deprecated uses could silently creep into such a body of code. > > That is true, but today deprecations warnings can (and do) creep into > the entirely of the JDK without notice. Turning on the deprecation > lint warning in the build will prevent that for the vast majority of > code, which is why I want to get the remaining warning suppression > bugs quickly pushed into JDK 9 so the build warning can be enabled. > (This suppression effort was on hold until a small language change was > recently implemented in JDK 9 to eliminate deprecation warnings just > for importing a deprecated type.) Maybe a digression, but why go to the trouble, why would one legitimately import a (deprecated) type and yet not use it ? But the gist of my point is that with this approach more warnings can still creep in. Its unfortunate that the annotation system does not provide a way to annotate the specific call and so it is not apparent to the reader what its suppressing. > For the "fix the warning" companion bug to this bug, I would recommend > factoring out the deprecated method call into its own private method > to limit the scope of the @SuppressWarning annotation. For this > changeset, I didn't want to actually modify the contents or structure > of any methods I so didn't undertake that kind of transformation. Adding a wrapper method seems artificial. Personally I would prefer to find a solution in the annotation system or find a replacement or de-deprecating as Alan suggested might work in some cases, although Stuart Marks said RMI has the same case. >> >> 2) Some significant fraction of all the warnings are for getPeer() :- >> dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821: >> warning: [deprecation] getPeer() in Component has been deprecated > > Yes, I also noticed that a sizeable percentage of the warnings were > for uses of that one method. > >> >> The issue here is that the deprecation javadoc tag is unable to >> distinguish deprecated for >> external usage vs legitimate internal usage. > > FYI, Stuart Mark / Dr. Deprecator gave an interesting talk at JavaOne > this year covering the nuances of deprecation in the JDK: > > https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=6377 > >> There is no problem with code inside the desktop module >> calling getPeer() which is defined in this same module. There may >> not be many other APIs that >> have this similar issue, but if there are it might be better to find >> some way to make it clear >> that we aren't suppressing warnings until we fix the code : rather we >> really should not be >> receiving a warning here anyway since there is nothing to fix. > > Well, the @SuppressWarnings annotation can be used to convey that > information, perhaps supplemented by a comment or a wrapper method > around getPeer; something like > > /** > * Package-access method somewhere in java.awt > */ > @SuppressWarnings("deprecation") > static java.awt Component privilegeOfPeerage(java.awt Component c) { > return c.getPeer(); > } > I don't think that conveys that its OK to use. It just adds work to hide it in a different way. >> Perhaps "Component. getPeer()" >> could acquire an annotation like "module-nodeprecation" which >> automatically suppresses the >> annotation processor warnings for all such cases. If javac doesn't >> know about modules perhaps >> we could utilise a javac flag that's used only by the JDK build to >> indicate that an annotation >> like that should apply. > > At this point, I think that level of solution would be overkill > (especially given the JDK's historical lack of discipline around > deprecation warnings). > Well .. I think its worth more discussion than dismissing it out of hand. >> >> Regarding the show() case above I came across a puzzle. >> show() is first defined on Component, as is its 'replacement' >> setVisible(boolean). >> It turns out that what we have in Component is >> >> public void setVisible(boolean b) { >> show(b); >> } >> >> @Deprecated >> public void show(boolean b) { >> if (b) { >> show(); >> } else { >> hide(); >> } >> >> @Deprecated >> public void show() { >> ... >> } >> >> So I am puzzled why those uses within Component aren't suppressed in >> your webrev ? >> Is there some automatic suppression of the warnings within the class >> that does >> the deprecation ? > > Yes, quoting from the JLS: > > "A Java compiler must produce a deprecation warning when a type, > method, field, or constructor whose declaration is annotated with > |@Deprecated| is used (overridden, invoked, or referenced by name) in > a construct which is explicitly or implicitly declared, unless: > * [...] > * The use and declaration are both within the same outermost class. " > > http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.4.6 OK. So that's not as well known as you'd think. It stumped Stuart. I had to 'infer' this from the observed behaviour. At this point I'll approve the changes although I would like full consideration of enhancements to the APS in the future. Also I believe this should go to client. If it gets pushed by the end of the day or at least no later than the end of tomorrow it should be integrated by 23rd. -phil. > > Thanks for the review, > > -Joe > >> If so then perhaps the module idea above can be considered >> an extension of this. If that isn't what's happening, then what is ? >> >> -phil. >> >> >> >> >> >> On 12/9/2014 4:41 PM, joe darcy wrote: >>> Hello, >>> >>> In support of JEP 212: Resolve Lint and Doclint Warnings >>> (http://openjdk.java.net/jeps/212), which is targeted to JDK 9, >>> please review the large but straightforward set of changes in the >>> webrev: >>> >>> http://cr.openjdk.java.net/~darcy/8066621.0/ >>> >>> Some background of the approach being taken to address this part of >>> JEP 212 was discussed on core-libs: >>> >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030085.html >>> >>> >>> Briefly, to allow the deprecation warnings to be dealt with and that >>> sole remaining lint warning category enabled in the build, a >>> two-step approach is being taken. The first step is to suppress the >>> deprecation warnings and the second step is for area-experts to >>> examine the specific uses of deprecated APIs in their code. This >>> webrev only attempts to cover the first step. >>> >>> The webrev is based off of the JDK 9 "dev" forest rather than the >>> "client" forest. Since the change only involves copyright updates >>> and adding annotations, there would be no functional modification in >>> the changeset. Therefore, I would strongly prefer to push these >>> changes directly to dev rather than pushing them to client and >>> waiting for them to propagate to dev to expedite the time when the >>> build warning can be enabled. (If a warning is not enabled in the >>> build, new instances of the warning tend to creep into the code base.) >>> >>> Thanks, >>> >>> -Joe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Dec 16 04:07:30 2014 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 15 Dec 2014 20:07:30 -0800 Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8066621: Suppress deprecation warnings in java.desktop module In-Reply-To: <548F3B15.1050300@oracle.com> References: <548796BE.2030504@oracle.com> <548B5434.4020609@oracle.com> <548B97D5.9050408@oracle.com> <548F3B15.1050300@oracle.com> Message-ID: <548FB002.4030809@oracle.com> On 12/15/2014 11:48 AM, Phil Race wrote: > > > On 12/12/14 5:35 PM, joe darcy wrote: >> Hi Phil, >> >> On 12/12/2014 12:46 PM, Phil Race wrote: >>> Hi, >>> You did not provide a direct reference to the set of warnings that >>> were generated. >>> fortunately I found it here :- >>> https://bugs.openjdk.java.net/browse/JDK-8066622 >> >> Each "Suppress deprecations warnings in foo" bug is linked to a "Fix >> deprecation warnings in foo" bug which lists the exact warnings. >> > OK .. direct link would have helped. > > >>> >>> A couple of things I find 'unfortunate' are >>> 1) In order to avoid a deprecation warning on one call/line of a 100 >>> line method, >>> the entire method is subject to the annotation. Eg :- >>> dev/jdk/src/java.desktop/share/classes/javax/print/ServiceUI.java:226: >>> warning: [deprecation] show() in Dialog has been deprecated >>> >>> Other deprecated uses could silently creep into such a body of code. >> >> That is true, but today deprecations warnings can (and do) creep into >> the entirely of the JDK without notice. Turning on the deprecation >> lint warning in the build will prevent that for the vast majority of >> code, which is why I want to get the remaining warning suppression >> bugs quickly pushed into JDK 9 so the build warning can be enabled. >> (This suppression effort was on hold until a small language change >> was recently implemented in JDK 9 to eliminate deprecation warnings >> just for importing a deprecated type.) > > Maybe a digression, but why go to the trouble, why would one > legitimately import a > (deprecated) type and yet not use it ? That is not the scenario that is problematic. If you @SuppressWarnings("deprecation") at the top of a class, that declaration annotation does *not* cover import statements. Additionally, a @SuppressWarnings("deprecation") annotation cannot be applied to import statements (this is a restriction since JDK 5). Therefore, before the small language change to elide deprecation warnings on import statements made in JDK 9 (JEP 211), you could have a class where: * A deprecated type was imported * All the uses of the deprecated type in the code were @SuppressWarnings'ed and still the class would generate deprecation warnings when it was compiled. To get a warning-free compile, the import statement would need to be removed and all the uses of the type replaced by fully qualified names, which is an unreasonable transformation to get warning-free code! > > But the gist of my point is that with this approach more warnings can > still creep in. > Its unfortunate that the annotation system does not provide a way to > annotate the specific call > and so it is not apparent to the reader what its suppressing. Conversely, the downside of annotating every call site is that every call site is annotated... All the @SuppressWarnings annotations are scoped to the declaration they are applied to (type, method/constructor, field). If you want to reduce the scope of warning suppression, a new scope can be introduced, such as a new method to contain the problematic construct. (This is analogous to introducing a new temporary variable with an @SuppressWarnings annotation to constrain the suppression to the expression used to initialize the variable, a technique that was used on occasion in the warnings cleanup changes earlier in JDK 9.) > >> For the "fix the warning" companion bug to this bug, I would >> recommend factoring out the deprecated method call into its own >> private method to limit the scope of the @SuppressWarning annotation. >> For this changeset, I didn't want to actually modify the contents or >> structure of any methods I so didn't undertake that kind of >> transformation. > Adding a wrapper method seems artificial. > Personally I would prefer to find a solution in the annotation system > or find a replacement or de-deprecating > as Alan suggested might work in some cases, although Stuart Marks said > RMI has the same case. > > >>> >>> 2) Some significant fraction of all the warnings are for getPeer() :- >>> dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821: >>> warning: [deprecation] getPeer() in Component has been deprecated >> >> Yes, I also noticed that a sizeable percentage of the warnings were >> for uses of that one method. > >> >>> >>> The issue here is that the deprecation javadoc tag is unable to >>> distinguish deprecated for >>> external usage vs legitimate internal usage. >> >> FYI, Stuart Mark / Dr. Deprecator gave an interesting talk at JavaOne >> this year covering the nuances of deprecation in the JDK: >> >> https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=6377 >> >>> There is no problem with code inside the desktop module >>> calling getPeer() which is defined in this same module. There may >>> not be many other APIs that >>> have this similar issue, but if there are it might be better to find >>> some way to make it clear >>> that we aren't suppressing warnings until we fix the code : rather >>> we really should not be >>> receiving a warning here anyway since there is nothing to fix. >> >> Well, the @SuppressWarnings annotation can be used to convey that >> information, perhaps supplemented by a comment or a wrapper method >> around getPeer; something like >> >> /** >> * Package-access method somewhere in java.awt >> */ >> @SuppressWarnings("deprecation") >> static java.awt Component privilegeOfPeerage(java.awt Component c) { >> return c.getPeer(); >> } >> > > I don't think that conveys that its OK to use. It just adds work to > hide it in a different way. A comment could be added to clarify "Package-level method to allow warning-free package-level use." > >>> Perhaps "Component. getPeer()" >>> could acquire an annotation like "module-nodeprecation" which >>> automatically suppresses the >>> annotation processor warnings for all such cases. If javac doesn't >>> know about modules perhaps >>> we could utilise a javac flag that's used only by the JDK build to >>> indicate that an annotation >>> like that should apply. >> >> At this point, I think that level of solution would be overkill >> (especially given the JDK's historical lack of discipline around >> deprecation warnings). >> > > Well .. I think its worth more discussion than dismissing it out of hand. >>> >>> Regarding the show() case above I came across a puzzle. >>> show() is first defined on Component, as is its 'replacement' >>> setVisible(boolean). >>> It turns out that what we have in Component is >>> >>> public void setVisible(boolean b) { >>> show(b); >>> } >>> >>> @Deprecated >>> public void show(boolean b) { >>> if (b) { >>> show(); >>> } else { >>> hide(); >>> } >>> >>> @Deprecated >>> public void show() { >>> ... >>> } >>> >>> So I am puzzled why those uses within Component aren't suppressed in >>> your webrev ? >>> Is there some automatic suppression of the warnings within the class >>> that does >>> the deprecation ? >> >> Yes, quoting from the JLS: >> >> "A Java compiler must produce a deprecation warning when a type, >> method, field, or constructor whose declaration is annotated with >> |@Deprecated| is used (overridden, invoked, or referenced by name) in >> a construct which is explicitly or implicitly declared, unless: >> * [...] >> * The use and declaration are both within the same outermost class. " >> >> http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.6.4.6 > > OK. So that's not as well known as you'd think. It stumped Stuart. > I had to 'infer' this from the observed behaviour. Although it may be surprising, that aspect of deprecation goes back a long ways. > > At this point I'll approve the changes although I would like full > consideration > of enhancements to the APS in the future. > > Also I believe this should go to client. If it gets pushed by the end > of the day > or at least no later than the end of tomorrow it should be integrated > by 23rd. I've pushed the changes to the client repo. I will be soon preparing two additional changesets for review to perform similar deprecation warning suppression in platform-specific client code. Thanks, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Dec 16 15:02:27 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 16 Dec 2014 18:02:27 +0300 Subject: [9] Review Request: 6470361 Swing's Threading Policy example does not compile In-Reply-To: <548EF2A8.8060307@oracle.com> References: <548AE56F.4020906@oracle.com> <548EF2A8.8060307@oracle.com> Message-ID: <54904983.3000308@oracle.com> Hi, Alexander. On 15.12.2014 17:39, Alexander Zvegintsev wrote: > I think that we should not use lambda expression here. > Someone who skimmed through these samples may not notice a lambda > expression, > and write something like this later: Make sense. An updated version http://cr.openjdk.java.net/~serb/6470361/webrev.01 > > > Thanks, > > Alexander. > On 12/12/2014 03:54 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the small documentation fix for jdk 9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6470361 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/6470361/webrev.00 >> > -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.zvegintsev at oracle.com Tue Dec 16 15:05:26 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 16 Dec 2014 18:05:26 +0300 Subject: [9] Review Request: 6470361 Swing's Threading Policy example does not compile In-Reply-To: <54904983.3000308@oracle.com> References: <548AE56F.4020906@oracle.com> <548EF2A8.8060307@oracle.com> <54904983.3000308@oracle.com> Message-ID: <54904A36.8080702@oracle.com> Hi Sergey, the fix looks good to me. Thanks, Alexander. On 12/16/2014 06:02 PM, Sergey Bylokhov wrote: > Hi, Alexander. > On 15.12.2014 17:39, Alexander Zvegintsev wrote: >> I think that we should not use lambda expression here. >> Someone who skimmed through these samples may not notice a lambda >> expression, >> and write something like this later: > Make sense. An updated version > http://cr.openjdk.java.net/~serb/6470361/webrev.01 >> >> >> Thanks, >> >> Alexander. >> On 12/12/2014 03:54 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the small documentation fix for jdk 9. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6470361 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/6470361/webrev.00 >>> >> > > > -- > Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Wed Dec 17 12:26:05 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 17 Dec 2014 15:26:05 +0300 Subject: [9] Review request for 6219960 null reference in ToolTipManager In-Reply-To: References: <53D65C13.8040600@oracle.com> <53D66034.7080000@oracle.com>, <548ED313.6080001@oracle.com> Message-ID: <5491765D.7000703@oracle.com> On 12/15/2014 9:14 PM, Jason Mehrens wrote: > Alexandr, > > > The fix looks good. The root cause of this error is that mouseExited is not fired on the focused container when a modal dialog is shown. I'm surprised that there isn't a linked issue against AWT to either fix the toolkit to fire the mouseExited (via the Z axis) on modal dialog, suppress the 2nd call to mouseEntered after dialog is closed, or fix the MousListener documentation to state that how the mouse cursor enters or leaves a component has some exceptional conditions. My preference would be to fire mouseExited on modal dialog shown. I have created a separate issue for this: 8067780 mouseExited is not fired on the focused container when a modal dialog is shown https://bugs.openjdk.java.net/browse/JDK-8067780 Thanks, Alexandr. > > > Jason > > > ---------------------------------------- >> Date: Mon, 15 Dec 2014 15:24:51 +0300 >> From: alexandr.scherbatiy at oracle.com >> To: Sergey.Bylokhov at oracle.com >> CC: swing-dev at openjdk.java.net >> Subject: Re: [9] Review request for 6219960 null reference in ToolTipManager >> >> >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/6219960/webrev.01/ >> >> - The test has been added >> >> Thanks, >> Alexandr. >> >> On 7/28/2014 5:37 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> What about the test? I see that it was added to the bug comment. >>> >>> On 7/28/14 6:20 PM, Alexander Scherbatiy wrote: >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-6219960 >>>> webrev: http://cr.openjdk.java.net/~alexsch/6219960/webrev.00 >>>> >>>> >>>> The NPE is fixed. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >> From neugens at redhat.com Fri Dec 19 16:42:56 2014 From: neugens at redhat.com (Mario Torre) Date: Fri, 19 Dec 2014 17:42:56 +0100 Subject: RFD: JEP: Modernize the GTK3 Look and Feel implementation for OpenJDK In-Reply-To: <1417786169.25606.0.camel@nirvana.localdomain> References: <1409155016.25913.6.camel@nirvana.localdomain> <1409220286.25913.8.camel@nirvana.localdomain> <1416583608.22846.43.camel@nirvana.localdomain> <1416584817.22846.49.camel@nirvana.localdomain> <54748C88.6080501@oracle.com> <1416926389.32571.5.camel@nirvana.localdomain> <54749E4F.2020903@oracle.com> <1416929665.32571.7.camel@nirvana.localdomain> <1417090181.32571.27.camel@nirvana.localdomain> <1417786169.25606.0.camel@nirvana.localdomain> Message-ID: <1419007376.4115.9.camel@nirvana.localdomain> On Fri, 2014-12-05 at 14:29 +0100, Mario Torre wrote: > On Thu, 2014-11-27 at 13:09 +0100, Mario Torre wrote: > > On Tue, 2014-11-25 at 16:34 +0100, Mario Torre wrote: > > > On Tue, 2014-11-25 at 18:20 +0300, Sergey Bylokhov wrote: > > > > Hi, Mario. > > > > You are talking about low level using of gtk2/3, I am sure it will be > > > > good if two look&feels will share some code, but I was talking about the > > > > high level, from the users point of view. It can be one LookAndFeel, but > > > > with different implementations(an old one can be dropped easily later): > > > > Note that if it will be different l&f, the user will be able to set one > > > > of them and later the second one. This is resulting in gtk2 getting > > > > loaded into a process having gtk3 already loaded, in this case we can > > > > get errors like this: > > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=431330 > > > > > > Right, I see now what you mean. > > > > > > Indeed, it makes totally sense. I'll amend the JEP with this > > > information. > > > > I updated the JEP with your feedback: > > > > https://bugs.openjdk.java.net/browse/JDK-8065658 > > > > Thanks! > > > > Cheers, > > Mario > > > > Hi all, > > Any more comments on that? > > I would like to move the process forward if possible. > > Thanks! Ping? Cheers, Mario From alexandr.scherbatiy at oracle.com Mon Dec 22 14:53:45 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 22 Dec 2014 17:53:45 +0300 Subject: RFD: JEP: Modernize the GTK3 Look and Feel implementation for OpenJDK In-Reply-To: <1419007376.4115.9.camel@nirvana.localdomain> References: <1409155016.25913.6.camel@nirvana.localdomain> <1409220286.25913.8.camel@nirvana.localdomain> <1416583608.22846.43.camel@nirvana.localdomain> <1416584817.22846.49.camel@nirvana.localdomain> <54748C88.6080501@oracle.com> <1416926389.32571.5.camel@nirvana.localdomain> <54749E4F.2020903@oracle.com> <1416929665.32571.7.camel@nirvana.localdomain> <1417090181.32571.27.camel@nirvana.localdomain> <1417786169.25606.0.camel@nirvana.localdomain> <1419007376.4115.9.camel@nirvana.localdomain> Message-ID: <54983079.3040806@oracle.com> Hi Mario, The JEP has been reviewed. You can move the JEP to the next state according to the http://openjdk.java.net/jeps/1 process. Thanks, Alexandr. On 12/19/2014 7:42 PM, Mario Torre wrote: > On Fri, 2014-12-05 at 14:29 +0100, Mario Torre wrote: >> On Thu, 2014-11-27 at 13:09 +0100, Mario Torre wrote: >>> On Tue, 2014-11-25 at 16:34 +0100, Mario Torre wrote: >>>> On Tue, 2014-11-25 at 18:20 +0300, Sergey Bylokhov wrote: >>>>> Hi, Mario. >>>>> You are talking about low level using of gtk2/3, I am sure it will be >>>>> good if two look&feels will share some code, but I was talking about the >>>>> high level, from the users point of view. It can be one LookAndFeel, but >>>>> with different implementations(an old one can be dropped easily later): >>>>> Note that if it will be different l&f, the user will be able to set one >>>>> of them and later the second one. This is resulting in gtk2 getting >>>>> loaded into a process having gtk3 already loaded, in this case we can >>>>> get errors like this: >>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=431330 >>>> Right, I see now what you mean. >>>> >>>> Indeed, it makes totally sense. I'll amend the JEP with this >>>> information. >>> I updated the JEP with your feedback: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8065658 >>> >>> Thanks! >>> >>> Cheers, >>> Mario >>> >> Hi all, >> >> Any more comments on that? >> >> I would like to move the process forward if possible. >> >> Thanks! > Ping? > > Cheers, > Mario > > From Sergey.Bylokhov at oracle.com Tue Dec 23 19:32:56 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 23 Dec 2014 22:32:56 +0300 Subject: [9] Review Request: 8067657 Dead/outdated links in Javadoc of package java.beans Message-ID: <5499C368.8050802@oracle.com> Hello. Please review the small documentation fix for jdk 9. Bug: https://bugs.openjdk.java.net/browse/JDK-8067657 Webrev can be found at: http://cr.openjdk.java.net/~serb/8067657/webrev.00 -- Best regards, Sergey. From philip.race at oracle.com Tue Dec 23 21:27:53 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 23 Dec 2014 13:27:53 -0800 Subject: [9] Review Request: 8067657 Dead/outdated links in Javadoc of package java.beans In-Reply-To: <5499C368.8050802@oracle.com> References: <5499C368.8050802@oracle.com> Message-ID: <5499DE59.5070400@oracle.com> Looks good to me. Are there other references to these top-level URLs in the doc? I'd like to think we are just doing the same as everyone else. -phil. On 12/23/2014 11:32 AM, Sergey Bylokhov wrote: > Hello. > Please review the small documentation fix for jdk 9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067657 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8067657/webrev.00 > From alexander.zvegintsev at oracle.com Wed Dec 24 10:21:06 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 24 Dec 2014 13:21:06 +0300 Subject: [9] Review Request: 8067657 Dead/outdated links in Javadoc of package java.beans In-Reply-To: <5499C368.8050802@oracle.com> References: <5499C368.8050802@oracle.com> Message-ID: <549A9392.3000803@oracle.com> Hello Sergey, it looks good to me too. Thanks, Alexander. On 12/23/2014 10:32 PM, Sergey Bylokhov wrote: > Hello. > Please review the small documentation fix for jdk 9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067657 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8067657/webrev.00 > From Sergey.Bylokhov at oracle.com Wed Dec 24 10:49:15 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 24 Dec 2014 13:49:15 +0300 Subject: [9] Review Request: 8067657 Dead/outdated links in Javadoc of package java.beans In-Reply-To: <5499DE59.5070400@oracle.com> References: <5499C368.8050802@oracle.com> <5499DE59.5070400@oracle.com> Message-ID: <549A9A2B.60007@oracle.com> On 24.12.2014 0:27, Phil Race wrote: > Looks good to me. Are there other references to these top-level URLs > in the doc? > I'd like to think we are just doing the same as everyone else. I suppose a sqe team validate and fix all such broken links in a packages. I take an opportunity to fix it before the long holidays, because it is not critical bug. > > -phil. > > On 12/23/2014 11:32 AM, Sergey Bylokhov wrote: >> Hello. >> Please review the small documentation fix for jdk 9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067657 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8067657/webrev.00 >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Dec 24 12:57:44 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 24 Dec 2014 15:57:44 +0300 Subject: [9] Review Request: 7180976 Pending String deadlocks UIDefaults Message-ID: <549AB848.3040402@oracle.com> Hello. Please review the fix for jdk 9. In the JDK-6727661 and JDK-6727662 the code : "= new String("Pending")" was changed to = "Pending". This object is used as a marker when we start initialization of LazyValue. "Pending" in the test and "Pending" in the UIDefaults are pointed to the same object, so the loop in UIDefaults.getFromHashtable() will hang. This flag was added in the JDK-4101618 and it does not seem the string type was necessary, so I change it to the simple object, to prevent similar regression in the future Bug: https://bugs.openjdk.java.net/browse/JDK-7180976 Webrev can be found at: http://cr.openjdk.java.net/~serb/7180976/webrev.00 -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Wed Dec 24 13:07:16 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 24 Dec 2014 16:07:16 +0300 Subject: [9] Review Request: 7180976 Pending String deadlocks UIDefaults In-Reply-To: <549AB848.3040402@oracle.com> References: <549AB848.3040402@oracle.com> Message-ID: <549ABA84.7000505@oracle.com> Hi Sergey, the fix looks good to me. Thanks, Alexander. On 12/24/2014 03:57 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > In the JDK-6727661 and JDK-6727662 the code : "= new > String("Pending")" was changed to = "Pending". > This object is used as a marker when we start initialization of > LazyValue. > "Pending" in the test and "Pending" in the UIDefaults are pointed to > the same object, so the loop in UIDefaults.getFromHashtable() will hang. > This flag was added in the JDK-4101618 and it does not seem the string > type was necessary, so I change it to the simple object, to prevent > similar regression in the future > > Bug: https://bugs.openjdk.java.net/browse/JDK-7180976 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7180976/webrev.00 > From alexandr.scherbatiy at oracle.com Wed Dec 24 13:30:27 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 24 Dec 2014 16:30:27 +0300 Subject: [9] Review Request: 7180976 Pending String deadlocks UIDefaults In-Reply-To: <549AB848.3040402@oracle.com> References: <549AB848.3040402@oracle.com> Message-ID: <549ABFF3.4000309@oracle.com> The fix looks good to me. Thanks, Alexandr. On 12/24/2014 3:57 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 9. > In the JDK-6727661 and JDK-6727662 the code : "= new > String("Pending")" was changed to = "Pending". > This object is used as a marker when we start initialization of > LazyValue. > "Pending" in the test and "Pending" in the UIDefaults are pointed to > the same object, so the loop in UIDefaults.getFromHashtable() will hang. > This flag was added in the JDK-4101618 and it does not seem the string > type was necessary, so I change it to the simple object, to prevent > similar regression in the future > > Bug: https://bugs.openjdk.java.net/browse/JDK-7180976 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7180976/webrev.00 > From neugens.limasoftware at gmail.com Sun Dec 28 17:24:18 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sun, 28 Dec 2014 18:24:18 +0100 Subject: RFD: JEP: Modernize the GTK3 Look and Feel implementation for OpenJDK In-Reply-To: <54983079.3040806@oracle.com> References: <1409155016.25913.6.camel@nirvana.localdomain> <1409220286.25913.8.camel@nirvana.localdomain> <1416583608.22846.43.camel@nirvana.localdomain> <1416584817.22846.49.camel@nirvana.localdomain> <54748C88.6080501@oracle.com> <1416926389.32571.5.camel@nirvana.localdomain> <54749E4F.2020903@oracle.com> <1416929665.32571.7.camel@nirvana.localdomain> <1417090181.32571.27.camel@nirvana.localdomain> <1417786169.25606.0.camel@nirvana.localdomain> <1419007376.4115.9.camel@nirvana.localdomain> <54983079.3040806@oracle.com> Message-ID: Hi Alexandr, I'm a bit confused by the process at this stage, the Jira doesn't allow me to edit the status, but the JEP#1 and the JEP 2.0 draft both state that I should be able to do so. Maybe I don't have enough powers to edit this field? Cheers, Mario 2014-12-22 15:53 GMT+01:00 Alexander Scherbatiy : > > Hi Mario, > > The JEP has been reviewed. > > You can move the JEP to the next state according to the > http://openjdk.java.net/jeps/1 process. > > Thanks, > Alexandr. > > > On 12/19/2014 7:42 PM, Mario Torre wrote: >> >> On Fri, 2014-12-05 at 14:29 +0100, Mario Torre wrote: >>> >>> On Thu, 2014-11-27 at 13:09 +0100, Mario Torre wrote: >>>> >>>> On Tue, 2014-11-25 at 16:34 +0100, Mario Torre wrote: >>>>> >>>>> On Tue, 2014-11-25 at 18:20 +0300, Sergey Bylokhov wrote: >>>>>> >>>>>> Hi, Mario. >>>>>> You are talking about low level using of gtk2/3, I am sure it will be >>>>>> good if two look&feels will share some code, but I was talking about >>>>>> the >>>>>> high level, from the users point of view. It can be one LookAndFeel, >>>>>> but >>>>>> with different implementations(an old one can be dropped easily >>>>>> later): >>>>>> Note that if it will be different l&f, the user will be able to set >>>>>> one >>>>>> of them and later the second one. This is resulting in gtk2 getting >>>>>> loaded into a process having gtk3 already loaded, in this case we can >>>>>> get errors like this: >>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=431330 >>>>> >>>>> Right, I see now what you mean. >>>>> >>>>> Indeed, it makes totally sense. I'll amend the JEP with this >>>>> information. >>>> >>>> I updated the JEP with your feedback: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8065658 >>>> >>>> Thanks! >>>> >>>> Cheers, >>>> Mario >>>> >>> Hi all, >>> >>> Any more comments on that? >>> >>> I would like to move the process forward if possible. >>> >>> Thanks! >> >> Ping? >> >> Cheers, >> Mario >> >> > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From shobhit.s.gupta at oracle.com Fri Dec 26 12:33:02 2014 From: shobhit.s.gupta at oracle.com (shobhit gupta) Date: Fri, 26 Dec 2014 18:03:02 +0530 Subject: [8u-dev] Review request for bug 8068301 : [TEST_BUG] Test javax/swing/JColorChooser/Test4177735.java fails with ArrayIndexOutOfBoundsException with GTKL&F Message-ID: <549D557E.1020105@oracle.com> |Hi,| |Please review a fix ||for| |the issue:| 8068301 : [TEST_BUG] Test javax/swing/JColorChooser/Test4177735.java fails with ArrayIndexOutOfBoundsException with GTKL&F |Test bug fix.| |https://bugs.openjdk.java.net/browse/JDK-8068301||| |The webrev is: http://cr.openjdk.java.net/~asmotrak/shobhit/8068301/webrev.00/||| |Thanks & Regards, | |Shobhit Gupta | -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Mon Dec 29 13:41:13 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 29 Dec 2014 16:41:13 +0300 Subject: [8u-dev] Review request for bug 8068301 : [TEST_BUG] Test javax/swing/JColorChooser/Test4177735.java fails with ArrayIndexOutOfBoundsException with GTKL&F In-Reply-To: <549D557E.1020105@oracle.com> References: <549D557E.1020105@oracle.com> Message-ID: <54A159F9.7050203@oracle.com> On 12/26/2014 3:33 PM, shobhit gupta wrote: > |Hi,| > |Please review a fix ||for| |the issue:| > > 8068301 : [TEST_BUG] Test javax/swing/JColorChooser/Test4177735.java > fails with ArrayIndexOutOfBoundsException with GTKL&F > |Test bug fix.| > |https://bugs.openjdk.java.net/browse/JDK-8068301||| > |The webrev is: > http://cr.openjdk.java.net/~asmotrak/shobhit/8068301/webrev.00/| | Could you use the minimum from the first panel and the panels count to allow to test the HSV chooser panel from the original issue with the Metal L&F? Thanks, Alexandr. | > || > |Thanks & Regards, > | > |Shobhit Gupta > | From alexandr.scherbatiy at oracle.com Mon Dec 29 13:57:35 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 29 Dec 2014 16:57:35 +0300 Subject: RFD: JEP: Modernize the GTK3 Look and Feel implementation for OpenJDK In-Reply-To: References: <1409155016.25913.6.camel@nirvana.localdomain> <1409220286.25913.8.camel@nirvana.localdomain> <1416583608.22846.43.camel@nirvana.localdomain> <1416584817.22846.49.camel@nirvana.localdomain> <54748C88.6080501@oracle.com> <1416926389.32571.5.camel@nirvana.localdomain> <54749E4F.2020903@oracle.com> <1416929665.32571.7.camel@nirvana.localdomain> <1417090181.32571.27.camel@nirvana.localdomain> <1417786169.25606.0.camel@nirvana.localdomain> <1419007376.4115.9.camel@nirvana.localdomain> <54983079.3040806@oracle.com> Message-ID: <54A15DCF.4000406@oracle.com> On 12/28/2014 8:24 PM, Mario Torre wrote: > Hi Alexandr, > > I'm a bit confused by the process at this stage, the Jira doesn't > allow me to edit the status, but the JEP#1 and the JEP 2.0 draft both > state that I should be able to do so. > > Maybe I don't have enough powers to edit this field? I think you can ask Mark Reinhold as he is the owner of the JEP process. It is the only contact that I found on the JEP page http://openjdk.java.net/jeps/1 Thanks, Alexandr. > > Cheers, > Mario > > 2014-12-22 15:53 GMT+01:00 Alexander Scherbatiy > : >> Hi Mario, >> >> The JEP has been reviewed. >> >> You can move the JEP to the next state according to the >> http://openjdk.java.net/jeps/1 process. >> >> Thanks, >> Alexandr. >> >> >> On 12/19/2014 7:42 PM, Mario Torre wrote: >>> On Fri, 2014-12-05 at 14:29 +0100, Mario Torre wrote: >>>> On Thu, 2014-11-27 at 13:09 +0100, Mario Torre wrote: >>>>> On Tue, 2014-11-25 at 16:34 +0100, Mario Torre wrote: >>>>>> On Tue, 2014-11-25 at 18:20 +0300, Sergey Bylokhov wrote: >>>>>>> Hi, Mario. >>>>>>> You are talking about low level using of gtk2/3, I am sure it will be >>>>>>> good if two look&feels will share some code, but I was talking about >>>>>>> the >>>>>>> high level, from the users point of view. It can be one LookAndFeel, >>>>>>> but >>>>>>> with different implementations(an old one can be dropped easily >>>>>>> later): >>>>>>> Note that if it will be different l&f, the user will be able to set >>>>>>> one >>>>>>> of them and later the second one. This is resulting in gtk2 getting >>>>>>> loaded into a process having gtk3 already loaded, in this case we can >>>>>>> get errors like this: >>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=431330 >>>>>> Right, I see now what you mean. >>>>>> >>>>>> Indeed, it makes totally sense. I'll amend the JEP with this >>>>>> information. >>>>> I updated the JEP with your feedback: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8065658 >>>>> >>>>> Thanks! >>>>> >>>>> Cheers, >>>>> Mario >>>>> >>>> Hi all, >>>> >>>> Any more comments on that? >>>> >>>> I would like to move the process forward if possible. >>>> >>>> Thanks! >>> Ping? >>> >>> Cheers, >>> Mario >>> >>> > > From neugens.limasoftware at gmail.com Mon Dec 29 14:26:15 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 29 Dec 2014 15:26:15 +0100 Subject: RFD: JEP: Modernize the GTK3 Look and Feel implementation for OpenJDK In-Reply-To: <54A15DCF.4000406@oracle.com> References: <1409155016.25913.6.camel@nirvana.localdomain> <1409220286.25913.8.camel@nirvana.localdomain> <1416583608.22846.43.camel@nirvana.localdomain> <1416584817.22846.49.camel@nirvana.localdomain> <54748C88.6080501@oracle.com> <1416926389.32571.5.camel@nirvana.localdomain> <54749E4F.2020903@oracle.com> <1416929665.32571.7.camel@nirvana.localdomain> <1417090181.32571.27.camel@nirvana.localdomain> <1417786169.25606.0.camel@nirvana.localdomain> <1419007376.4115.9.camel@nirvana.localdomain> <54983079.3040806@oracle.com> <54A15DCF.4000406@oracle.com> Message-ID: 2014-12-29 14:57 GMT+01:00 Alexander Scherbatiy : >> 2014-12-22 15:53 GMT+01:00 Alexander Scherbatiy >> : >>> >>> Hi Mario, >>> >>> The JEP has been reviewed. >>> >>> You can move the JEP to the next state according to the >>> >>> http://openjdk.java.net/jeps/1 process. >>> > On 12/28/2014 8:24 PM, Mario Torre wrote: >> >> Hi Alexandr, >> >> I'm a bit confused by the process at this stage, the Jira doesn't >> allow me to edit the status, but the JEP#1 and the JEP 2.0 draft both >> state that I should be able to do so. >> >> Maybe I don't have enough powers to edit this field? > > > I think you can ask Mark Reinhold as he is the owner of the JEP process. > It is the only contact that I found on the JEP page > http://openjdk.java.net/jeps/1 Hi Alexandr, Thanks for the reply. I added Mark in CC. Mark, can you please help me sort out how to proceed? Maybe it's just a setting I don't see in Jira? Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/