From leonid.romanov at oracle.com Tue Oct 1 15:29:17 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 01 Oct 2013 19:29:17 +0400 Subject: [8] Review request for 8016551: JMenuItem in WindowsLookAndFeel can't paint default icons In-Reply-To: <5242D8F4.2060407@oracle.com> References: <5242041C.6050803@oracle.com> <52420A41.3030506@oracle.com> <2BD73524-B3CF-41E6-9591-1B479EE043A0@oracle.com> <5242D267.3090100@oracle.com> <5242D7E6.2090301@oracle.com> <5242D8F4.2060407@oracle.com> Message-ID: <524AEA4D.40709@oracle.com> Hello, I've modified the test to allow it to run with others l&f. Also, I've added the check for null icon. http://cr.openjdk.java.net/~leonidr/8016551/webrev.01/ On 9/25/2013 16:37, Sergey Bylokhov wrote: > On 25.09.2013 16:32, Leonid Romanov wrote: >> On 9/25/2013 16:09, Sergey Bylokhov wrote: >>> On 25.09.2013 15:49, Leonid Romanov wrote: >>>> I'm not sure whether UIManager.getIcon("InternalFrame.closeIcon") >>>> is guaranteed to return non null with other look&feels. >>> I am not sure it is guaranteed to wl&f as well. I don't see >>> specific to windows code. >> >> com.sun.java.swing.plaf.windows.WindowsLookAndFeel has the following >> line in initComponentDefaults() method: >> "InternalFrame.closeIcon", WindowsIconFactory.createFrameCloseIcon() >> >> So I think we can be sure about wl&f. > The same code exists in aqua, metal etc. But it can be null or can be > changed to null in future. >> >>>> >>>> On Sep 25, 2013, at 1:55 AM, Sergey Bylokhov >>>> wrote: >>>> >>>>> Hi, Leonid. >>>>> Is the test not applicable for default l&f if WindowsLookAndFeel >>>>> is not exists? >>>>> >>>>> On 25.09.2013 1:29, Leonid Romanov wrote: >>>>>> Hello, >>>>>> Please review a one line fix for 8016551: JMenuItem in >>>>>> WindowsLookAndFeel can't paint default icons. I'm not sure >>>>>> whether such a trivial change needs a regression test, but I've >>>>>> written one anyway, just in case. If it's not needed, I won't >>>>>> commit it. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8016551 >>>>>> webrev: http://cr.openjdk.java.net/~leonidr/8016551/webrev.00/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Leonid. >>>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>> >>> >> > > From anthony.petrov at oracle.com Tue Oct 1 18:21:42 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 01 Oct 2013 22:21:42 +0400 Subject: [8] Review request for 8020688: broken links in documentation at http://docs.oracle.com/javase/6/docs/api/index. In-Reply-To: <5245A508.4040707@oracle.com> References: <52433994.1090403@oracle.com> <5243635C.7070007@oracle.com> <52454506.8090500@oracle.com> <52457F15.7090501@oracle.com> <52459263.7040704@oracle.com> <524593EB.2010600@oracle.com> <524596A8.2040700@oracle.com> <5245A508.4040707@oracle.com> Message-ID: <524B12B6.3060803@oracle.com> Hi Mikhail, This "Advanced JList Programming" article seems to vanish, indeed. Although there's a copy at: http://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/tech_topics/jlist_1/jlist.html but generally we shouldn't refer to 3rd-party web-sites from our specification. I briefly looked into the copy, and I think that referring to the Swing tutorial should be just fine as a replacement for this article. -- best regards, Anthony On 09/27/2013 07:32 PM, mikhail cherkasov wrote: > Anthony thank you for this link, it's good replacement for removed link. > > Also I didn't find replacement for : > - * Also see the article href="http://java.sun.com/products/jfc/tsc/tech_topics/jlist_1/jlist.html">Advanced > JList Programming > - * in The Swing > Connection. > > Do you have any suggestion about this link? the link to swing tutorial > already are there: > http://docs.oracle.com/javase/tutorial/uiswing/components/list.html > > Thanks, > Mikhail. > > On 27.09.2013 18:31, Anthony Petrov wrote: >> On 09/27/2013 06:19 PM, mikhail cherkasov wrote: >>> Anthony, some links, like this one, we lost for ever. >> >> How about >> http://docs.oracle.com/javase/tutorial/uiswing/events/actionlistener.html >> ? >> >> >>> On 27.09.2013 18:12, Anthony Petrov wrote: >>>> Thanks. I skimmed through the changes and they look good generally. A >>>> couple of nits: >>>> >>>> src/share/classes/java/awt/event/ActionListener.java >>>>> - * @see >>>> href="http://java.sun.com/docs/books/tutorial/post1.0/ui/eventmodel.html">Tutorial: >>>>> >>>>> Java 1.1 Event Model >>>> >>>> You're only removing the link here. You should add a new one, too, I >>>> guess. >>>> >>>> >>>> src/share/classes/sun/text/normalizer/UCharacter.java >>>>> - * >>>> href="http://java.sun.com/j2se/1.5/docs/api/java/lang/Character.html"> >>>>> + * >>>> href="http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Character.html"> >>>>> >>>>> >>>>> * java.lang.Character class. These extensions provide support >>>>> for >>>> >>>> I believe the here should be replaced with a usual javadoc's >>>> {@link ...} kind of thing. >>> Agree, and this should be done in all places, but this will be too much >>> changes for this fix. >> >> Certainly, we shouldn't change all and every occurrence of this. >> However, this line is updated in your fix anyway, so why not apply the >> correct pattern just for this particular case now? >> >> -- >> best regards, >> Anthony >> >> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 09/27/2013 04:50 PM, mikhail cherkasov wrote: >>>>> Hi Anthony, >>>>> >>>>> Please review a new version: >>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.02/ >>>>> >>>>> I rely on http redirect, but it doesn't always work correctly. Now I >>>>> re-checked all links. >>>>> >>>>> Thanks, >>>>> Mikhail. >>>>> >>>>> On 27.09.2013 12:42, Anthony Petrov wrote: >>>>>> Hi Mikhail, >>>>>> >>>>>> Please comment on the following: >>>>>> >>>>>> src/share/classes/java/awt/Component.java: >>>>>>> - * >>>>>> href="http://java.sun.com/products/jfc/tsc/articles/painting/index.html">Painting >>>>>>> >>>>>>> >>>>>>> in AWT and Swing. >>>>>>> + * >>>>>> href="http://www.oracle.com/technetwork/java/index.html">Painting in >>>>>>> AWT and Swing. >>>>>> >>>>>> The new link doesn't point to the "Painting..." article (and it is a >>>>>> very good article, btw). Could you please check all the new links and >>>>>> update the webrev? >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 09/26/2013 02:27 AM, mikhail cherkasov wrote: >>>>>>> a new webrev: >>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.01/ >>>>>>> >>>>>>> no changes, I've turned off laptop before the webrev upload was >>>>>>> complete, so >>>>>>> the first could be corrupted. >>>>>>> >>>>>>> On 25.09.2013 23:29, mikhail cherkasov wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Could you please review the fix for the following bug: >>>>>>>> 8020688: broken links in documentation at >>>>>>>> http://docs.oracle.com/javase/6/docs/api/index. >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020688 >>>>>>>> The webrev: http://cr.openjdk.java.net/~mcherkas/8020688/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Mikhail. >>>>>>> >>>>> >>> > From mikhail.cherkasov at oracle.com Thu Oct 3 10:33:44 2013 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 03 Oct 2013 14:33:44 +0400 Subject: [8] Review request for 8020688: broken links in documentation at http://docs.oracle.com/javase/6/docs/api/index. In-Reply-To: <524B12B6.3060803@oracle.com> References: <52433994.1090403@oracle.com> <5243635C.7070007@oracle.com> <52454506.8090500@oracle.com> <52457F15.7090501@oracle.com> <52459263.7040704@oracle.com> <524593EB.2010600@oracle.com> <524596A8.2040700@oracle.com> <5245A508.4040707@oracle.com> <524B12B6.3060803@oracle.com> Message-ID: <524D4808.2060901@oracle.com> Hi Anthony, Alexandr, Do you approve the latest version? Thanks, Mikhail. On 01.10.2013 22:21, Anthony Petrov wrote: > Hi Mikhail, > > This "Advanced JList Programming" article seems to vanish, indeed. > Although there's a copy at: > > http://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/tech_topics/jlist_1/jlist.html > > > but generally we shouldn't refer to 3rd-party web-sites from our > specification. I briefly looked into the copy, and I think that > referring to the Swing tutorial should be just fine as a replacement > for this article. > > -- > best regards, > Anthony > > On 09/27/2013 07:32 PM, mikhail cherkasov wrote: >> Anthony thank you for this link, it's good replacement for removed link. >> >> Also I didn't find replacement for : >> - * Also see the article > href="http://java.sun.com/products/jfc/tsc/tech_topics/jlist_1/jlist.html">Advanced >> >> JList Programming >> - * in The Swing >> Connection. >> >> Do you have any suggestion about this link? the link to swing tutorial >> already are there: >> http://docs.oracle.com/javase/tutorial/uiswing/components/list.html >> >> Thanks, >> Mikhail. >> >> On 27.09.2013 18:31, Anthony Petrov wrote: >>> On 09/27/2013 06:19 PM, mikhail cherkasov wrote: >>>> Anthony, some links, like this one, we lost for ever. >>> >>> How about >>> http://docs.oracle.com/javase/tutorial/uiswing/events/actionlistener.html >>> >>> ? >>> >>> >>>> On 27.09.2013 18:12, Anthony Petrov wrote: >>>>> Thanks. I skimmed through the changes and they look good generally. A >>>>> couple of nits: >>>>> >>>>> src/share/classes/java/awt/event/ActionListener.java >>>>>> - * @see >>>>> href="http://java.sun.com/docs/books/tutorial/post1.0/ui/eventmodel.html">Tutorial: >>>>>> >>>>>> >>>>>> Java 1.1 Event Model >>>>> >>>>> You're only removing the link here. You should add a new one, too, I >>>>> guess. >>>>> >>>>> >>>>> src/share/classes/sun/text/normalizer/UCharacter.java >>>>>> - * >>>>> href="http://java.sun.com/j2se/1.5/docs/api/java/lang/Character.html"> >>>>>> >>>>>> + * >>>>> href="http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Character.html"> >>>>>> >>>>>> >>>>>> >>>>>> * java.lang.Character class. These extensions provide support >>>>>> for >>>>> >>>>> I believe the here should be replaced with a usual javadoc's >>>>> {@link ...} kind of thing. >>>> Agree, and this should be done in all places, but this will be too >>>> much >>>> changes for this fix. >>> >>> Certainly, we shouldn't change all and every occurrence of this. >>> However, this line is updated in your fix anyway, so why not apply the >>> correct pattern just for this particular case now? >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 09/27/2013 04:50 PM, mikhail cherkasov wrote: >>>>>> Hi Anthony, >>>>>> >>>>>> Please review a new version: >>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.02/ >>>>>> >>>>>> I rely on http redirect, but it doesn't always work correctly. Now I >>>>>> re-checked all links. >>>>>> >>>>>> Thanks, >>>>>> Mikhail. >>>>>> >>>>>> On 27.09.2013 12:42, Anthony Petrov wrote: >>>>>>> Hi Mikhail, >>>>>>> >>>>>>> Please comment on the following: >>>>>>> >>>>>>> src/share/classes/java/awt/Component.java: >>>>>>>> - * >>>>>>> href="http://java.sun.com/products/jfc/tsc/articles/painting/index.html">Painting >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> in AWT and Swing. >>>>>>>> + * >>>>>>> href="http://www.oracle.com/technetwork/java/index.html">Painting >>>>>>>> in >>>>>>>> AWT and Swing. >>>>>>> >>>>>>> The new link doesn't point to the "Painting..." article (and it >>>>>>> is a >>>>>>> very good article, btw). Could you please check all the new >>>>>>> links and >>>>>>> update the webrev? >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 09/26/2013 02:27 AM, mikhail cherkasov wrote: >>>>>>>> a new webrev: >>>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.01/ >>>>>>>> >>>>>>>> no changes, I've turned off laptop before the webrev upload was >>>>>>>> complete, so >>>>>>>> the first could be corrupted. >>>>>>>> >>>>>>>> On 25.09.2013 23:29, mikhail cherkasov wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Could you please review the fix for the following bug: >>>>>>>>> 8020688: broken links in documentation at >>>>>>>>> http://docs.oracle.com/javase/6/docs/api/index. >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020688 >>>>>>>>> The webrev: >>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Mikhail. >>>>>>>> >>>>>> >>>> >> From anthony.petrov at oracle.com Fri Oct 4 08:18:46 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 Oct 2013 12:18:46 +0400 Subject: [8] Review request for 8020688: broken links in documentation at http://docs.oracle.com/javase/6/docs/api/index. In-Reply-To: <524D4808.2060901@oracle.com> References: <52433994.1090403@oracle.com> <5243635C.7070007@oracle.com> <52454506.8090500@oracle.com> <52457F15.7090501@oracle.com> <52459263.7040704@oracle.com> <524593EB.2010600@oracle.com> <524596A8.2040700@oracle.com> <5245A508.4040707@oracle.com> <524B12B6.3060803@oracle.com> <524D4808.2060901@oracle.com> Message-ID: <524E79E6.7090701@oracle.com> Hi Mikhail, Yes, the latest version looks good to me. -- best regards, Anthony On 10/03/2013 02:33 PM, mikhail cherkasov wrote: > Hi Anthony, Alexandr, > > Do you approve the latest version? > > Thanks, > Mikhail. > > On 01.10.2013 22:21, Anthony Petrov wrote: >> Hi Mikhail, >> >> This "Advanced JList Programming" article seems to vanish, indeed. >> Although there's a copy at: >> >> http://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/tech_topics/jlist_1/jlist.html >> >> >> but generally we shouldn't refer to 3rd-party web-sites from our >> specification. I briefly looked into the copy, and I think that >> referring to the Swing tutorial should be just fine as a replacement >> for this article. >> >> -- >> best regards, >> Anthony >> >> On 09/27/2013 07:32 PM, mikhail cherkasov wrote: >>> Anthony thank you for this link, it's good replacement for removed link. >>> >>> Also I didn't find replacement for : >>> - * Also see the article >> href="http://java.sun.com/products/jfc/tsc/tech_topics/jlist_1/jlist.html">Advanced >>> >>> JList Programming >>> - * in The Swing >>> Connection. >>> >>> Do you have any suggestion about this link? the link to swing tutorial >>> already are there: >>> http://docs.oracle.com/javase/tutorial/uiswing/components/list.html >>> >>> Thanks, >>> Mikhail. >>> >>> On 27.09.2013 18:31, Anthony Petrov wrote: >>>> On 09/27/2013 06:19 PM, mikhail cherkasov wrote: >>>>> Anthony, some links, like this one, we lost for ever. >>>> >>>> How about >>>> http://docs.oracle.com/javase/tutorial/uiswing/events/actionlistener.html >>>> >>>> ? >>>> >>>> >>>>> On 27.09.2013 18:12, Anthony Petrov wrote: >>>>>> Thanks. I skimmed through the changes and they look good generally. A >>>>>> couple of nits: >>>>>> >>>>>> src/share/classes/java/awt/event/ActionListener.java >>>>>>> - * @see >>>>>> href="http://java.sun.com/docs/books/tutorial/post1.0/ui/eventmodel.html">Tutorial: >>>>>>> >>>>>>> >>>>>>> Java 1.1 Event Model >>>>>> >>>>>> You're only removing the link here. You should add a new one, too, I >>>>>> guess. >>>>>> >>>>>> >>>>>> src/share/classes/sun/text/normalizer/UCharacter.java >>>>>>> - * >>>>>> href="http://java.sun.com/j2se/1.5/docs/api/java/lang/Character.html"> >>>>>>> >>>>>>> + * >>>>>> href="http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Character.html"> >>>>>>> >>>>>>> >>>>>>> >>>>>>> * java.lang.Character class. These extensions provide support >>>>>>> for >>>>>> >>>>>> I believe the here should be replaced with a usual javadoc's >>>>>> {@link ...} kind of thing. >>>>> Agree, and this should be done in all places, but this will be too >>>>> much >>>>> changes for this fix. >>>> >>>> Certainly, we shouldn't change all and every occurrence of this. >>>> However, this line is updated in your fix anyway, so why not apply the >>>> correct pattern just for this particular case now? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 09/27/2013 04:50 PM, mikhail cherkasov wrote: >>>>>>> Hi Anthony, >>>>>>> >>>>>>> Please review a new version: >>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.02/ >>>>>>> >>>>>>> I rely on http redirect, but it doesn't always work correctly. Now I >>>>>>> re-checked all links. >>>>>>> >>>>>>> Thanks, >>>>>>> Mikhail. >>>>>>> >>>>>>> On 27.09.2013 12:42, Anthony Petrov wrote: >>>>>>>> Hi Mikhail, >>>>>>>> >>>>>>>> Please comment on the following: >>>>>>>> >>>>>>>> src/share/classes/java/awt/Component.java: >>>>>>>>> - * >>>>>>>> href="http://java.sun.com/products/jfc/tsc/articles/painting/index.html">Painting >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> in AWT and Swing. >>>>>>>>> + * >>>>>>>> href="http://www.oracle.com/technetwork/java/index.html">Painting >>>>>>>>> in >>>>>>>>> AWT and Swing. >>>>>>>> >>>>>>>> The new link doesn't point to the "Painting..." article (and it >>>>>>>> is a >>>>>>>> very good article, btw). Could you please check all the new >>>>>>>> links and >>>>>>>> update the webrev? >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 09/26/2013 02:27 AM, mikhail cherkasov wrote: >>>>>>>>> a new webrev: >>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.01/ >>>>>>>>> >>>>>>>>> no changes, I've turned off laptop before the webrev upload was >>>>>>>>> complete, so >>>>>>>>> the first could be corrupted. >>>>>>>>> >>>>>>>>> On 25.09.2013 23:29, mikhail cherkasov wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Could you please review the fix for the following bug: >>>>>>>>>> 8020688: broken links in documentation at >>>>>>>>>> http://docs.oracle.com/javase/6/docs/api/index. >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020688 >>>>>>>>>> The webrev: >>>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Mikhail. >>>>>>>>> >>>>>>> >>>>> >>> > From alexandr.scherbatiy at oracle.com Fri Oct 4 16:03:24 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 04 Oct 2013 20:03:24 +0400 Subject: [8] Review request for 8020688: broken links in documentation at http://docs.oracle.com/javase/6/docs/api/index. In-Reply-To: <524D4808.2060901@oracle.com> References: <52433994.1090403@oracle.com> <5243635C.7070007@oracle.com> <52454506.8090500@oracle.com> <52457F15.7090501@oracle.com> <52459263.7040704@oracle.com> <524593EB.2010600@oracle.com> <524596A8.2040700@oracle.com> <5245A508.4040707@oracle.com> <524B12B6.3060803@oracle.com> <524D4808.2060901@oracle.com> Message-ID: <524EE6CC.5050701@oracle.com> The fix looks good for me. Thanks, Alexandr. On 10/3/2013 2:33 PM, mikhail cherkasov wrote: > Hi Anthony, Alexandr, > > Do you approve the latest version? > > Thanks, > Mikhail. > > On 01.10.2013 22:21, Anthony Petrov wrote: >> Hi Mikhail, >> >> This "Advanced JList Programming" article seems to vanish, indeed. >> Although there's a copy at: >> >> http://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/tech_topics/jlist_1/jlist.html >> >> >> but generally we shouldn't refer to 3rd-party web-sites from our >> specification. I briefly looked into the copy, and I think that >> referring to the Swing tutorial should be just fine as a replacement >> for this article. >> >> -- >> best regards, >> Anthony >> >> On 09/27/2013 07:32 PM, mikhail cherkasov wrote: >>> Anthony thank you for this link, it's good replacement for removed >>> link. >>> >>> Also I didn't find replacement for : >>> - * Also see the article >> href="http://java.sun.com/products/jfc/tsc/tech_topics/jlist_1/jlist.html">Advanced >>> >>> JList Programming >>> - * in The Swing >>> Connection. >>> >>> Do you have any suggestion about this link? the link to swing tutorial >>> already are there: >>> http://docs.oracle.com/javase/tutorial/uiswing/components/list.html >>> >>> Thanks, >>> Mikhail. >>> >>> On 27.09.2013 18:31, Anthony Petrov wrote: >>>> On 09/27/2013 06:19 PM, mikhail cherkasov wrote: >>>>> Anthony, some links, like this one, we lost for ever. >>>> >>>> How about >>>> http://docs.oracle.com/javase/tutorial/uiswing/events/actionlistener.html >>>> >>>> ? >>>> >>>> >>>>> On 27.09.2013 18:12, Anthony Petrov wrote: >>>>>> Thanks. I skimmed through the changes and they look good >>>>>> generally. A >>>>>> couple of nits: >>>>>> >>>>>> src/share/classes/java/awt/event/ActionListener.java >>>>>>> - * @see >>>>>> href="http://java.sun.com/docs/books/tutorial/post1.0/ui/eventmodel.html">Tutorial: >>>>>>> >>>>>>> >>>>>>> Java 1.1 Event Model >>>>>> >>>>>> You're only removing the link here. You should add a new one, too, I >>>>>> guess. >>>>>> >>>>>> >>>>>> src/share/classes/sun/text/normalizer/UCharacter.java >>>>>>> - * >>>>>> href="http://java.sun.com/j2se/1.5/docs/api/java/lang/Character.html"> >>>>>>> >>>>>>> + * >>>>>> href="http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Character.html"> >>>>>>> >>>>>>> >>>>>>> >>>>>>> * java.lang.Character class. These extensions provide support >>>>>>> for >>>>>> >>>>>> I believe the here should be replaced with a usual javadoc's >>>>>> {@link ...} kind of thing. >>>>> Agree, and this should be done in all places, but this will be too >>>>> much >>>>> changes for this fix. >>>> >>>> Certainly, we shouldn't change all and every occurrence of this. >>>> However, this line is updated in your fix anyway, so why not apply the >>>> correct pattern just for this particular case now? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 09/27/2013 04:50 PM, mikhail cherkasov wrote: >>>>>>> Hi Anthony, >>>>>>> >>>>>>> Please review a new version: >>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.02/ >>>>>>> >>>>>>> I rely on http redirect, but it doesn't always work correctly. >>>>>>> Now I >>>>>>> re-checked all links. >>>>>>> >>>>>>> Thanks, >>>>>>> Mikhail. >>>>>>> >>>>>>> On 27.09.2013 12:42, Anthony Petrov wrote: >>>>>>>> Hi Mikhail, >>>>>>>> >>>>>>>> Please comment on the following: >>>>>>>> >>>>>>>> src/share/classes/java/awt/Component.java: >>>>>>>>> - * >>>>>>>> href="http://java.sun.com/products/jfc/tsc/articles/painting/index.html">Painting >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> in AWT and Swing. >>>>>>>>> + * >>>>>>>> href="http://www.oracle.com/technetwork/java/index.html">Painting >>>>>>>>> in >>>>>>>>> AWT and Swing. >>>>>>>> >>>>>>>> The new link doesn't point to the "Painting..." article (and it >>>>>>>> is a >>>>>>>> very good article, btw). Could you please check all the new >>>>>>>> links and >>>>>>>> update the webrev? >>>>>>>> >>>>>>>> -- >>>>>>>> best regards, >>>>>>>> Anthony >>>>>>>> >>>>>>>> On 09/26/2013 02:27 AM, mikhail cherkasov wrote: >>>>>>>>> a new webrev: >>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.01/ >>>>>>>>> >>>>>>>>> no changes, I've turned off laptop before the webrev upload was >>>>>>>>> complete, so >>>>>>>>> the first could be corrupted. >>>>>>>>> >>>>>>>>> On 25.09.2013 23:29, mikhail cherkasov wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Could you please review the fix for the following bug: >>>>>>>>>> 8020688: broken links in documentation at >>>>>>>>>> http://docs.oracle.com/javase/6/docs/api/index. >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8020688 >>>>>>>>>> The webrev: >>>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8020688/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Mikhail. >>>>>>>>> >>>>>>> >>>>> >>> > From alexandr.scherbatiy at oracle.com Tue Oct 8 10:57:37 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 08 Oct 2013 14:57:37 +0400 Subject: [8] Review request for 8005391 Floating behavior of HTMLEditorKit parser Message-ID: <5253E521.5090202@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8005391 webrev: http://cr.openjdk.java.net/~alexsch/8005391/webrev.00 The test in the webrev fails because SimpleAttributeSet returns attribute names as Hashtable keys which order is not preserved. So the tags are also generated in the random order. The suggested fix uses LinkedHashMap instead of Hashtable which guarantee predictable iteration order. The LinkedHashMap implementation is not synchronized as it is done for the Hashtable. However, the SimpleAttributeSet is designed to use on EDT like others swing classes. Thanks, Alexandr. From anton.nashatyrev at oracle.com Tue Oct 8 12:46:43 2013 From: anton.nashatyrev at oracle.com (anton nashatyrev) Date: Tue, 08 Oct 2013 16:46:43 +0400 Subject: [8] Review request for 8024932: [TEST_BUG] [macosx] javax/swing/text/StyledEditorKit/8016833/bug8016833.java failed In-Reply-To: <524422CB.2060507@oracle.com> References: <5241B530.9090102@oracle.com> <524422CB.2060507@oracle.com> Message-ID: <5253FEB3.806@oracle.com> Hello, could please anyone else review the fix? Thanks! Anton. On 26.09.2013 16:04, Alexander Scherbatiy wrote: > > > The fix looks good for me. > > Thanks, > Alexandr. > > > On 9/24/2013 7:52 PM, anton nashatyrev wrote: >> Hello, >> could you please review the following fix for regression test: >> >> fix: http://cr.openjdk.java.net/~mcherkas/anton/8024932/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8024932 >> >> It is still acceptable for the underline to be drawn right below >> the advance line without any blank space. >> >> Thanks! >> Anton. > From sergey.malenkov at oracle.com Tue Oct 8 15:18:26 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Tue, 08 Oct 2013 19:18:26 +0400 Subject: Approved: [8] Review request for 8005391 Floating behavior of HTMLEditorKit parser In-Reply-To: <5253E521.5090202@oracle.com> References: <5253E521.5090202@oracle.com> Message-ID: <52542242.8060706@oracle.com> The fix looks good. Thanks, SAM On 08.10.2013 14:57, Alexander Scherbatiy wrote: > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8005391 > webrev: http://cr.openjdk.java.net/~alexsch/8005391/webrev.00 > > The test in the webrev fails because SimpleAttributeSet returns > attribute names as Hashtable keys which order is not preserved. > So the tags are also generated in the random order. > > The suggested fix uses LinkedHashMap instead of Hashtable which > guarantee predictable iteration order. > > The LinkedHashMap implementation is not synchronized as it is done for > the Hashtable. > However, the SimpleAttributeSet is designed to use on EDT like others > swing classes. > > Thanks, > Alexandr. > From artem.ananiev at oracle.com Wed Oct 9 11:35:57 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 09 Oct 2013 15:35:57 +0400 Subject: javax.swing.RepaintManager volatileMap In-Reply-To: <521E00B0.5080205@oracle.com> References: <521E00B0.5080205@oracle.com> Message-ID: <52553F9D.6010400@oracle.com> Hi, Vladimir, have you received this reply, or it was lost for some reason? Thanks, Artem On 8/28/2013 5:52 PM, Artem Ananiev wrote: > Hi, Vladimir, > > I agree that using a class with no equals/hashCode overridden as a key > for HashMap is not the best thing to do. However, in this case the > problem seems to be caused by something else. > > I'm not an expert in RepaintManager, but here is what I observe: > > 1. When graphics environment changes, we get displayChanged() > notification (it's not a public API yet, unfortunately). > > 2. RepaintManager.displayChanged() clears all the volatile images, as > they depend on the GraphicsConfiguration objects and may be invalid > > 3. In clearImages(), we iterate through volatileMap and remove the > images. Note that despite GraphicsConfiguration doesn't override > equals/hashCode, iteration should still work. > > Anyway, it indeed looks like a bug, no matter of what it's caused by. Do > you have a test case that can be used to reproduce it, other than to run > JDeveloper? > > Thanks, > > Artem > > On 8/28/2013 3:00 PM, Vladimir Sitnikov wrote: >> Hi, >> >> In the heapdump of SQL Developer 4.0 I found that RepaintManager holds >> 23 items of sun.awt.image.BufImgVolatileSurfaceManager 5-10MiB each. >> >> All the images are contained in "volatileMap" HashMap. >> >> I identified that the key of the map is sun.awt.Win32GraphicsConfig and >> that class does not override equals/hashCode. >> >> Can you please tell me if "using GraphicsConfig as a key knowing the >> fact this key does not ovveride equals/hashCode" is intentional or not? >> >> I have checked several keys of the map (Win32GraphicsConfig) and they >> have identical value (even screen and sTypeOrig references point to the >> same objects), however as the Win32GraphicsConfig objects itself are >> different java objects they occupy different entries in valueMap. >> >> -- >> Regards, >> Vladimir Sitnikov From leonid.romanov at oracle.com Wed Oct 9 13:57:40 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 9 Oct 2013 17:57:40 +0400 Subject: [8] Review request for 8016551: JMenuItem in WindowsLookAndFeel can't paint default icons In-Reply-To: <524AEA4D.40709@oracle.com> References: <5242041C.6050803@oracle.com> <52420A41.3030506@oracle.com> <2BD73524-B3CF-41E6-9591-1B479EE043A0@oracle.com> <5242D267.3090100@oracle.com> <5242D7E6.2090301@oracle.com> <5242D8F4.2060407@oracle.com> <524AEA4D.40709@oracle.com> Message-ID: <36DEA9AC-AC3F-4972-AA72-3BD0D34EC16F@oracle.com> Guys, could you please take a look at this simple one-line fix? One more reviewer is needed. Thanks, Leonid. On Oct 1, 2013, at 7:29 PM, Leonid Romanov wrote: > Hello, > I've modified the test to allow it to run with others l&f. Also, I've added the check for null icon. > > http://cr.openjdk.java.net/~leonidr/8016551/webrev.01/ > > > On 9/25/2013 16:37, Sergey Bylokhov wrote: >> On 25.09.2013 16:32, Leonid Romanov wrote: >>> On 9/25/2013 16:09, Sergey Bylokhov wrote: >>>> On 25.09.2013 15:49, Leonid Romanov wrote: >>>>> I'm not sure whether UIManager.getIcon("InternalFrame.closeIcon") is guaranteed to return non null with other look&feels. >>>> I am not sure it is guaranteed to wl&f as well. I don't see specific to windows code. >>> >>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel has the following line in initComponentDefaults() method: >>> "InternalFrame.closeIcon", WindowsIconFactory.createFrameCloseIcon() >>> >>> So I think we can be sure about wl&f. >> The same code exists in aqua, metal etc. But it can be null or can be changed to null in future. >>> >>>>> >>>>> On Sep 25, 2013, at 1:55 AM, Sergey Bylokhov wrote: >>>>> >>>>>> Hi, Leonid. >>>>>> Is the test not applicable for default l&f if WindowsLookAndFeel is not exists? >>>>>> >>>>>> On 25.09.2013 1:29, Leonid Romanov wrote: >>>>>>> Hello, >>>>>>> Please review a one line fix for 8016551: JMenuItem in WindowsLookAndFeel can't paint default icons. I'm not sure whether such a trivial change needs a regression test, but I've written one anyway, just in case. If it's not needed, I won't commit it. >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8016551 >>>>>>> webrev: http://cr.openjdk.java.net/~leonidr/8016551/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Leonid. >>>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>> >>>> >>> >> >> > From alexandr.scherbatiy at oracle.com Wed Oct 9 14:03:05 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 09 Oct 2013 18:03:05 +0400 Subject: [8] Review request for 8016551: JMenuItem in WindowsLookAndFeel can't paint default icons In-Reply-To: <36DEA9AC-AC3F-4972-AA72-3BD0D34EC16F@oracle.com> References: <5242041C.6050803@oracle.com> <52420A41.3030506@oracle.com> <2BD73524-B3CF-41E6-9591-1B479EE043A0@oracle.com> <5242D267.3090100@oracle.com> <5242D7E6.2090301@oracle.com> <5242D8F4.2060407@oracle.com> <524AEA4D.40709@oracle.com> <36DEA9AC-AC3F-4972-AA72-3BD0D34EC16F@oracle.com> Message-ID: <52556219.2060209@oracle.com> The fix looks good for me. Thanks, Alexandr. On 10/9/2013 5:57 PM, Leonid Romanov wrote: > Guys, could you please take a look at this simple one-line fix? One more reviewer is needed. > > Thanks, > Leonid. > > > On Oct 1, 2013, at 7:29 PM, Leonid Romanov wrote: > >> Hello, >> I've modified the test to allow it to run with others l&f. Also, I've added the check for null icon. >> >> http://cr.openjdk.java.net/~leonidr/8016551/webrev.01/ >> >> >> On 9/25/2013 16:37, Sergey Bylokhov wrote: >>> On 25.09.2013 16:32, Leonid Romanov wrote: >>>> On 9/25/2013 16:09, Sergey Bylokhov wrote: >>>>> On 25.09.2013 15:49, Leonid Romanov wrote: >>>>>> I'm not sure whether UIManager.getIcon("InternalFrame.closeIcon") is guaranteed to return non null with other look&feels. >>>>> I am not sure it is guaranteed to wl&f as well. I don't see specific to windows code. >>>> com.sun.java.swing.plaf.windows.WindowsLookAndFeel has the following line in initComponentDefaults() method: >>>> "InternalFrame.closeIcon", WindowsIconFactory.createFrameCloseIcon() >>>> >>>> So I think we can be sure about wl&f. >>> The same code exists in aqua, metal etc. But it can be null or can be changed to null in future. >>>>>> On Sep 25, 2013, at 1:55 AM, Sergey Bylokhov wrote: >>>>>> >>>>>>> Hi, Leonid. >>>>>>> Is the test not applicable for default l&f if WindowsLookAndFeel is not exists? >>>>>>> >>>>>>> On 25.09.2013 1:29, Leonid Romanov wrote: >>>>>>>> Hello, >>>>>>>> Please review a one line fix for 8016551: JMenuItem in WindowsLookAndFeel can't paint default icons. I'm not sure whether such a trivial change needs a regression test, but I've written one anyway, just in case. If it's not needed, I won't commit it. >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8016551 >>>>>>>> webrev: http://cr.openjdk.java.net/~leonidr/8016551/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Leonid. >>>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>> >>> From leonid.romanov at oracle.com Thu Oct 10 11:19:09 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 10 Oct 2013 15:19:09 +0400 Subject: [8] Review request for 8005391 Floating behavior of HTMLEditorKit parser In-Reply-To: <5253E521.5090202@oracle.com> References: <5253E521.5090202@oracle.com> Message-ID: Looks good to me. Leonid. On 08.10.2013, at 14:57, Alexander Scherbatiy wrote: > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8005391 > webrev: http://cr.openjdk.java.net/~alexsch/8005391/webrev.00 > > The test in the webrev fails because SimpleAttributeSet returns attribute names as Hashtable keys which order is not preserved. > So the tags are also generated in the random order. > > The suggested fix uses LinkedHashMap instead of Hashtable which guarantee predictable iteration order. > > The LinkedHashMap implementation is not synchronized as it is done for the Hashtable. > However, the SimpleAttributeSet is designed to use on EDT like others swing classes. > > Thanks, > Alexandr. > From alexandr.scherbatiy at oracle.com Thu Oct 10 15:00:40 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 10 Oct 2013 19:00:40 +0400 Subject: [8] Review request for 8020708 NLS: mnemonics missing in SwingSet2/JInternalFrame demo Message-ID: <5256C118.8030002@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8020708 webrev: http://cr.openjdk.java.net/~alexsch/8020708/webrev.00 The fix updates mnemonics for the InternalFrameTitlePane.*Button properties - Mnemonics are loaded from the *.properties files - (&Mnemonic) is added for the localized text that does not contains the mnemonics char Thanks, Alexandr. From leonid.romanov at oracle.com Thu Oct 10 19:12:43 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 10 Oct 2013 23:12:43 +0400 Subject: [8] Review request for 8020708 NLS: mnemonics missing in SwingSet2/JInternalFrame demo In-Reply-To: <5256C118.8030002@oracle.com> References: <5256C118.8030002@oracle.com> Message-ID: Hello, Who is the author of localized properties changes? Is it you or someone from i18n team? On Oct 10, 2013, at 7:00 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8020708 > webrev: http://cr.openjdk.java.net/~alexsch/8020708/webrev.00 > > The fix updates mnemonics for the InternalFrameTitlePane.*Button properties > - Mnemonics are loaded from the *.properties files > - (&Mnemonic) is added for the localized text that does not contains the mnemonics char > > > Thanks, > Alexandr. > From sergey.malenkov at oracle.com Fri Oct 11 08:35:07 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Fri, 11 Oct 2013 12:35:07 +0400 Subject: [8] Review request for 7165112: Incomprehensible garbage in doc for RootPaneContainer Message-ID: <5257B83B.2080906@oracle.com> Hello, Could you please review the following fix: fix:http://cr.openjdk.java.net/~malenkov/7165112.8.0/ bug:https://bugs.openjdk.java.net/browse/JDK-7165112 The javadoc partially rewritten. Thanks, SAM From sergey.malenkov at oracle.com Fri Oct 11 08:49:52 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Fri, 11 Oct 2013 12:49:52 +0400 Subject: [8] Review request for 7016396: (spec) JCK test mentioned in 6735293 is still failing Message-ID: <5257BBB0.1000102@oracle.com> Hello, Could you please review the following fix: fix:http://cr.openjdk.java.net/~malenkov/7016396.8.0/ bug:https://bugs.openjdk.java.net/browse/JDK-7016396 The javadoc fixed. Added missing range checks. Thanks, SAM From alexandr.scherbatiy at oracle.com Fri Oct 11 10:34:41 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 11 Oct 2013 14:34:41 +0400 Subject: [8] Review request for 8020708 NLS: mnemonics missing in SwingSet2/JInternalFrame demo In-Reply-To: References: <5256C118.8030002@oracle.com> Message-ID: <5257D441.5010603@oracle.com> On 10/10/2013 11:12 PM, Leonid Romanov wrote: > Hello, > Who is the author of localized properties changes? Is it you or someone from i18n team? I have updated the localized InternalFrameTitlePane properties. Only mnemonics have been updated. It is done in the same way as for other properties like: basic.properties: ColorChooser.rgbRed.textAndMnemonic=Re&d basic_zh_TW.properties: ColorChooser.rgbRed.textAndMnemonic=\u7D05(&D) This is the standard procedure to include mnemonics into properties by & sign. So name=A&BC property means that the value is ABC and the mnemonic is B. If a value does not contain a mnemonic char it needs to be added at the end like name=ABC(&D) Thanks, Alexandr. > > On Oct 10, 2013, at 7:00 PM, Alexander Scherbatiy wrote: > >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8020708 >> webrev: http://cr.openjdk.java.net/~alexsch/8020708/webrev.00 >> >> The fix updates mnemonics for the InternalFrameTitlePane.*Button properties >> - Mnemonics are loaded from the *.properties files >> - (&Mnemonic) is added for the localized text that does not contains the mnemonics char >> >> >> Thanks, >> Alexandr. >> From alexandr.scherbatiy at oracle.com Fri Oct 11 10:36:30 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 11 Oct 2013 14:36:30 +0400 Subject: [8] Review request for 7165112: Incomprehensible garbage in doc for RootPaneContainer In-Reply-To: <5257B83B.2080906@oracle.com> References: <5257B83B.2080906@oracle.com> Message-ID: <5257D4AE.7060000@oracle.com> The fix looks good for me. Thanks, Alexandr. On 10/11/2013 12:35 PM, sergey malenkov wrote: > Hello, > > Could you please review the following fix: > fix:http://cr.openjdk.java.net/~malenkov/7165112.8.0/ > > bug:https://bugs.openjdk.java.net/browse/JDK-7165112 > > The javadoc partially rewritten. > > Thanks, > SAM > From alexandr.scherbatiy at oracle.com Fri Oct 11 10:37:46 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 11 Oct 2013 14:37:46 +0400 Subject: [8] Review request for 7016396: (spec) JCK test mentioned in 6735293 is still failing In-Reply-To: <5257BBB0.1000102@oracle.com> References: <5257BBB0.1000102@oracle.com> Message-ID: <5257D4FA.4030205@oracle.com> The fix looks good for me. Thanks, Alexandr. On 10/11/2013 12:49 PM, sergey malenkov wrote: > Hello, > > Could you please review the following fix: > fix:http://cr.openjdk.java.net/~malenkov/7016396.8.0/ > > bug:https://bugs.openjdk.java.net/browse/JDK-7016396 > > The javadoc fixed. Added missing range checks. > > Thanks, > SAM From sergey.malenkov at oracle.com Fri Oct 11 10:46:59 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Fri, 11 Oct 2013 14:46:59 +0400 Subject: Approved: [8] Review request for 8020708 NLS: mnemonics missing in SwingSet2/JInternalFrame demo In-Reply-To: <5257D441.5010603@oracle.com> References: <5256C118.8030002@oracle.com> <5257D441.5010603@oracle.com> Message-ID: <5257D723.4000809@oracle.com> The fix looks good to me. SAM On 11.10.2013 14:34, Alexander Scherbatiy wrote: > On 10/10/2013 11:12 PM, Leonid Romanov wrote: >> Hello, >> Who is the author of localized properties changes? Is it you or >> someone from i18n team? > > I have updated the localized InternalFrameTitlePane properties. > Only mnemonics have been updated. > It is done in the same way as for other properties like: > basic.properties: ColorChooser.rgbRed.textAndMnemonic=Re&d > basic_zh_TW.properties: > ColorChooser.rgbRed.textAndMnemonic=\u7D05(&D) > > This is the standard procedure to include mnemonics into properties > by & sign. > So name=A&BC property means that the value is ABC and the mnemonic > is B. > If a value does not contain a mnemonic char it needs to be added at > the end like name=ABC(&D) > > Thanks, > Alexandr. > >> >> On Oct 10, 2013, at 7:00 PM, Alexander Scherbatiy >> wrote: >> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8020708 >>> webrev: http://cr.openjdk.java.net/~alexsch/8020708/webrev.00 >>> >>> The fix updates mnemonics for the InternalFrameTitlePane.*Button >>> properties >>> - Mnemonics are loaded from the *.properties files >>> - (&Mnemonic) is added for the localized text that does not >>> contains the mnemonics char >>> >>> >>> Thanks, >>> Alexandr. >>> > From leonid.romanov at oracle.com Fri Oct 11 14:08:54 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 11 Oct 2013 18:08:54 +0400 Subject: [8] Review request for 8020708 NLS: mnemonics missing in SwingSet2/JInternalFrame demo In-Reply-To: <5257D441.5010603@oracle.com> References: <5256C118.8030002@oracle.com> <5257D441.5010603@oracle.com> Message-ID: I see.. I'm not an expert in this area, so from my limited prospective, the fix looks good. On Oct 11, 2013, at 2:34 PM, Alexander Scherbatiy wrote: > On 10/10/2013 11:12 PM, Leonid Romanov wrote: >> Hello, >> Who is the author of localized properties changes? Is it you or someone from i18n team? > > I have updated the localized InternalFrameTitlePane properties. Only mnemonics have been updated. > It is done in the same way as for other properties like: > basic.properties: ColorChooser.rgbRed.textAndMnemonic=Re&d > basic_zh_TW.properties: ColorChooser.rgbRed.textAndMnemonic=\u7D05(&D) > > This is the standard procedure to include mnemonics into properties by & sign. > So name=A&BC property means that the value is ABC and the mnemonic is B. > If a value does not contain a mnemonic char it needs to be added at the end like name=ABC(&D) > > Thanks, > Alexandr. > >> >> On Oct 10, 2013, at 7:00 PM, Alexander Scherbatiy wrote: >> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8020708 >>> webrev: http://cr.openjdk.java.net/~alexsch/8020708/webrev.00 >>> >>> The fix updates mnemonics for the InternalFrameTitlePane.*Button properties >>> - Mnemonics are loaded from the *.properties files >>> - (&Mnemonic) is added for the localized text that does not contains the mnemonics char >>> >>> >>> Thanks, >>> Alexandr. >>> > From weijun.wang at oracle.com Sat Oct 12 00:49:37 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 12 Oct 2013 08:49:37 +0800 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard Message-ID: <52589CA1.4080503@oracle.com> Hi All Please review the fix at http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ The fix includes porting PolicyTool from AWT to Swing, defining mnemonics for menu items and buttons, and adding keyboard shortcuts for the File -> New/Open/Save items. Several tests are updated also. Thanks Max From sergey.malenkov at oracle.com Mon Oct 14 09:01:35 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Mon, 14 Oct 2013 13:01:35 +0400 Subject: [8] Review request for 7035495: javax.swing.ImageIcon spec should be clarified Message-ID: <525BB2EF.9080109@oracle.com> Hello, Could you please review the following fix: fix:http://cr.openjdk.java.net/~malenkov/7035495.8.0/ bug:https://bugs.openjdk.java.net/browse/JDK-7035495 The javadoc added for deprecated fields. Thanks, SAM From alexandr.scherbatiy at oracle.com Mon Oct 14 09:16:09 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 14 Oct 2013 02:16:09 -0700 (PDT) Subject: [8] Review request for 7035495: javax.swing.ImageIcon spec should be clarified In-Reply-To: <525BB2EF.9080109@oracle.com> References: <525BB2EF.9080109@oracle.com> Message-ID: <525BB659.8000904@oracle.com> The fix looks good for me. Thanks, Alexandr. On 10/14/2013 1:01 PM, sergey malenkov wrote: > Hello, > > Could you please review the following fix: > fix:http://cr.openjdk.java.net/~malenkov/7035495.8.0/ > > bug:https://bugs.openjdk.java.net/browse/JDK-7035495 > > > The javadoc added for deprecated fields. > > Thanks, > SAM > From dmitry.ginzburg at oracle.com Tue Oct 15 10:04:47 2013 From: dmitry.ginzburg at oracle.com (Dmitry Ginzburg) Date: Tue, 15 Oct 2013 14:04:47 +0400 Subject: [8] Review Request: JDK-8025234 [javadoc] fix some errors in javax.swing.** In-Reply-To: <525BFF51.5080609@oracle.com> References: <524442C3.8050202@oracle.com> <52455E2A.8060108@oracle.com> <52455ED3.4060804@oracle.com> <52456025.4070706@oracle.com> <52456279.5050802@oracle.com> <52457D69.7080209@oracle.com> <5245AE45.6000409@oracle.com> <524EC569.2070107@oracle.com> <524EF34E.80509@oracle.com> <524EF971.9030501@oracle.com> <525BFF51.5080609@oracle.com> Message-ID: <525D133F.9090900@oracle.com> forwarding to swing-dev 14.10.2013 18:27, Dmitry Ginzburg wrote: > See new webrev: http://cr.openjdk.java.net/~yan/jdk-8025234/webrev.01/ > > > Thanks, > -Dmitry > > 04.10.2013 21:22, alexey zhebel wrote: >> Yes, change

to

. Doc comments are not really written in HTML. >> They get converted to HTML by Javadoc. The

here is not a >> paragraph opening tag, it is a marker for Javadoc to start a new >> paragraph. >> >> Best regards, >> Alexey Zhebel >> >> On 04.10.2013 20:56, Alexander Scherbatiy wrote: >>> >>> The mistaken tag

should be corrected to

. This avoids >>> fixing the typo next time. >>> >>> Thanks, >>> Alexandr. >>> >>> On 10/4/2013 5:40 PM, Dmitry Ginzburg wrote: >>>> Hi guys >>>> >>>> Have you decided what to do in this situation? >>>> Maybe my solution have to be approved? >>>> >>>> Thanks, >>>> -Dmitry >>>> >>>> 27.09.2013 20:11, alexey zhebel wrote: >>>>> Hi Alexander! >>>>> >>>>> AFAIK, the paragraph separator for Javadoc comments is

. So it >>>>> is a typo (the > and / characters are close on the keyboard). >>>>> >>>>> Here is a good example: >>>>> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#format >>>>> >>>>> >>>>> Best regards, >>>>> Alexey Zhebel >>>>> >>>>> On 27.09.2013 16:43, Alexander Scherbatiy wrote: >>>>>> >>>>>> Hello Alexey, >>>>>> >>>>>> The is the

tag at line: 1384 in the file >>>>>> http://hg.openjdk.java.net/jdk8/awt/jdk/file/ca45169cb4eb/src/share/classes/javax/swing/AbstractButton.java >>>>>> >>>>>> 1379 /** >>>>>> 1380 * Sets the borderPainted property. >>>>>> 1381 * If true and the button has a border, >>>>>> 1382 * the border is painted. The default value for the >>>>>> 1383 * borderPainted property is >>>>>> true. >>>>>> 1384 *

>>>>>> 1385 * Some look and feels might not support >>>>>> 1386 * the borderPainted property, >>>>>> 1387 * in which case they ignore this. >>>>>> >>>>>> Could look at this and say is it just a typo and what should be >>>>>> the corrected code? >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>>> On 9/27/2013 2:48 PM, Dmitry Ginzburg wrote: >>>>>>> According to w3c (http://dev.w3.org/html5/markup/p.html#p) >>>>>>> pelement?send tagmay >>>>>>> be omitted if thepelement is immediately followed by an >>>>>> some tags>, but that's false in our case, it's followed by text. >>>>>>> >>>>>>> 27.09.2013 14:38, Sergey Bylokhov wrote: >>>>>>>> Why not just

? >>>>>>>> >>>>>>>> On 27.09.2013 14:32, Dmitry Ginzburg wrote: >>>>>>>>> If it made sense earlier to do the same thing with >>>>>>>>> self-closing tag, it's now the same, but valid for doclint. >>>>>>>>> >>>>>>>>> 27.09.2013 14:30, Alexander Scherbatiy wrote: >>>>>>>>>> >>>>>>>>>> --- old/src/share/classes/javax/swing/AbstractButton.java >>>>>>>>>> +++ new/src/share/classes/javax/swing/AbstractButton.java >>>>>>>>>> @@ -1381,7 +1381,7 @@ >>>>>>>>>> * If true and the button has a border, >>>>>>>>>> * the border is painted. The default value for the >>>>>>>>>> * borderPainted property is >>>>>>>>>> true. >>>>>>>>>> - *

>>>>>>>>>> + *

>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Does it has sense to have open and closed p tags without the >>>>>>>>>> text? >>>>>>>>>> >>>>>>>>>> Otherwise, the fix looks good for me. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Alexandr. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/26/2013 6:20 PM, Dmitry Ginzburg wrote: >>>>>>>>>>> Hello, Swing Team. >>>>>>>>>>> >>>>>>>>>>> Please review the fix for the following issue: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025234 >>>>>>>>>>> The fix is available at: >>>>>>>>>>> http://cr.openjdk.java.net/~yan/jdk-8025234/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> This is the fix for javadoc errors, on which doclint was >>>>>>>>>>> showing some issues. >>>>>>>>>>> >>>>>>>>>>> The patch contains only simple markup fixes; no >>>>>>>>>>> changes/fixes in >>>>>>>>>>> documentation text; the specification itself wasn't changed. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dmitry Ginzburg, FXSQE team member >>>>>> >>>>> >>>> >>>> >>> >> > > -- Dmitry Ginzburg, FXSQE team member From alexandr.scherbatiy at oracle.com Tue Oct 15 10:24:12 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 15 Oct 2013 14:24:12 +0400 Subject: [8] Review Request: JDK-8025234 [javadoc] fix some errors in javax.swing.** In-Reply-To: <525D133F.9090900@oracle.com> References: <524442C3.8050202@oracle.com> <52455E2A.8060108@oracle.com> <52455ED3.4060804@oracle.com> <52456025.4070706@oracle.com> <52456279.5050802@oracle.com> <52457D69.7080209@oracle.com> <5245AE45.6000409@oracle.com> <524EC569.2070107@oracle.com> <524EF34E.80509@oracle.com> <524EF971.9030501@oracle.com> <525BFF51.5080609@oracle.com> <525D133F.9090900@oracle.com> Message-ID: <525D17CC.3060500@oracle.com> The fix looks good for me. Thanks, Alexandr. On 10/15/2013 2:04 PM, Dmitry Ginzburg wrote: > forwarding to swing-dev > > 14.10.2013 18:27, Dmitry Ginzburg wrote: >> See new webrev: >> http://cr.openjdk.java.net/~yan/jdk-8025234/webrev.01/ >> >> >> Thanks, >> -Dmitry >> >> 04.10.2013 21:22, alexey zhebel wrote: >>> Yes, change

to

. Doc comments are not really written in >>> HTML. They get converted to HTML by Javadoc. The

here is not a >>> paragraph opening tag, it is a marker for Javadoc to start a new >>> paragraph. >>> >>> Best regards, >>> Alexey Zhebel >>> >>> On 04.10.2013 20:56, Alexander Scherbatiy wrote: >>>> >>>> The mistaken tag

should be corrected to

. This avoids >>>> fixing the typo next time. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 10/4/2013 5:40 PM, Dmitry Ginzburg wrote: >>>>> Hi guys >>>>> >>>>> Have you decided what to do in this situation? >>>>> Maybe my solution have to be approved? >>>>> >>>>> Thanks, >>>>> -Dmitry >>>>> >>>>> 27.09.2013 20:11, alexey zhebel wrote: >>>>>> Hi Alexander! >>>>>> >>>>>> AFAIK, the paragraph separator for Javadoc comments is

. So it >>>>>> is a typo (the > and / characters are close on the keyboard). >>>>>> >>>>>> Here is a good example: >>>>>> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#format >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Alexey Zhebel >>>>>> >>>>>> On 27.09.2013 16:43, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hello Alexey, >>>>>>> >>>>>>> The is the

tag at line: 1384 in the file >>>>>>> http://hg.openjdk.java.net/jdk8/awt/jdk/file/ca45169cb4eb/src/share/classes/javax/swing/AbstractButton.java >>>>>>> >>>>>>> 1379 /** >>>>>>> 1380 * Sets the borderPainted property. >>>>>>> 1381 * If true and the button has a border, >>>>>>> 1382 * the border is painted. The default value for the >>>>>>> 1383 * borderPainted property is >>>>>>> true. >>>>>>> 1384 *

>>>>>>> 1385 * Some look and feels might not support >>>>>>> 1386 * the borderPainted property, >>>>>>> 1387 * in which case they ignore this. >>>>>>> >>>>>>> Could look at this and say is it just a typo and what should be >>>>>>> the corrected code? >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>>> On 9/27/2013 2:48 PM, Dmitry Ginzburg wrote: >>>>>>>> According to w3c (http://dev.w3.org/html5/markup/p.html#p) >>>>>>>> pelement?send tagmay >>>>>>>> be omitted if thepelement is immediately followed by an >>>>>>> some tags>, but that's false in our case, it's followed by text. >>>>>>>> >>>>>>>> 27.09.2013 14:38, Sergey Bylokhov wrote: >>>>>>>>> Why not just

? >>>>>>>>> >>>>>>>>> On 27.09.2013 14:32, Dmitry Ginzburg wrote: >>>>>>>>>> If it made sense earlier to do the same thing with >>>>>>>>>> self-closing tag, it's now the same, but valid for doclint. >>>>>>>>>> >>>>>>>>>> 27.09.2013 14:30, Alexander Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>> --- old/src/share/classes/javax/swing/AbstractButton.java >>>>>>>>>>> +++ new/src/share/classes/javax/swing/AbstractButton.java >>>>>>>>>>> @@ -1381,7 +1381,7 @@ >>>>>>>>>>> * If true and the button has a border, >>>>>>>>>>> * the border is painted. The default value for the >>>>>>>>>>> * borderPainted property is >>>>>>>>>>> true. >>>>>>>>>>> - *

>>>>>>>>>>> + *

>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Does it has sense to have open and closed p tags without the >>>>>>>>>>> text? >>>>>>>>>>> >>>>>>>>>>> Otherwise, the fix looks good for me. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9/26/2013 6:20 PM, Dmitry Ginzburg wrote: >>>>>>>>>>>> Hello, Swing Team. >>>>>>>>>>>> >>>>>>>>>>>> Please review the fix for the following issue: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025234 >>>>>>>>>>>> The fix is available at: >>>>>>>>>>>> http://cr.openjdk.java.net/~yan/jdk-8025234/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> This is the fix for javadoc errors, on which doclint was >>>>>>>>>>>> showing some issues. >>>>>>>>>>>> >>>>>>>>>>>> The patch contains only simple markup fixes; no >>>>>>>>>>>> changes/fixes in >>>>>>>>>>>> documentation text; the specification itself wasn't changed. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dmitry Ginzburg, FXSQE team member >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> > > From anthony.petrov at oracle.com Tue Oct 15 12:08:44 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 15 Oct 2013 16:08:44 +0400 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <52589CA1.4080503@oracle.com> References: <52589CA1.4080503@oracle.com> Message-ID: <525D304C.9090304@oracle.com> Hi Max, I don't have expertise in this code so I haven't reviewed the fix thoroughly. I'd like to point out one thing though: unlike AWT, Swing is a single-threaded GUI toolkit. While in AWT you can create components/windows and call APIs on any thread, in Swing everything GUI-related must be performed on the Event Dispatch Thread (EDT) only. Any long, non-GUI-related operations (like I/O, computations, etc.) should be dispatched on other threads (with a SwingWorker, for example). I don't see a single SwingUtilities.invokeLater/invokeAndWait() call in PolicyTool.java, so I thought I'd ask whether you're aware of the threading limitations imposed by Swing and how those are going to be addressed? -- best regards, Anthony On 10/12/2013 04:49 AM, Weijun Wang wrote: > Hi All > > Please review the fix at > > http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ > > The fix includes porting PolicyTool from AWT to Swing, defining > mnemonics for menu items and buttons, and adding keyboard shortcuts for > the File -> New/Open/Save items. Several tests are updated also. > > Thanks > Max From weijun.wang at oracle.com Tue Oct 15 14:13:09 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 15 Oct 2013 22:13:09 +0800 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <525D304C.9090304@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> Message-ID: <525D4D75.3090200@oracle.com> Policy Tool is a GUI editor for the plain text policy file. The only I/O is loading the policy file from disk and it should be quite small, so I think there won't be a problem here. Thanks Max On 10/15/13 8:08 PM, Anthony Petrov wrote: > Hi Max, > > I don't have expertise in this code so I haven't reviewed the fix > thoroughly. I'd like to point out one thing though: unlike AWT, Swing is > a single-threaded GUI toolkit. While in AWT you can create > components/windows and call APIs on any thread, in Swing everything > GUI-related must be performed on the Event Dispatch Thread (EDT) only. > Any long, non-GUI-related operations (like I/O, computations, etc.) > should be dispatched on other threads (with a SwingWorker, for example). > > I don't see a single SwingUtilities.invokeLater/invokeAndWait() call in > PolicyTool.java, so I thought I'd ask whether you're aware of the > threading limitations imposed by Swing and how those are going to be > addressed? > > -- > best regards, > Anthony > > On 10/12/2013 04:49 AM, Weijun Wang wrote: >> Hi All >> >> Please review the fix at >> >> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >> >> The fix includes porting PolicyTool from AWT to Swing, defining >> mnemonics for menu items and buttons, and adding keyboard shortcuts for >> the File -> New/Open/Save items. Several tests are updated also. >> >> Thanks >> Max From anthony.petrov at oracle.com Tue Oct 15 16:43:29 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 15 Oct 2013 20:43:29 +0400 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <525D4D75.3090200@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> <525D4D75.3090200@oracle.com> Message-ID: <525D70B1.4020603@oracle.com> Well, performing I/O or other blocking operations on EDT can only freeze the app's GUI for the period of blocking. If developers/users are OK with that, this is fine with me too. However, you should still call all Swing APIs (including creating your components/windows) on the EDT. And I don't see this is being done in your current code. As a minimum, the displayToolWindow() method should be dispatched on the event thread. I haven't examined the code closely, but if there are any other GUI updates from separate threads, those should also be moved to the EDT. See the following tutorial for details: http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html -- best regards, Anthony On 10/15/2013 06:13 PM, Weijun Wang wrote: > Policy Tool is a GUI editor for the plain text policy file. The only I/O > is loading the policy file from disk and it should be quite small, so I > think there won't be a problem here. > > Thanks > Max > > On 10/15/13 8:08 PM, Anthony Petrov wrote: >> Hi Max, >> >> I don't have expertise in this code so I haven't reviewed the fix >> thoroughly. I'd like to point out one thing though: unlike AWT, Swing is >> a single-threaded GUI toolkit. While in AWT you can create >> components/windows and call APIs on any thread, in Swing everything >> GUI-related must be performed on the Event Dispatch Thread (EDT) only. >> Any long, non-GUI-related operations (like I/O, computations, etc.) >> should be dispatched on other threads (with a SwingWorker, for example). >> >> I don't see a single SwingUtilities.invokeLater/invokeAndWait() call in >> PolicyTool.java, so I thought I'd ask whether you're aware of the >> threading limitations imposed by Swing and how those are going to be >> addressed? >> >> -- >> best regards, >> Anthony >> >> On 10/12/2013 04:49 AM, Weijun Wang wrote: >>> Hi All >>> >>> Please review the fix at >>> >>> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >>> >>> The fix includes porting PolicyTool from AWT to Swing, defining >>> mnemonics for menu items and buttons, and adding keyboard shortcuts for >>> the File -> New/Open/Save items. Several tests are updated also. >>> >>> Thanks >>> Max From alexander.potochkin at oracle.com Tue Oct 15 16:56:41 2013 From: alexander.potochkin at oracle.com (alexander potochkin) Date: Tue, 15 Oct 2013 09:56:41 -0700 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <525D70B1.4020603@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> <525D4D75.3090200@oracle.com> <525D70B1.4020603@oracle.com> Message-ID: <525D73C9.2090702@oracle.com> Hello > Well, performing I/O or other blocking operations on EDT can only > freeze the app's GUI for the period of blocking. If developers/users > are OK with that, this is fine with me too. > I don't think an I/O blocking operation on EDT is acceptable. It can freeze the whole application and give a bad experience to the users. Please consider using the SwingWorker API http://docs.oracle.com/javase/tutorial/uiswing/concurrency/worker.html > However, you should still call all Swing APIs (including creating your > components/windows) on the EDT. And I don't see this is being done in > your current code. As a minimum, the displayToolWindow() method should > be dispatched on the event thread. I haven't examined the code > closely, but if there are any other GUI updates from separate threads, > those should also be moved to the EDT. See the following tutorial for > details: > > http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html > Indeed, rewriting an AWT app as a Swing app is not only about changing Labels to JLabels Please make sure that all Swing code are used on the event dispatching thread only. Thanks alexp > -- > best regards, > Anthony > > On 10/15/2013 06:13 PM, Weijun Wang wrote: >> Policy Tool is a GUI editor for the plain text policy file. The only I/O >> is loading the policy file from disk and it should be quite small, so I >> think there won't be a problem here. >> >> Thanks >> Max >> >> On 10/15/13 8:08 PM, Anthony Petrov wrote: >>> Hi Max, >>> >>> I don't have expertise in this code so I haven't reviewed the fix >>> thoroughly. I'd like to point out one thing though: unlike AWT, >>> Swing is >>> a single-threaded GUI toolkit. While in AWT you can create >>> components/windows and call APIs on any thread, in Swing everything >>> GUI-related must be performed on the Event Dispatch Thread (EDT) only. >>> Any long, non-GUI-related operations (like I/O, computations, etc.) >>> should be dispatched on other threads (with a SwingWorker, for >>> example). >>> >>> I don't see a single SwingUtilities.invokeLater/invokeAndWait() call in >>> PolicyTool.java, so I thought I'd ask whether you're aware of the >>> threading limitations imposed by Swing and how those are going to be >>> addressed? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/12/2013 04:49 AM, Weijun Wang wrote: >>>> Hi All >>>> >>>> Please review the fix at >>>> >>>> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >>>> >>>> The fix includes porting PolicyTool from AWT to Swing, defining >>>> mnemonics for menu items and buttons, and adding keyboard shortcuts >>>> for >>>> the File -> New/Open/Save items. Several tests are updated also. >>>> >>>> Thanks >>>> Max From leif.samuelsson at oracle.com Tue Oct 15 17:00:45 2013 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Tue, 15 Oct 2013 10:00:45 -0700 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <525D73C9.2090702@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> <525D4D75.3090200@oracle.com> <525D70B1.4020603@oracle.com> <525D73C9.2090702@oracle.com> Message-ID: <525D74BD.6070707@oracle.com> Thanks for the good feedback. We will make sure to move to move the GUI instantiation to the EDT and the file I/O to a worker thread. All other operations are event driven and therefore occur directly on the EDT. Leif On 2013-10-15 09:56, alexander potochkin wrote: > Hello > >> Well, performing I/O or other blocking operations on EDT can only freeze the app's GUI for the period of blocking. If developers/users are OK with that, this is fine with me too. >> > > I don't think an I/O blocking operation on EDT is acceptable. It can freeze the whole application and give a bad experience to the users. > Please consider using the SwingWorker API > http://docs.oracle.com/javase/tutorial/uiswing/concurrency/worker.html > > >> However, you should still call all Swing APIs (including creating your components/windows) on the EDT. And I don't see this is being done in your current code. As a minimum, the displayToolWindow() method should be dispatched on the event thread. I haven't examined the code closely, but if there are any other GUI updates from separate threads, those should also be moved to the EDT. See the following tutorial for details: >> >> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html >> > > Indeed, rewriting an AWT app as a Swing app is not only about changing Labels to JLabels > Please make sure that all Swing code are used on the event dispatching thread only. > > Thanks > alexp > >> -- >> best regards, >> Anthony >> >> On 10/15/2013 06:13 PM, Weijun Wang wrote: >>> Policy Tool is a GUI editor for the plain text policy file. The only I/O >>> is loading the policy file from disk and it should be quite small, so I >>> think there won't be a problem here. >>> >>> Thanks >>> Max >>> >>> On 10/15/13 8:08 PM, Anthony Petrov wrote: >>>> Hi Max, >>>> >>>> I don't have expertise in this code so I haven't reviewed the fix >>>> thoroughly. I'd like to point out one thing though: unlike AWT, Swing is >>>> a single-threaded GUI toolkit. While in AWT you can create >>>> components/windows and call APIs on any thread, in Swing everything >>>> GUI-related must be performed on the Event Dispatch Thread (EDT) only. >>>> Any long, non-GUI-related operations (like I/O, computations, etc.) >>>> should be dispatched on other threads (with a SwingWorker, for example). >>>> >>>> I don't see a single SwingUtilities.invokeLater/invokeAndWait() call in >>>> PolicyTool.java, so I thought I'd ask whether you're aware of the >>>> threading limitations imposed by Swing and how those are going to be >>>> addressed? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/12/2013 04:49 AM, Weijun Wang wrote: >>>>> Hi All >>>>> >>>>> Please review the fix at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >>>>> >>>>> The fix includes porting PolicyTool from AWT to Swing, defining >>>>> mnemonics for menu items and buttons, and adding keyboard shortcuts for >>>>> the File -> New/Open/Save items. Several tests are updated also. >>>>> >>>>> Thanks >>>>> Max > From Nicholas.Rahn at bedag.ch Thu Oct 17 09:32:00 2013 From: Nicholas.Rahn at bedag.ch (Rahn Nicholas, Bedag) Date: Thu, 17 Oct 2013 09:32:00 +0000 Subject: Could changeset 7166409 be applied to jdk7u? Message-ID: Hi. The changeset 7166409 fixes an NPE in the WindowsLookAndFeel code when run on Linux. However, it seems that the change was only applied to jdk8. Would it be possible to have it applied to jdk7u too? http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/4faaaf5027a5 Thanks, Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.malenkov at oracle.com Thu Oct 17 14:35:22 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Thu, 17 Oct 2013 18:35:22 +0400 Subject: [8] Review Request: JDK-8025234 [javadoc] fix some errors in javax.swing.** In-Reply-To: <525D133F.9090900@oracle.com> References: <524442C3.8050202@oracle.com> <52455E2A.8060108@oracle.com> <52455ED3.4060804@oracle.com> <52456025.4070706@oracle.com> <52456279.5050802@oracle.com> <52457D69.7080209@oracle.com> <5245AE45.6000409@oracle.com> <524EC569.2070107@oracle.com> <524EF34E.80509@oracle.com> <524EF971.9030501@oracle.com> <525BFF51.5080609@oracle.com> <525D133F.9090900@oracle.com> Message-ID: <525FF5AA.4060006@oracle.com> The fix looks OK. Thanks, SAM On 15.10.2013 14:04, Dmitry Ginzburg wrote: > forwarding to swing-dev > > 14.10.2013 18:27, Dmitry Ginzburg wrote: >> See new webrev: >> http://cr.openjdk.java.net/~yan/jdk-8025234/webrev.01/ >> >> >> Thanks, >> -Dmitry >> >> 04.10.2013 21:22, alexey zhebel wrote: >>> Yes, change

to

. Doc comments are not really written in >>> HTML. They get converted to HTML by Javadoc. The

here is not a >>> paragraph opening tag, it is a marker for Javadoc to start a new >>> paragraph. >>> >>> Best regards, >>> Alexey Zhebel >>> >>> On 04.10.2013 20:56, Alexander Scherbatiy wrote: >>>> >>>> The mistaken tag

should be corrected to

. This avoids >>>> fixing the typo next time. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 10/4/2013 5:40 PM, Dmitry Ginzburg wrote: >>>>> Hi guys >>>>> >>>>> Have you decided what to do in this situation? >>>>> Maybe my solution have to be approved? >>>>> >>>>> Thanks, >>>>> -Dmitry >>>>> >>>>> 27.09.2013 20:11, alexey zhebel wrote: >>>>>> Hi Alexander! >>>>>> >>>>>> AFAIK, the paragraph separator for Javadoc comments is

. So it >>>>>> is a typo (the > and / characters are close on the keyboard). >>>>>> >>>>>> Here is a good example: >>>>>> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#format >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Alexey Zhebel >>>>>> >>>>>> On 27.09.2013 16:43, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hello Alexey, >>>>>>> >>>>>>> The is the

tag at line: 1384 in the file >>>>>>> http://hg.openjdk.java.net/jdk8/awt/jdk/file/ca45169cb4eb/src/share/classes/javax/swing/AbstractButton.java >>>>>>> >>>>>>> 1379 /** >>>>>>> 1380 * Sets the borderPainted property. >>>>>>> 1381 * If true and the button has a border, >>>>>>> 1382 * the border is painted. The default value for the >>>>>>> 1383 * borderPainted property is >>>>>>> true. >>>>>>> 1384 *

>>>>>>> 1385 * Some look and feels might not support >>>>>>> 1386 * the borderPainted property, >>>>>>> 1387 * in which case they ignore this. >>>>>>> >>>>>>> Could look at this and say is it just a typo and what should be >>>>>>> the corrected code? >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>>> On 9/27/2013 2:48 PM, Dmitry Ginzburg wrote: >>>>>>>> According to w3c (http://dev.w3.org/html5/markup/p.html#p) >>>>>>>> pelement?send tagmay >>>>>>>> be omitted if thepelement is immediately followed by an >>>>>>> some tags>, but that's false in our case, it's followed by text. >>>>>>>> >>>>>>>> 27.09.2013 14:38, Sergey Bylokhov wrote: >>>>>>>>> Why not just

? >>>>>>>>> >>>>>>>>> On 27.09.2013 14:32, Dmitry Ginzburg wrote: >>>>>>>>>> If it made sense earlier to do the same thing with >>>>>>>>>> self-closing tag, it's now the same, but valid for doclint. >>>>>>>>>> >>>>>>>>>> 27.09.2013 14:30, Alexander Scherbatiy wrote: >>>>>>>>>>> >>>>>>>>>>> --- old/src/share/classes/javax/swing/AbstractButton.java >>>>>>>>>>> +++ new/src/share/classes/javax/swing/AbstractButton.java >>>>>>>>>>> @@ -1381,7 +1381,7 @@ >>>>>>>>>>> * If true and the button has a border, >>>>>>>>>>> * the border is painted. The default value for the >>>>>>>>>>> * borderPainted property is >>>>>>>>>>> true. >>>>>>>>>>> - *

>>>>>>>>>>> + *

>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Does it has sense to have open and closed p tags without the >>>>>>>>>>> text? >>>>>>>>>>> >>>>>>>>>>> Otherwise, the fix looks good for me. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Alexandr. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9/26/2013 6:20 PM, Dmitry Ginzburg wrote: >>>>>>>>>>>> Hello, Swing Team. >>>>>>>>>>>> >>>>>>>>>>>> Please review the fix for the following issue: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025234 >>>>>>>>>>>> The fix is available at: >>>>>>>>>>>> http://cr.openjdk.java.net/~yan/jdk-8025234/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> This is the fix for javadoc errors, on which doclint was >>>>>>>>>>>> showing some issues. >>>>>>>>>>>> >>>>>>>>>>>> The patch contains only simple markup fixes; no >>>>>>>>>>>> changes/fixes in >>>>>>>>>>>> documentation text; the specification itself wasn't changed. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dmitry Ginzburg, FXSQE team member >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> > > From dmitry.ginzburg at oracle.com Thu Oct 17 14:39:12 2013 From: dmitry.ginzburg at oracle.com (Dmitry Ginzburg) Date: Thu, 17 Oct 2013 18:39:12 +0400 Subject: [8] Review Request: JDK-8025234 [javadoc] fix some errors in javax.swing.** In-Reply-To: <525FF5AA.4060006@oracle.com> References: <524442C3.8050202@oracle.com> <52455E2A.8060108@oracle.com> <52455ED3.4060804@oracle.com> <52456025.4070706@oracle.com> <52456279.5050802@oracle.com> <52457D69.7080209@oracle.com> <5245AE45.6000409@oracle.com> <524EC569.2070107@oracle.com> <524EF34E.80509@oracle.com> <524EF971.9030501@oracle.com> <525BFF51.5080609@oracle.com> <525D133F.9090900@oracle.com> <525FF5AA.4060006@oracle.com> Message-ID: <525FF690.7010304@oracle.com> Thanks, Sergey Can I be sure now yan can push this fix? Thanks, -Dmitry 17.10.2013 18:35, sergey malenkov wrote: > The fix looks OK. > > Thanks, > SAM > > On 15.10.2013 14:04, Dmitry Ginzburg wrote: >> forwarding to swing-dev >> >> 14.10.2013 18:27, Dmitry Ginzburg wrote: >>> See new webrev: >>> http://cr.openjdk.java.net/~yan/jdk-8025234/webrev.01/ >>> >>> >>> Thanks, >>> -Dmitry >>> >>> 04.10.2013 21:22, alexey zhebel wrote: >>>> Yes, change

to

. Doc comments are not really written in >>>> HTML. They get converted to HTML by Javadoc. The

here is not a >>>> paragraph opening tag, it is a marker for Javadoc to start a new >>>> paragraph. >>>> >>>> Best regards, >>>> Alexey Zhebel >>>> >>>> On 04.10.2013 20:56, Alexander Scherbatiy wrote: >>>>> >>>>> The mistaken tag

should be corrected to

. This avoids >>>>> fixing the typo next time. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 10/4/2013 5:40 PM, Dmitry Ginzburg wrote: >>>>>> Hi guys >>>>>> >>>>>> Have you decided what to do in this situation? >>>>>> Maybe my solution have to be approved? >>>>>> >>>>>> Thanks, >>>>>> -Dmitry >>>>>> >>>>>> 27.09.2013 20:11, alexey zhebel wrote: >>>>>>> Hi Alexander! >>>>>>> >>>>>>> AFAIK, the paragraph separator for Javadoc comments is

. So >>>>>>> it is a typo (the > and / characters are close on the keyboard). >>>>>>> >>>>>>> Here is a good example: >>>>>>> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#format >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Alexey Zhebel >>>>>>> >>>>>>> On 27.09.2013 16:43, Alexander Scherbatiy wrote: >>>>>>>> >>>>>>>> Hello Alexey, >>>>>>>> >>>>>>>> The is the

tag at line: 1384 in the file >>>>>>>> http://hg.openjdk.java.net/jdk8/awt/jdk/file/ca45169cb4eb/src/share/classes/javax/swing/AbstractButton.java >>>>>>>> >>>>>>>> 1379 /** >>>>>>>> 1380 * Sets the borderPainted property. >>>>>>>> 1381 * If true and the button has a border, >>>>>>>> 1382 * the border is painted. The default value for the >>>>>>>> 1383 * borderPainted property is >>>>>>>> true. >>>>>>>> 1384 *

>>>>>>>> 1385 * Some look and feels might not support >>>>>>>> 1386 * the borderPainted property, >>>>>>>> 1387 * in which case they ignore this. >>>>>>>> >>>>>>>> Could look at this and say is it just a typo and what should >>>>>>>> be the corrected code? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>>> On 9/27/2013 2:48 PM, Dmitry Ginzburg wrote: >>>>>>>>> According to w3c (http://dev.w3.org/html5/markup/p.html#p) >>>>>>>>> pelement?send tagmay >>>>>>>>> be omitted if thepelement is immediately followed by an >>>>>>>> of some tags>, but that's false in our case, it's followed by >>>>>>>>> text. >>>>>>>>> >>>>>>>>> 27.09.2013 14:38, Sergey Bylokhov wrote: >>>>>>>>>> Why not just

? >>>>>>>>>> >>>>>>>>>> On 27.09.2013 14:32, Dmitry Ginzburg wrote: >>>>>>>>>>> If it made sense earlier to do the same thing with >>>>>>>>>>> self-closing tag, it's now the same, but valid for doclint. >>>>>>>>>>> >>>>>>>>>>> 27.09.2013 14:30, Alexander Scherbatiy wrote: >>>>>>>>>>>> >>>>>>>>>>>> --- old/src/share/classes/javax/swing/AbstractButton.java >>>>>>>>>>>> +++ new/src/share/classes/javax/swing/AbstractButton.java >>>>>>>>>>>> @@ -1381,7 +1381,7 @@ >>>>>>>>>>>> * If true and the button has a border, >>>>>>>>>>>> * the border is painted. The default value for the >>>>>>>>>>>> * borderPainted property is >>>>>>>>>>>> true. >>>>>>>>>>>> - *

>>>>>>>>>>>> + *

>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Does it has sense to have open and closed p tags without >>>>>>>>>>>> the text? >>>>>>>>>>>> >>>>>>>>>>>> Otherwise, the fix looks good for me. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Alexandr. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9/26/2013 6:20 PM, Dmitry Ginzburg wrote: >>>>>>>>>>>>> Hello, Swing Team. >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the fix for the following issue: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025234 >>>>>>>>>>>>> The fix is available at: >>>>>>>>>>>>> http://cr.openjdk.java.net/~yan/jdk-8025234/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> This is the fix for javadoc errors, on which doclint was >>>>>>>>>>>>> showing some issues. >>>>>>>>>>>>> >>>>>>>>>>>>> The patch contains only simple markup fixes; no >>>>>>>>>>>>> changes/fixes in >>>>>>>>>>>>> documentation text; the specification itself wasn't changed. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Dmitry Ginzburg, FXSQE team member >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> >> > -- Dmitry Ginzburg, FXSQE team member From leif.samuelsson at oracle.com Thu Oct 17 16:57:55 2013 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Thu, 17 Oct 2013 09:57:55 -0700 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <525D74BD.6070707@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> <525D4D75.3090200@oracle.com> <525D70B1.4020603@oracle.com> <525D73C9.2090702@oracle.com> <525D74BD.6070707@oracle.com> Message-ID: <52601713.5020202@oracle.com> Hi All, A new webrev is available at: http://cr.openjdk.java.net/~weijun/7025699/webrev.01/ The following new changes were made: 1. Added call to SwingUtilities.invokeLater() in main() to run the GUI initialization on the Event Dispatch Thread. 2. Minor corrections to initial size and placement of the main window. 3. More mnemonics defined for buttons and labeled fields on the Policy Entry and KeyStore dialogs. Note that we have decided to not implement the use of SwingWorker for File I/O in this release. The main reasons are that it is not covered in the scope of the bug report, the blocking can not actually be considered a regression compared to the AWT version, and it would require enough refactoring of the code to risk affecting the general logic and cause new bugs. I am the Contributor for this bug fix, and Max (Weijun) will be the Committer. Thanks, Leif On 2013-10-15 10:00, Leif Samuelsson wrote: > Thanks for the good feedback. We will make sure to move to move the > GUI instantiation to the EDT and the file I/O to a worker thread. > > All other operations are event driven and therefore occur directly > on the EDT. > > Leif > > > On 2013-10-15 09:56, alexander potochkin wrote: >> Hello >> >>> Well, performing I/O or other blocking operations on EDT can only freeze the app's GUI for the period of blocking. If developers/users are OK with that, this is fine with me too. >>> >> >> I don't think an I/O blocking operation on EDT is acceptable. It can freeze the whole application and give a bad experience to the users. >> Please consider using the SwingWorker API >> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/worker.html >> >> >>> However, you should still call all Swing APIs (including creating your components/windows) on the EDT. And I don't see this is being done in your current code. As a minimum, the displayToolWindow() method should be dispatched on the event thread. I haven't examined the code closely, but if there are any other GUI updates from separate threads, those should also be moved to the EDT. See the following tutorial for details: >>> >>> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html >>> >> >> Indeed, rewriting an AWT app as a Swing app is not only about changing Labels to JLabels >> Please make sure that all Swing code are used on the event dispatching thread only. >> >> Thanks >> alexp >> >>> -- >>> best regards, >>> Anthony >>> >>> On 10/15/2013 06:13 PM, Weijun Wang wrote: >>>> Policy Tool is a GUI editor for the plain text policy file. The only I/O >>>> is loading the policy file from disk and it should be quite small, so I >>>> think there won't be a problem here. >>>> >>>> Thanks >>>> Max >>>> >>>> On 10/15/13 8:08 PM, Anthony Petrov wrote: >>>>> Hi Max, >>>>> >>>>> I don't have expertise in this code so I haven't reviewed the fix >>>>> thoroughly. I'd like to point out one thing though: unlike AWT, Swing is >>>>> a single-threaded GUI toolkit. While in AWT you can create >>>>> components/windows and call APIs on any thread, in Swing everything >>>>> GUI-related must be performed on the Event Dispatch Thread (EDT) only. >>>>> Any long, non-GUI-related operations (like I/O, computations, etc.) >>>>> should be dispatched on other threads (with a SwingWorker, for example). >>>>> >>>>> I don't see a single SwingUtilities.invokeLater/invokeAndWait() call in >>>>> PolicyTool.java, so I thought I'd ask whether you're aware of the >>>>> threading limitations imposed by Swing and how those are going to be >>>>> addressed? >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 10/12/2013 04:49 AM, Weijun Wang wrote: >>>>>> Hi All >>>>>> >>>>>> Please review the fix at >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >>>>>> >>>>>> The fix includes porting PolicyTool from AWT to Swing, defining >>>>>> mnemonics for menu items and buttons, and adding keyboard shortcuts for >>>>>> the File -> New/Open/Save items. Several tests are updated also. >>>>>> >>>>>> Thanks >>>>>> Max >> From alexander.potochkin at oracle.com Thu Oct 17 17:11:12 2013 From: alexander.potochkin at oracle.com (alexander potochkin) Date: Thu, 17 Oct 2013 10:11:12 -0700 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <52601713.5020202@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> <525D4D75.3090200@oracle.com> <525D70B1.4020603@oracle.com> <525D73C9.2090702@oracle.com> <525D74BD.6070707@oracle.com> <52601713.5020202@oracle.com> Message-ID: <52601A30.8030401@oracle.com> Hello Leif Looks good to me I had a look at the PolicyTool code and indeed it is better to leave the IO processing as is at this moment. Thanks alexp > Hi All, > > A new webrev is available at: > > http://cr.openjdk.java.net/~weijun/7025699/webrev.01/ > > The following new changes were made: > > 1. Added call to SwingUtilities.invokeLater() in main() to run the GUI > initialization on the Event Dispatch Thread. > > 2. Minor corrections to initial size and placement of the main window. > > 3. More mnemonics defined for buttons and labeled fields on the Policy > Entry and KeyStore dialogs. > > Note that we have decided to not implement the use of SwingWorker for > File I/O in this release. The main reasons are that it is not covered > in the scope of the bug report, the blocking can not actually be > considered a regression compared to the AWT version, and it would > require enough refactoring of the code to risk affecting the general > logic and cause new bugs. > > I am the Contributor for this bug fix, and Max (Weijun) will be the > Committer. > > Thanks, > Leif > > > > On 2013-10-15 10:00, Leif Samuelsson wrote: >> Thanks for the good feedback. We will make sure to move to move the >> GUI instantiation to the EDT and the file I/O to a worker thread. >> >> All other operations are event driven and therefore occur directly >> on the EDT. >> >> Leif >> >> >> On 2013-10-15 09:56, alexander potochkin wrote: >>> Hello >>> >>>> Well, performing I/O or other blocking operations on EDT can only >>>> freeze the app's GUI for the period of blocking. If >>>> developers/users are OK with that, this is fine with me too. >>>> >>> >>> I don't think an I/O blocking operation on EDT is acceptable. It can >>> freeze the whole application and give a bad experience to the users. >>> Please consider using the SwingWorker API >>> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/worker.html >>> >>> >>>> However, you should still call all Swing APIs (including creating >>>> your components/windows) on the EDT. And I don't see this is being >>>> done in your current code. As a minimum, the displayToolWindow() >>>> method should be dispatched on the event thread. I haven't examined >>>> the code closely, but if there are any other GUI updates from >>>> separate threads, those should also be moved to the EDT. See the >>>> following tutorial for details: >>>> >>>> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html >>>> >>>> >>> >>> Indeed, rewriting an AWT app as a Swing app is not only about >>> changing Labels to JLabels >>> Please make sure that all Swing code are used on the event >>> dispatching thread only. >>> >>> Thanks >>> alexp >>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 10/15/2013 06:13 PM, Weijun Wang wrote: >>>>> Policy Tool is a GUI editor for the plain text policy file. The >>>>> only I/O >>>>> is loading the policy file from disk and it should be quite small, >>>>> so I >>>>> think there won't be a problem here. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> On 10/15/13 8:08 PM, Anthony Petrov wrote: >>>>>> Hi Max, >>>>>> >>>>>> I don't have expertise in this code so I haven't reviewed the fix >>>>>> thoroughly. I'd like to point out one thing though: unlike AWT, >>>>>> Swing is >>>>>> a single-threaded GUI toolkit. While in AWT you can create >>>>>> components/windows and call APIs on any thread, in Swing everything >>>>>> GUI-related must be performed on the Event Dispatch Thread (EDT) >>>>>> only. >>>>>> Any long, non-GUI-related operations (like I/O, computations, etc.) >>>>>> should be dispatched on other threads (with a SwingWorker, for >>>>>> example). >>>>>> >>>>>> I don't see a single SwingUtilities.invokeLater/invokeAndWait() >>>>>> call in >>>>>> PolicyTool.java, so I thought I'd ask whether you're aware of the >>>>>> threading limitations imposed by Swing and how those are going to be >>>>>> addressed? >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 10/12/2013 04:49 AM, Weijun Wang wrote: >>>>>>> Hi All >>>>>>> >>>>>>> Please review the fix at >>>>>>> >>>>>>> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >>>>>>> >>>>>>> The fix includes porting PolicyTool from AWT to Swing, defining >>>>>>> mnemonics for menu items and buttons, and adding keyboard >>>>>>> shortcuts for >>>>>>> the File -> New/Open/Save items. Several tests are updated also. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>> From anthony.petrov at oracle.com Fri Oct 18 10:05:50 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 18 Oct 2013 14:05:50 +0400 Subject: Code review request: 7025699: Policy Tool is not accessible by keyboard In-Reply-To: <52601A30.8030401@oracle.com> References: <52589CA1.4080503@oracle.com> <525D304C.9090304@oracle.com> <525D4D75.3090200@oracle.com> <525D70B1.4020603@oracle.com> <525D73C9.2090702@oracle.com> <525D74BD.6070707@oracle.com> <52601713.5020202@oracle.com> <52601A30.8030401@oracle.com> Message-ID: <526107FE.8050301@oracle.com> +1 -- best regards, Anthony On 10/17/2013 09:11 PM, alexander potochkin wrote: > Hello Leif > > Looks good to me > > I had a look at the PolicyTool code > and indeed it is better to leave the IO processing as is at this moment. > > Thanks > alexp > >> Hi All, >> >> A new webrev is available at: >> >> http://cr.openjdk.java.net/~weijun/7025699/webrev.01/ >> >> The following new changes were made: >> >> 1. Added call to SwingUtilities.invokeLater() in main() to run the GUI >> initialization on the Event Dispatch Thread. >> >> 2. Minor corrections to initial size and placement of the main window. >> >> 3. More mnemonics defined for buttons and labeled fields on the Policy >> Entry and KeyStore dialogs. >> >> Note that we have decided to not implement the use of SwingWorker for >> File I/O in this release. The main reasons are that it is not covered >> in the scope of the bug report, the blocking can not actually be >> considered a regression compared to the AWT version, and it would >> require enough refactoring of the code to risk affecting the general >> logic and cause new bugs. >> >> I am the Contributor for this bug fix, and Max (Weijun) will be the >> Committer. >> >> Thanks, >> Leif >> >> >> >> On 2013-10-15 10:00, Leif Samuelsson wrote: >>> Thanks for the good feedback. We will make sure to move to move the >>> GUI instantiation to the EDT and the file I/O to a worker thread. >>> >>> All other operations are event driven and therefore occur directly >>> on the EDT. >>> >>> Leif >>> >>> >>> On 2013-10-15 09:56, alexander potochkin wrote: >>>> Hello >>>> >>>>> Well, performing I/O or other blocking operations on EDT can only >>>>> freeze the app's GUI for the period of blocking. If >>>>> developers/users are OK with that, this is fine with me too. >>>>> >>>> >>>> I don't think an I/O blocking operation on EDT is acceptable. It can >>>> freeze the whole application and give a bad experience to the users. >>>> Please consider using the SwingWorker API >>>> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/worker.html >>>> >>>> >>>>> However, you should still call all Swing APIs (including creating >>>>> your components/windows) on the EDT. And I don't see this is being >>>>> done in your current code. As a minimum, the displayToolWindow() >>>>> method should be dispatched on the event thread. I haven't examined >>>>> the code closely, but if there are any other GUI updates from >>>>> separate threads, those should also be moved to the EDT. See the >>>>> following tutorial for details: >>>>> >>>>> http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html >>>>> >>>>> >>>> >>>> Indeed, rewriting an AWT app as a Swing app is not only about >>>> changing Labels to JLabels >>>> Please make sure that all Swing code are used on the event >>>> dispatching thread only. >>>> >>>> Thanks >>>> alexp >>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 10/15/2013 06:13 PM, Weijun Wang wrote: >>>>>> Policy Tool is a GUI editor for the plain text policy file. The >>>>>> only I/O >>>>>> is loading the policy file from disk and it should be quite small, >>>>>> so I >>>>>> think there won't be a problem here. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> On 10/15/13 8:08 PM, Anthony Petrov wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> I don't have expertise in this code so I haven't reviewed the fix >>>>>>> thoroughly. I'd like to point out one thing though: unlike AWT, >>>>>>> Swing is >>>>>>> a single-threaded GUI toolkit. While in AWT you can create >>>>>>> components/windows and call APIs on any thread, in Swing everything >>>>>>> GUI-related must be performed on the Event Dispatch Thread (EDT) >>>>>>> only. >>>>>>> Any long, non-GUI-related operations (like I/O, computations, etc.) >>>>>>> should be dispatched on other threads (with a SwingWorker, for >>>>>>> example). >>>>>>> >>>>>>> I don't see a single SwingUtilities.invokeLater/invokeAndWait() >>>>>>> call in >>>>>>> PolicyTool.java, so I thought I'd ask whether you're aware of the >>>>>>> threading limitations imposed by Swing and how those are going to be >>>>>>> addressed? >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 10/12/2013 04:49 AM, Weijun Wang wrote: >>>>>>>> Hi All >>>>>>>> >>>>>>>> Please review the fix at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~weijun/7025699/webrev.00/ >>>>>>>> >>>>>>>> The fix includes porting PolicyTool from AWT to Swing, defining >>>>>>>> mnemonics for menu items and buttons, and adding keyboard >>>>>>>> shortcuts for >>>>>>>> the File -> New/Open/Save items. Several tests are updated also. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>> > From alexandr.scherbatiy at oracle.com Fri Oct 18 11:09:23 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 18 Oct 2013 15:09:23 +0400 Subject: Could changeset 7166409 be applied to jdk7u? In-Reply-To: References: Message-ID: <526116E3.20606@oracle.com> On 10/17/2013 1:32 PM, Rahn Nicholas, Bedag wrote: > Hi. The changeset 7166409 fixes an NPE in the WindowsLookAndFeel code > when run on Linux. However, it seems that the change was only applied > to jdk8. Would it be possible to have it applied to jdk7u too? > _http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/4faaaf5027a5_ The request has been sent to the jdk7u-dev alias. http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-October/007956.html Thanks, Alexandr. > Thanks, > Nick From leif.samuelsson at oracle.com Mon Oct 21 19:12:09 2013 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Mon, 21 Oct 2013 12:12:09 -0700 Subject: Code review request: 8026929: remove accelerators from policytool resources Message-ID: <52657C89.1070601@oracle.com> Hi All, This is a small additional fix to PolicyTool to move the default accelerators for File->New/Open/Save from the resource bundle to hard coded values in PolicyTool.java. This is done to avoid confusing the translators about the difference between mnemonics and accelerators. Accelerators are typically not localized, but this fix will still allow overriding the values for rare cases, by specifying them in a localized resource bundle. http://cr.openjdk.java.net/~weijun/8026929/webrev.00/ I am the Contributor for this bug fix, and Max (Weijun) will be the Committer. Thanks, Leif From alexander.potochkin at oracle.com Tue Oct 22 11:25:09 2013 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Tue, 22 Oct 2013 15:25:09 +0400 Subject: Code review request: 8026929: remove accelerators from policytool resources In-Reply-To: <52657C89.1070601@oracle.com> References: <52657C89.1070601@oracle.com> Message-ID: <52666095.4010803@oracle.com> Hello Leif There was a special logic for keyStrokes on MacOS inPolicyTool.addMenuItem(), could you make sure that the new code correctly set keyStrokes on MacOS? Thanks alexp > Hi All, > > This is a small additional fix to PolicyTool to move the default > accelerators for File->New/Open/Save from the resource bundle to > hard coded values in PolicyTool.java. > > This is done to avoid confusing the translators about the difference > between mnemonics and accelerators. Accelerators are typically not > localized, but this fix will still allow overriding the values for > rare cases, by specifying them in a localized resource bundle. > > http://cr.openjdk.java.net/~weijun/8026929/webrev.00/ > > I am the Contributor for this bug fix, and Max (Weijun) will be the > Committer. > > Thanks, > Leif From leif.samuelsson at oracle.com Tue Oct 22 16:12:00 2013 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Tue, 22 Oct 2013 09:12:00 -0700 Subject: Code review request: 8026929: remove accelerators from policytool resources In-Reply-To: <52666095.4010803@oracle.com> References: <52657C89.1070601@oracle.com> <52666095.4010803@oracle.com> Message-ID: <5266A3D0.1040504@oracle.com> Hi Alexander, On 2013-10-22 04:25, Alexander Potochkin wrote: > Hello Leif > > There was a special logic for keyStrokes on MacOS inPolicyTool.addMenuItem(), > could you make sure that the new code correctly set keyStrokes on MacOS? That logic is still there, but it was simplified. As long as the accelerator string is defined with a single character, it will be set with the platform specific shortcut modifier "control" or "meta". If the string is longer, it will be passed to KeyStroke.getKeyStroke(String) for parsing. Thanks, Leif > Thanks > alexp >> Hi All, >> >> This is a small additional fix to PolicyTool to move the default >> accelerators for File->New/Open/Save from the resource bundle to >> hard coded values in PolicyTool.java. >> >> This is done to avoid confusing the translators about the difference >> between mnemonics and accelerators. Accelerators are typically not >> localized, but this fix will still allow overriding the values for >> rare cases, by specifying them in a localized resource bundle. >> >> http://cr.openjdk.java.net/~weijun/8026929/webrev.00/ >> >> I am the Contributor for this bug fix, and Max (Weijun) will be the >> Committer. >> >> Thanks, >> Leif > From anton.tarasov at oracle.com Wed Oct 23 18:15:07 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 23 Oct 2013 22:15:07 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow Message-ID: <5268122B.9010105@oracle.com> Hello, Please, review the fix: jira: https://bugs.openjdk.java.net/browse/JDK-8027157 webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 This is to support SwingNode. On Windows, in the interop mode, when a popup (JWindow) is shown it doesn't get WM_PAINT native message. The message should trigger adding a dirty component to RepaintManager that will eventually paint it. Currently, a popup is shown blank. Please, see https://javafx-jira.kenai.com/browse/RT-32570 for more details. The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a window owned by JLightweightFrame. Thanks, Anton. From artem.ananiev at oracle.com Wed Oct 23 14:52:38 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 23 Oct 2013 18:52:38 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5268122B.9010105@oracle.com> References: <5268122B.9010105@oracle.com> Message-ID: <5267E2B6.4090105@oracle.com> Hi, Anton, can this code be moved to WLightweightFramePeer? It would help to get rid of the nasty instanceof check. Thanks, Artem On 10/23/2013 10:15 PM, Anton V. Tarasov wrote: > Hello, > > Please, review the fix: > > jira: https://bugs.openjdk.java.net/browse/JDK-8027157 > webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 > > This is to support SwingNode. On Windows, in the interop mode, when a > popup (JWindow) is shown it doesn't get WM_PAINT native message. > The message should trigger adding a dirty component to RepaintManager > that will eventually paint it. > Currently, a popup is shown blank. Please, see > https://javafx-jira.kenai.com/browse/RT-32570 for more details. > > The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a > window owned by JLightweightFrame. > > Thanks, > Anton. From anton.nashatyrev at oracle.com Wed Oct 23 16:18:21 2013 From: anton.nashatyrev at oracle.com (anton nashatyrev) Date: Wed, 23 Oct 2013 20:18:21 +0400 Subject: [8] Review request for 8027066: XMLDecoder in java 7 cannot properly deserialize object arrays Message-ID: <5267F6CD.7010706@oracle.com> Hello, could you please review the following fix: fix: http://cr.openjdk.java.net/~alitvinov/8027066/webrev.01 bug: https://bugs.openjdk.java.net/browse/JDK-8027066 The problem: when serializing-deserializing an object which fields refer to the same array instance, one of the fields is not initialized The reason: The ElementHandler.isArgument() returns false when the serialized element contains 'id' which is our case since the second object field refers the first field value by 'id': First message Second message When the isArgument() returns false the value created isn't passed up to its parent. This issue resolved in the ObjectElementHandler by overriding isArgument() to always return true. Though the same is not done in the ArrayElementHandler. The solution: override the isArgument() in the ArrayElementHandler the same way as in ObjectElementHandler Thanks! Anton. From anthony.petrov at oracle.com Wed Oct 23 16:37:55 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 23 Oct 2013 20:37:55 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5268122B.9010105@oracle.com> References: <5268122B.9010105@oracle.com> Message-ID: <5267FB63.1040104@oracle.com> Hi Anton, Not sure if this matters much, but normally we don't use *.swing.* classes directly from *.awt.* classes to avoid inter-dependencies. It would look better if you could use an approach based on the Class.getName()/Class.getSuperClass() methods here. Also, I don't quite understand why "in case of interop WM_PAINT is never triggered". W/o understanding this, I'm not sure if the current fix is correct. Please elaborate on the root cause of the bug. -- best regards, Anthony On 10/23/2013 10:15 PM, Anton V. Tarasov wrote: > Hello, > > Please, review the fix: > > jira: https://bugs.openjdk.java.net/browse/JDK-8027157 > webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 > > This is to support SwingNode. On Windows, in the interop mode, when a > popup (JWindow) is shown it doesn't get WM_PAINT native message. > The message should trigger adding a dirty component to RepaintManager > that will eventually paint it. > Currently, a popup is shown blank. Please, see > https://javafx-jira.kenai.com/browse/RT-32570 for more details. > > The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a > window owned by JLightweightFrame. > > Thanks, > Anton. From sergey.malenkov at oracle.com Wed Oct 23 16:44:38 2013 From: sergey.malenkov at oracle.com (sergey malenkov) Date: Wed, 23 Oct 2013 20:44:38 +0400 Subject: [8] Review request for 8027066: XMLDecoder in java 7 cannot properly deserialize object arrays In-Reply-To: <5267F6CD.7010706@oracle.com> References: <5267F6CD.7010706@oracle.com> Message-ID: <5267FCF6.6090305@oracle.com> The fix looks fine. It was my fault. SAM On 23.10.2013 20:18, anton nashatyrev wrote: > Hello, > could you please review the following fix: > > fix: http://cr.openjdk.java.net/~alitvinov/8027066/webrev.01 > > bug: https://bugs.openjdk.java.net/browse/JDK-8027066 > > The problem: when serializing-deserializing an object which fields > refer to the same array instance, one of the fields is not initialized > > The reason: The ElementHandler.isArgument() returns false when the > serialized element contains 'id' which is our case since the second > object field refers the first field value by 'id': > > > > > > First message > > > Second message > > > > > > > > > > When the isArgument() returns false the value created isn't passed up > to its parent. This issue resolved in the ObjectElementHandler by > overriding isArgument() to always return true. Though the same is not > done in the ArrayElementHandler. > > The solution: override the isArgument() in the ArrayElementHandler the > same way as in ObjectElementHandler > > Thanks! > Anton. From anton.tarasov at oracle.com Thu Oct 24 10:59:12 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 24 Oct 2013 14:59:12 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5267E2B6.4090105@oracle.com> References: <5268122B.9010105@oracle.com> <5267E2B6.4090105@oracle.com> Message-ID: <5268FD80.5070103@oracle.com> Hi Artem, I'm afraid it can't. I override the show method of an _owned_ window. Thanks, Anton. On 10/23/13 6:52 PM, Artem Ananiev wrote: > Hi, Anton, > > can this code be moved to WLightweightFramePeer? It would help to get > rid of the nasty instanceof check. > > Thanks, > > Artem > > On 10/23/2013 10:15 PM, Anton V. Tarasov wrote: >> Hello, >> >> Please, review the fix: >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >> >> This is to support SwingNode. On Windows, in the interop mode, when a >> popup (JWindow) is shown it doesn't get WM_PAINT native message. >> The message should trigger adding a dirty component to RepaintManager >> that will eventually paint it. >> Currently, a popup is shown blank. Please, see >> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >> >> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >> window owned by JLightweightFrame. >> >> Thanks, >> Anton. From anton.tarasov at oracle.com Thu Oct 24 11:06:35 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 24 Oct 2013 15:06:35 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5267FB63.1040104@oracle.com> References: <5268122B.9010105@oracle.com> <5267FB63.1040104@oracle.com> Message-ID: <5268FF3B.9070200@oracle.com> Hi Anthony, On 10/23/13 8:37 PM, Anthony Petrov wrote: > Hi Anton, > > Not sure if this matters much, but normally we don't use *.swing.* > classes directly from *.awt.* classes to avoid inter-dependencies. It > would look better if you could use an approach based on the > Class.getName()/Class.getSuperClass() methods here. Right, I missed that. Thanks. > > Also, I don't quite understand why "in case of interop WM_PAINT is > never triggered". W/o understanding this, I'm not sure if the current > fix is correct. Please elaborate on the root cause of the bug. Well, I agree we should understand why WM_PAINT is not generated. However, I'm afraid the investigation may take too much time and with no guarantee (that it can't be solved). This is a simple and, imo, harmless workaround which gets the issue solved in jfx8/jdk8. What about leaving the WM_PAINT issue open, but targeting it to the next release (when we have more time to investigate)? Thanks, Anton. > > -- > best regards, > Anthony > > On 10/23/2013 10:15 PM, Anton V. Tarasov wrote: >> Hello, >> >> Please, review the fix: >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >> >> This is to support SwingNode. On Windows, in the interop mode, when a >> popup (JWindow) is shown it doesn't get WM_PAINT native message. >> The message should trigger adding a dirty component to RepaintManager >> that will eventually paint it. >> Currently, a popup is shown blank. Please, see >> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >> >> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >> window owned by JLightweightFrame. >> >> Thanks, >> Anton. From alexandr.scherbatiy at oracle.com Thu Oct 24 09:44:35 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 24 Oct 2013 13:44:35 +0400 Subject: Code review request: 8026929: remove accelerators from policytool resources In-Reply-To: <5266A3D0.1040504@oracle.com> References: <52657C89.1070601@oracle.com> <52666095.4010803@oracle.com> <5266A3D0.1040504@oracle.com> Message-ID: <5268EC03.1080508@oracle.com> The fix looks good for me. It would be better to split long strings on several lines. Thanks, Alexandr. On 10/22/2013 8:12 PM, Leif Samuelsson wrote: > Hi Alexander, > > On 2013-10-22 04:25, Alexander Potochkin wrote: >> Hello Leif >> >> There was a special logic for keyStrokes on MacOS >> inPolicyTool.addMenuItem(), >> could you make sure that the new code correctly set keyStrokes on MacOS? > > That logic is still there, but it was simplified. As long as the > accelerator > string is defined with a single character, it will be set with the > platform > specific shortcut modifier "control" or "meta". If the string is > longer, it > will be passed to KeyStroke.getKeyStroke(String) for parsing. > > Thanks, > Leif > >> Thanks >> alexp >>> Hi All, >>> >>> This is a small additional fix to PolicyTool to move the default >>> accelerators for File->New/Open/Save from the resource bundle to >>> hard coded values in PolicyTool.java. >>> >>> This is done to avoid confusing the translators about the difference >>> between mnemonics and accelerators. Accelerators are typically not >>> localized, but this fix will still allow overriding the values for >>> rare cases, by specifying them in a localized resource bundle. >>> >>> http://cr.openjdk.java.net/~weijun/8026929/webrev.00/ >>> >>> I am the Contributor for this bug fix, and Max (Weijun) will be the >>> Committer. >>> >>> Thanks, >>> Leif >> From alexandr.scherbatiy at oracle.com Thu Oct 24 09:57:04 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 24 Oct 2013 13:57:04 +0400 Subject: [8] Review request for 8027066: XMLDecoder in java 7 cannot properly deserialize object arrays In-Reply-To: <5267F6CD.7010706@oracle.com> References: <5267F6CD.7010706@oracle.com> Message-ID: <5268EEF0.6030709@oracle.com> The fix looks good for me. Thanks, Alexandr. On 10/23/2013 8:18 PM, anton nashatyrev wrote: > Hello, > could you please review the following fix: > > fix: http://cr.openjdk.java.net/~alitvinov/8027066/webrev.01 > > bug: https://bugs.openjdk.java.net/browse/JDK-8027066 > > The problem: when serializing-deserializing an object which fields > refer to the same array instance, one of the fields is not initialized > > The reason: The ElementHandler.isArgument() returns false when the > serialized element contains 'id' which is our case since the second > object field refers the first field value by 'id': > > > > > > First message > > > Second message > > > > > > > > > > When the isArgument() returns false the value created isn't passed up > to its parent. This issue resolved in the ObjectElementHandler by > overriding isArgument() to always return true. Though the same is not > done in the ArrayElementHandler. > > The solution: override the isArgument() in the ArrayElementHandler the > same way as in ObjectElementHandler > > Thanks! > Anton. From anthony.petrov at oracle.com Thu Oct 24 17:00:51 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 24 Oct 2013 17:00:51 +0000 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5268FF3B.9070200@oracle.com> References: <5268122B.9010105@oracle.com> <5267FB63.1040104@oracle.com> <5268FF3B.9070200@oracle.com> Message-ID: <52695243.3070306@oracle.com> On 10/24/2013 11:06 AM, Anton V. Tarasov wrote: > On 10/23/13 8:37 PM, Anthony Petrov wrote: >> Not sure if this matters much, but normally we don't use *.swing.* >> classes directly from *.awt.* classes to avoid inter-dependencies. It >> would look better if you could use an approach based on the >> Class.getName()/Class.getSuperClass() methods here. > Right, I missed that. Thanks. Looking forward to seeing a new webrev. >> Also, I don't quite understand why "in case of interop WM_PAINT is >> never triggered". W/o understanding this, I'm not sure if the current >> fix is correct. Please elaborate on the root cause of the bug. > > Well, I agree we should understand why WM_PAINT is not generated. > However, I'm afraid the investigation may take too much time and with no > guarantee (that it can't be solved). This is a simple and, imo, harmless > workaround which gets the issue solved in jfx8/jdk8. What about leaving > the WM_PAINT issue open, but targeting it to the next release (when we > have more time to investigate)? Yes, I think this is a good option for now. -- best regards, Anthony > > Thanks, > Anton. > > >> >> -- >> best regards, >> Anthony >> >> On 10/23/2013 10:15 PM, Anton V. Tarasov wrote: >>> Hello, >>> >>> Please, review the fix: >>> >>> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >>> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >>> >>> This is to support SwingNode. On Windows, in the interop mode, when a >>> popup (JWindow) is shown it doesn't get WM_PAINT native message. >>> The message should trigger adding a dirty component to RepaintManager >>> that will eventually paint it. >>> Currently, a popup is shown blank. Please, see >>> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >>> >>> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >>> window owned by JLightweightFrame. >>> >>> Thanks, >>> Anton. > From anton.tarasov at oracle.com Thu Oct 24 14:35:08 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 24 Oct 2013 18:35:08 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5268122B.9010105@oracle.com> References: <5268122B.9010105@oracle.com> Message-ID: <5269301C.6050205@oracle.com> Hello, Please look at the new version: http://cr.openjdk.java.net/~ant/RT-32570/webrev.1 It eliminates code dependency b/w awt & swing. Thanks, Anton. On 10/23/13 10:15 PM, Anton V. Tarasov wrote: > Hello, > > Please, review the fix: > > jira: https://bugs.openjdk.java.net/browse/JDK-8027157 > webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 > > This is to support SwingNode. On Windows, in the interop mode, when a > popup (JWindow) is shown it doesn't get WM_PAINT native message. > The message should trigger adding a dirty component to RepaintManager > that will eventually paint it. > Currently, a popup is shown blank. Please, see > https://javafx-jira.kenai.com/browse/RT-32570 for more details. > > The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a > window owned by JLightweightFrame. > > Thanks, > Anton. From artem.ananiev at oracle.com Thu Oct 24 14:59:04 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 24 Oct 2013 18:59:04 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5269301C.6050205@oracle.com> References: <5268122B.9010105@oracle.com> <5269301C.6050205@oracle.com> Message-ID: <526935B8.1020609@oracle.com> Hi, Anton, it looks much better now. Is it possible to create a regression test for this change? Thanks, Artem On 10/24/2013 6:35 PM, Anton V. Tarasov wrote: > Hello, > > Please look at the new version: > > http://cr.openjdk.java.net/~ant/RT-32570/webrev.1 > > It eliminates code dependency b/w awt & swing. > > Thanks, > Anton. > > On 10/23/13 10:15 PM, Anton V. Tarasov wrote: >> Hello, >> >> Please, review the fix: >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >> >> This is to support SwingNode. On Windows, in the interop mode, when a >> popup (JWindow) is shown it doesn't get WM_PAINT native message. >> The message should trigger adding a dirty component to RepaintManager >> that will eventually paint it. >> Currently, a popup is shown blank. Please, see >> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >> >> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >> window owned by JLightweightFrame. >> >> Thanks, >> Anton. > From anthony.petrov at oracle.com Thu Oct 24 20:10:19 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 25 Oct 2013 00:10:19 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <5269301C.6050205@oracle.com> References: <5268122B.9010105@oracle.com> <5269301C.6050205@oracle.com> Message-ID: <52697EAB.1060302@oracle.com> The fix looks fine to me. Thanks. -- best regards, Anthony On 10/24/2013 06:35 PM, Anton V. Tarasov wrote: > Hello, > > Please look at the new version: > > http://cr.openjdk.java.net/~ant/RT-32570/webrev.1 > > It eliminates code dependency b/w awt & swing. > > Thanks, > Anton. > > On 10/23/13 10:15 PM, Anton V. Tarasov wrote: >> Hello, >> >> Please, review the fix: >> >> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >> >> This is to support SwingNode. On Windows, in the interop mode, when a >> popup (JWindow) is shown it doesn't get WM_PAINT native message. >> The message should trigger adding a dirty component to RepaintManager >> that will eventually paint it. >> Currently, a popup is shown blank. Please, see >> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >> >> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >> window owned by JLightweightFrame. >> >> Thanks, >> Anton. > From anton.tarasov at oracle.com Fri Oct 25 13:45:30 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 25 Oct 2013 17:45:30 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <526935B8.1020609@oracle.com> References: <5268122B.9010105@oracle.com> <5269301C.6050205@oracle.com> <526935B8.1020609@oracle.com> Message-ID: <526A75FA.6010400@oracle.com> Hi Artem, On 10/24/13 6:59 PM, Artem Ananiev wrote: > Hi, Anton, > > it looks much better now. Is it possible to create a regression test > for this change? Ok, I did that. Here's the test: http://cr.openjdk.java.net/~ant/RT-32570.test/webrev.0 It persistently passes with the fix (Window/Mac), and fails without (Windows). I'll push it to jfx8 right after this fix gets into jdk8 and jfx8 is switched to build since that jdk8 build (if that is possible). Thanks, Anton. > > Thanks, > > Artem > > On 10/24/2013 6:35 PM, Anton V. Tarasov wrote: >> Hello, >> >> Please look at the new version: >> >> http://cr.openjdk.java.net/~ant/RT-32570/webrev.1 >> >> It eliminates code dependency b/w awt & swing. >> >> Thanks, >> Anton. >> >> On 10/23/13 10:15 PM, Anton V. Tarasov wrote: >>> Hello, >>> >>> Please, review the fix: >>> >>> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >>> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >>> >>> This is to support SwingNode. On Windows, in the interop mode, when a >>> popup (JWindow) is shown it doesn't get WM_PAINT native message. >>> The message should trigger adding a dirty component to RepaintManager >>> that will eventually paint it. >>> Currently, a popup is shown blank. Please, see >>> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >>> >>> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >>> window owned by JLightweightFrame. >>> >>> Thanks, >>> Anton. >> From artem.ananiev at oracle.com Mon Oct 28 16:39:35 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 28 Oct 2013 20:39:35 +0400 Subject: [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow In-Reply-To: <526A75FA.6010400@oracle.com> References: <5268122B.9010105@oracle.com> <5269301C.6050205@oracle.com> <526935B8.1020609@oracle.com> <526A75FA.6010400@oracle.com> Message-ID: <526E9347.9050807@oracle.com> Thanks. Artem On 10/25/2013 5:45 PM, Anton V. Tarasov wrote: > Hi Artem, > > On 10/24/13 6:59 PM, Artem Ananiev wrote: >> Hi, Anton, >> >> it looks much better now. Is it possible to create a regression test >> for this change? > > Ok, I did that. Here's the test: > > http://cr.openjdk.java.net/~ant/RT-32570.test/webrev.0 > > It persistently passes with the fix (Window/Mac), and fails without > (Windows). > > I'll push it to jfx8 right after this fix gets into jdk8 and jfx8 is > switched to build since that jdk8 build (if that is possible). > > Thanks, > Anton. > >> >> Thanks, >> >> Artem >> >> On 10/24/2013 6:35 PM, Anton V. Tarasov wrote: >>> Hello, >>> >>> Please look at the new version: >>> >>> http://cr.openjdk.java.net/~ant/RT-32570/webrev.1 >>> >>> It eliminates code dependency b/w awt & swing. >>> >>> Thanks, >>> Anton. >>> >>> On 10/23/13 10:15 PM, Anton V. Tarasov wrote: >>>> Hello, >>>> >>>> Please, review the fix: >>>> >>>> jira: https://bugs.openjdk.java.net/browse/JDK-8027157 >>>> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0 >>>> >>>> This is to support SwingNode. On Windows, in the interop mode, when a >>>> popup (JWindow) is shown it doesn't get WM_PAINT native message. >>>> The message should trigger adding a dirty component to RepaintManager >>>> that will eventually paint it. >>>> Currently, a popup is shown blank. Please, see >>>> https://javafx-jira.kenai.com/browse/RT-32570 for more details. >>>> >>>> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a >>>> window owned by JLightweightFrame. >>>> >>>> Thanks, >>>> Anton. >>> > From alexander.potochkin at oracle.com Mon Oct 28 16:56:13 2013 From: alexander.potochkin at oracle.com (Alexander Potochkin) Date: Mon, 28 Oct 2013 20:56:13 +0400 Subject: Code review request: 8026929: remove accelerators from policytool resources In-Reply-To: <5266A3D0.1040504@oracle.com> References: <52657C89.1070601@oracle.com> <52666095.4010803@oracle.com> <5266A3D0.1040504@oracle.com> Message-ID: <526E972D.20104@oracle.com> Hello Leif Okay, I approve Thanks alexp On 10/22/2013 8:12 PM, Leif Samuelsson wrote: > Hi Alexander, > > On 2013-10-22 04:25, Alexander Potochkin wrote: >> Hello Leif >> >> There was a special logic for keyStrokes on MacOS >> inPolicyTool.addMenuItem(), >> could you make sure that the new code correctly set keyStrokes on MacOS? > > That logic is still there, but it was simplified. As long as the > accelerator > string is defined with a single character, it will be set with the > platform > specific shortcut modifier "control" or "meta". If the string is > longer, it > will be passed to KeyStroke.getKeyStroke(String) for parsing. > > Thanks, > Leif > >> Thanks >> alexp >>> Hi All, >>> >>> This is a small additional fix to PolicyTool to move the default >>> accelerators for File->New/Open/Save from the resource bundle to >>> hard coded values in PolicyTool.java. >>> >>> This is done to avoid confusing the translators about the difference >>> between mnemonics and accelerators. Accelerators are typically not >>> localized, but this fix will still allow overriding the values for >>> rare cases, by specifying them in a localized resource bundle. >>> >>> http://cr.openjdk.java.net/~weijun/8026929/webrev.00/ >>> >>> I am the Contributor for this bug fix, and Max (Weijun) will be the >>> Committer. >>> >>> Thanks, >>> Leif >>