From anthony.petrov at sun.com Tue Mar 3 02:58:41 2009 From: anthony.petrov at sun.com (anthony.petrov at sun.com) Date: Tue, 03 Mar 2009 10:58:41 +0000 Subject: hg: jdk7/awt/jdk: 6811674: Container.setComponentZOrder throws NPE Message-ID: <20090303105852.F3DCEE639@hg.openjdk.java.net> Changeset: a2082e850247 Author: anthony Date: 2009-03-03 13:54 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/a2082e850247 6811674: Container.setComponentZOrder throws NPE Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Container.java From dmitry.cherepanov at sun.com Wed Mar 4 02:14:14 2009 From: dmitry.cherepanov at sun.com (dmitry.cherepanov at sun.com) Date: Wed, 04 Mar 2009 10:14:14 +0000 Subject: hg: jdk7/awt/jdk: 6809227: poor performance on Panel.Add() method in jdk6 Message-ID: <20090304101442.59651E757@hg.openjdk.java.net> Changeset: ae27b7949714 Author: dcherepanov Date: 2009-03-04 13:05 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/ae27b7949714 6809227: poor performance on Panel.Add() method in jdk6 Reviewed-by: art, anthony ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/java/awt/peer/ContainerPeer.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java ! src/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Panel.cpp ! src/windows/native/sun/windows/awt_Panel.h From artem.ananiev at sun.com Wed Mar 4 07:14:53 2009 From: artem.ananiev at sun.com (artem.ananiev at sun.com) Date: Wed, 04 Mar 2009 15:14:53 +0000 Subject: hg: jdk7/awt/jdk: 6784816: Remove AWT tree lock from Container methods: getComponent, getComponents, getComponentCount Message-ID: <20090304151505.7D4C6E773@hg.openjdk.java.net> Changeset: e7205c5dd3b7 Author: art Date: 2009-03-04 18:10 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/e7205c5dd3b7 6784816: Remove AWT tree lock from Container methods: getComponent, getComponents, getComponentCount Reviewed-by: anthony, dav ! src/share/classes/java/awt/Container.java From roman.kennke at aicas.com Thu Mar 5 04:43:48 2009 From: roman.kennke at aicas.com (Roman Kennke) Date: Thu, 05 Mar 2009 13:43:48 +0100 Subject: Problem with modal Dialog In-Reply-To: <4999C7D0.4030302@aicas.com> References: <4995A5D6.7000902@aicas.com> <4995D8A8.8090408@aicas.com> <271e55d20902131940i269b315bx6f4f048369b1aa25@mail.gmail.com> <4999454A.1090401@aicas.com> <271e55d20902160307l582e13c7y18e9dc72176f2c0c@mail.gmail.com> <49996510.9050104@sun.com> <499969E4.6040108@aicas.com> <49996AFB.9080205@sun.com> <49996EC5.3030905@aicas.com> <49999138.30708@sun.com> <271e55d20902161115n1ec573e0x470a6e668f48bc1@mail.gmail.com> <4999C7D0.4030302@aicas.com> Message-ID: <1236257029.6164.0.camel@moonlight> Hi there, > >>>>>>>> BTW, simply sending this over the EQ is no solution either, because > >>>>>>>> then > >>>>>>>> later it will fail to invokeAndWait(). I will think a little more > >>>>>>>> about > >>>>>>>> this, or maybe anybody has a quick idea? > >>>>>>> Just an idea (have not evaluated it carefully): > >>>>>>> perhaps we should set keepBlockingEDT to false not in > >>>>>>> hideAndDisposeHandler(), > >>>>>>> but in WakingRunnable.run() instead. > >>>>>> I'm looking at this problem at the moment. The problem is the instance > >>>>>> of WakingRunnable is not run on EDT at all - I don't know why. > >>>>> I know why. It is because the DisposeAction is run _immediately_, before > >>>>> the WakingRunnable had a chance. This DisposeAction calls removeNotify(), > >>>>> which leads to all events on the EQ that are related to the Dialog beeing > >>>>> discarded. > >>>> Could you, please, point to the place where all the events are discarded? > >>>> I don't see any. > >>> In Component.removeNotify(), we call this: > >>> > >>> Toolkit.getEventQueue().removeSourceEvents(this, false); > >> OK, I see. What a wonderful code... > >> > >>> which removes all events related to the component. removeNotify() is > >>> called from inside the DisposeAction. > >> For this particular case it's enough to add some additional check to > >> hideAndDisposeHandler: > >> > >> if (showAppContext != curAppContext) { > >> // Wake up event dispatch thread on which the dialog was > >> // initially shown > >> SunToolkit.postEvent(showAppContext, wakingEvent); > >> showAppContext = null; > >> + } else if (EventQueue.isDispatchThread()) { > >> + waking.run(); > >> } else { > >> Toolkit.getEventQueue().postEvent(wakingEvent); > >> } > > > > this change will fix this particular test, but the same problem may > > exists even when > > we call hide() not on EDT, it is just a little bit harder to write > > test for this ;) > > > > What about moving resetting keepBlockingEDT to WakingEvent.run(), or, > > perhaps, we can simply change > > target of WakingEvent from a dialog to toolkit. > > What do you think? > > Setting the target of the WakingEvent to the toolkit sounds like an > elegant and efficient solution to me. Simply executing the event > directly when on the EDT (as Artem proposed) sounds like crying for more > side-effects. So what should we do about it? /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From anton.tarasov at sun.com Wed Mar 11 00:37:57 2009 From: anton.tarasov at sun.com (anton.tarasov at sun.com) Date: Wed, 11 Mar 2009 07:37:57 +0000 Subject: hg: jdk7/awt/jdk: 6806217: implement synthetic focus model for MS Windows Message-ID: <20090311073823.46E9FEC5B@hg.openjdk.java.net> Changeset: 4dc625187820 Author: ant Date: 2009-03-10 18:33 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/4dc625187820 6806217: implement synthetic focus model for MS Windows Reviewed-by: art, dcherepanov ! make/sun/awt/make.depend ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/HeadlessToolkit.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/windows/classes/sun/awt/windows/WChoicePeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java + src/windows/classes/sun/awt/windows/WKeyboardFocusManagerPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java ! src/windows/native/sun/windows/awt_Button.cpp ! src/windows/native/sun/windows/awt_Button.h ! src/windows/native/sun/windows/awt_Canvas.cpp ! src/windows/native/sun/windows/awt_Checkbox.cpp ! src/windows/native/sun/windows/awt_Checkbox.h ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Choice.h ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h ! src/windows/native/sun/windows/awt_KeyboardFocusManager.cpp - src/windows/native/sun/windows/awt_KeyboardFocusManager.h ! src/windows/native/sun/windows/awt_List.cpp ! src/windows/native/sun/windows/awt_List.h ! src/windows/native/sun/windows/awt_PrintDialog.cpp ! src/windows/native/sun/windows/awt_ScrollPane.cpp ! src/windows/native/sun/windows/awt_ScrollPane.h ! src/windows/native/sun/windows/awt_Scrollbar.cpp ! src/windows/native/sun/windows/awt_Scrollbar.h ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h ! src/windows/native/sun/windows/awt_TextField.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h ! src/windows/native/sun/windows/awtmsg.h + test/java/awt/Focus/ClearGlobalFocusOwnerTest/ClearGlobalFocusOwnerTest.java ! test/java/awt/Focus/IconifiedFrameFocusChangeTest/IconifiedFrameFocusChangeTest.java + test/java/awt/Focus/RemoveAfterRequest/RemoveAfterRequest.java From anton.tarasov at sun.com Wed Mar 11 06:17:42 2009 From: anton.tarasov at sun.com (anton.tarasov at sun.com) Date: Wed, 11 Mar 2009 13:17:42 +0000 Subject: hg: jdk7/awt/jdk: 6815946: regression: failed to build MToolkit Message-ID: <20090311131754.7DB16EC69@hg.openjdk.java.net> Changeset: 04b368454df3 Author: ant Date: 2009-03-11 16:11 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/04b368454df3 6815946: regression: failed to build MToolkit Reviewed-by: anthony ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/motif/MToolkit.java From dmitry.cherepanov at sun.com Fri Mar 13 08:16:59 2009 From: dmitry.cherepanov at sun.com (dmitry.cherepanov at sun.com) Date: Fri, 13 Mar 2009 15:16:59 +0000 Subject: hg: jdk7/awt/jdk: 6805897: Gap present between the choice and its drop down list in Jdk 7 build for a non resizable frame. Message-ID: <20090313151725.0C973EE3F@hg.openjdk.java.net> Changeset: 6df5f5fb5174 Author: dcherepanov Date: 2009-03-13 18:07 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/6df5f5fb5174 6805897: Gap present between the choice and its drop down list in Jdk 7 build for a non resizable frame. Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java From Artem.Ananiev at Sun.COM Thu Mar 19 02:27:44 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Thu, 19 Mar 2009 12:27:44 +0300 Subject: Problem with modal Dialog In-Reply-To: <1236257029.6164.0.camel@moonlight> References: <4995A5D6.7000902@aicas.com> <4995D8A8.8090408@aicas.com> <271e55d20902131940i269b315bx6f4f048369b1aa25@mail.gmail.com> <4999454A.1090401@aicas.com> <271e55d20902160307l582e13c7y18e9dc72176f2c0c@mail.gmail.com> <49996510.9050104@sun.com> <499969E4.6040108@aicas.com> <49996AFB.9080205@sun.com> <49996EC5.3030905@aicas.com> <49999138.30708@sun.com> <271e55d20902161115n1ec573e0x470a6e668f48bc1@mail.gmail.com> <4999C7D0.4030302@aicas.com> <1236257029.6164.0.camel@moonlight> Message-ID: <49C21010.8010001@sun.com> Roman Kennke wrote: > Hi there, > >>>>>>>>>> BTW, simply sending this over the EQ is no solution either, because >>>>>>>>>> then >>>>>>>>>> later it will fail to invokeAndWait(). I will think a little more >>>>>>>>>> about >>>>>>>>>> this, or maybe anybody has a quick idea? >>>>>>>>> Just an idea (have not evaluated it carefully): >>>>>>>>> perhaps we should set keepBlockingEDT to false not in >>>>>>>>> hideAndDisposeHandler(), >>>>>>>>> but in WakingRunnable.run() instead. >>>>>>>> I'm looking at this problem at the moment. The problem is the instance >>>>>>>> of WakingRunnable is not run on EDT at all - I don't know why. >>>>>>> I know why. It is because the DisposeAction is run _immediately_, before >>>>>>> the WakingRunnable had a chance. This DisposeAction calls removeNotify(), >>>>>>> which leads to all events on the EQ that are related to the Dialog beeing >>>>>>> discarded. >>>>>> Could you, please, point to the place where all the events are discarded? >>>>>> I don't see any. >>>>> In Component.removeNotify(), we call this: >>>>> >>>>> Toolkit.getEventQueue().removeSourceEvents(this, false); >>>> OK, I see. What a wonderful code... >>>> >>>>> which removes all events related to the component. removeNotify() is >>>>> called from inside the DisposeAction. >>>> For this particular case it's enough to add some additional check to >>>> hideAndDisposeHandler: >>>> >>>> if (showAppContext != curAppContext) { >>>> // Wake up event dispatch thread on which the dialog was >>>> // initially shown >>>> SunToolkit.postEvent(showAppContext, wakingEvent); >>>> showAppContext = null; >>>> + } else if (EventQueue.isDispatchThread()) { >>>> + waking.run(); >>>> } else { >>>> Toolkit.getEventQueue().postEvent(wakingEvent); >>>> } >>> this change will fix this particular test, but the same problem may >>> exists even when >>> we call hide() not on EDT, it is just a little bit harder to write >>> test for this ;) >>> >>> What about moving resetting keepBlockingEDT to WakingEvent.run(), or, >>> perhaps, we can simply change >>> target of WakingEvent from a dialog to toolkit. >>> What do you think? >> Setting the target of the WakingEvent to the toolkit sounds like an >> elegant and efficient solution to me. Simply executing the event >> directly when on the EDT (as Artem proposed) sounds like crying for more >> side-effects. > > So what should we do about it? I'm fine with changing event's target to Toolkit. Could you send a patch for review then? Thanks, Artem > /Roman > From roman.kennke at aicas.com Thu Mar 19 04:31:24 2009 From: roman.kennke at aicas.com (Roman Kennke) Date: Thu, 19 Mar 2009 12:31:24 +0100 Subject: [PATCH]: Fix modal dialog (was Problem with modal Dialog) In-Reply-To: <49C21010.8010001@sun.com> References: <4995A5D6.7000902@aicas.com> <4995D8A8.8090408@aicas.com> <271e55d20902131940i269b315bx6f4f048369b1aa25@mail.gmail.com> <4999454A.1090401@aicas.com> <271e55d20902160307l582e13c7y18e9dc72176f2c0c@mail.gmail.com> <49996510.9050104@sun.com> <499969E4.6040108@aicas.com> <49996AFB.9080205@sun.com> <49996EC5.3030905@aicas.com> <49999138.30708@sun.com> <271e55d20902161115n1ec573e0x470a6e668f48bc1@mail.gmail.com> <4999C7D0.4030302@aicas.com> <1236257029.6164.0.camel@moonlight> <49C21010.8010001@sun.com> Message-ID: <1237462284.9445.4.camel@moonlight> So this is the patch I propose to fix this modal dialog problem. /Roman Am Donnerstag, den 19.03.2009, 12:27 +0300 schrieb Artem Ananiev: > Roman Kennke wrote: > > Hi there, > > > >>>>>>>>>> BTW, simply sending this over the EQ is no solution either, because > >>>>>>>>>> then > >>>>>>>>>> later it will fail to invokeAndWait(). I will think a little more > >>>>>>>>>> about > >>>>>>>>>> this, or maybe anybody has a quick idea? > >>>>>>>>> Just an idea (have not evaluated it carefully): > >>>>>>>>> perhaps we should set keepBlockingEDT to false not in > >>>>>>>>> hideAndDisposeHandler(), > >>>>>>>>> but in WakingRunnable.run() instead. > >>>>>>>> I'm looking at this problem at the moment. The problem is the instance > >>>>>>>> of WakingRunnable is not run on EDT at all - I don't know why. > >>>>>>> I know why. It is because the DisposeAction is run _immediately_, before > >>>>>>> the WakingRunnable had a chance. This DisposeAction calls removeNotify(), > >>>>>>> which leads to all events on the EQ that are related to the Dialog beeing > >>>>>>> discarded. > >>>>>> Could you, please, point to the place where all the events are discarded? > >>>>>> I don't see any. > >>>>> In Component.removeNotify(), we call this: > >>>>> > >>>>> Toolkit.getEventQueue().removeSourceEvents(this, false); > >>>> OK, I see. What a wonderful code... > >>>> > >>>>> which removes all events related to the component. removeNotify() is > >>>>> called from inside the DisposeAction. > >>>> For this particular case it's enough to add some additional check to > >>>> hideAndDisposeHandler: > >>>> > >>>> if (showAppContext != curAppContext) { > >>>> // Wake up event dispatch thread on which the dialog was > >>>> // initially shown > >>>> SunToolkit.postEvent(showAppContext, wakingEvent); > >>>> showAppContext = null; > >>>> + } else if (EventQueue.isDispatchThread()) { > >>>> + waking.run(); > >>>> } else { > >>>> Toolkit.getEventQueue().postEvent(wakingEvent); > >>>> } > >>> this change will fix this particular test, but the same problem may > >>> exists even when > >>> we call hide() not on EDT, it is just a little bit harder to write > >>> test for this ;) > >>> > >>> What about moving resetting keepBlockingEDT to WakingEvent.run(), or, > >>> perhaps, we can simply change > >>> target of WakingEvent from a dialog to toolkit. > >>> What do you think? > >> Setting the target of the WakingEvent to the toolkit sounds like an > >> elegant and efficient solution to me. Simply executing the event > >> directly when on the EDT (as Artem proposed) sounds like crying for more > >> side-effects. > > > > So what should we do about it? > > I'm fine with changing event's target to Toolkit. Could you send a patch > for review then? > > Thanks, > > Artem > > > /Roman > > -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt -------------- next part -------------- diff --git a/src/share/classes/java/awt/Dialog.java b/src/share/classes/java/awt/Dialog.java --- a/src/share/classes/java/awt/Dialog.java +++ b/src/share/classes/java/awt/Dialog.java @@ -1226,7 +1226,7 @@ synchronized (getTreeLock()) { if (keepBlockingEDT) { keepBlockingEDT = false; - PeerEvent wakingEvent = new PeerEvent(this, new WakingRunnable(), PeerEvent.PRIORITY_EVENT); + PeerEvent wakingEvent = new PeerEvent(getToolkit(), new WakingRunnable(), PeerEvent.PRIORITY_EVENT); AppContext curAppContext = AppContext.getAppContext(); if (showAppContext != curAppContext) { // Wake up event dispatch thread on which the dialog was From dmitry.cherepanov at sun.com Fri Mar 20 01:41:15 2009 From: dmitry.cherepanov at sun.com (dmitry.cherepanov at sun.com) Date: Fri, 20 Mar 2009 08:41:15 +0000 Subject: hg: jdk7/awt/jdk: 6774258: api/java_awt/Component/index.html#PaintUpdate fails randomly Message-ID: <20090320084138.929CBE4FF@hg.openjdk.java.net> Changeset: c58f41b4bfbd Author: dcherepanov Date: 2009-03-20 08:41 -0400 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/c58f41b4bfbd 6774258: api/java_awt/Component/index.html#PaintUpdate fails randomly Reviewed-by: art ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java + test/java/awt/Component/NoUpdateUponShow/NoUpdateUponShow.java From dmitry.cherepanov at sun.com Mon Mar 23 02:08:11 2009 From: dmitry.cherepanov at sun.com (dmitry.cherepanov at sun.com) Date: Mon, 23 Mar 2009 09:08:11 +0000 Subject: hg: jdk7/awt/jdk: 6516404: regression: Choice vertical scrollbar is not seen when the item in the choice is increased more than Message-ID: <20090323090830.DE1D4E6D1@hg.openjdk.java.net> Changeset: 55f02057dc37 Author: dcherepanov Date: 2009-03-23 11:59 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/55f02057dc37 6516404: regression: Choice vertical scrollbar is not seen when the item in the choice is increased more than Reviewed-by: art, dav ! src/windows/native/sun/windows/awt_Choice.cpp From dmitry.cherepanov at sun.com Mon Mar 23 02:40:47 2009 From: dmitry.cherepanov at sun.com (dmitry.cherepanov at sun.com) Date: Mon, 23 Mar 2009 09:40:47 +0000 Subject: hg: jdk7/awt/jdk: 6730447: Support for high resolution mouse wheel is still incomplete. AWT panel needs to be supported Message-ID: <20090323094059.A7CF9E6DF@hg.openjdk.java.net> Changeset: adaee9531504 Author: dcherepanov Date: 2009-03-23 09:47 -0400 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/adaee9531504 6730447: Support for high resolution mouse wheel is still incomplete. AWT panel needs to be supported Reviewed-by: art, dav ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h + test/java/awt/event/MouseEvent/AWTPanelSmoothWheel/AWTPanelSmoothWheel.html + test/java/awt/event/MouseEvent/AWTPanelSmoothWheel/AWTPanelSmoothWheel.java From Artem.Ananiev at Sun.COM Tue Mar 24 03:56:47 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Tue, 24 Mar 2009 13:56:47 +0300 Subject: [PATCH]: Fix modal dialog (was Problem with modal Dialog) In-Reply-To: <1237462284.9445.4.camel@moonlight> References: <4995A5D6.7000902@aicas.com> <4995D8A8.8090408@aicas.com> <271e55d20902131940i269b315bx6f4f048369b1aa25@mail.gmail.com> <4999454A.1090401@aicas.com> <271e55d20902160307l582e13c7y18e9dc72176f2c0c@mail.gmail.com> <49996510.9050104@sun.com> <499969E4.6040108@aicas.com> <49996AFB.9080205@sun.com> <49996EC5.3030905@aicas.com> <49999138.30708@sun.com> <271e55d20902161115n1ec573e0x470a6e668f48bc1@mail.gmail.com> <4999C7D0.4030302@aicas.com> <1236257029.6164.0.camel@moonlight> <49C21010.8010001@sun.com> <1237462284.9445.4.camel@moonlight> Message-ID: <49C8BC6F.3060505@sun.com> Looks fine. Thanks, Artem Roman Kennke wrote: > So this is the patch I propose to fix this modal dialog problem. > > /Roman > > Am Donnerstag, den 19.03.2009, 12:27 +0300 schrieb Artem Ananiev: >> Roman Kennke wrote: >>> Hi there, >>> >>>>>>>>>>>> BTW, simply sending this over the EQ is no solution either, because >>>>>>>>>>>> then >>>>>>>>>>>> later it will fail to invokeAndWait(). I will think a little more >>>>>>>>>>>> about >>>>>>>>>>>> this, or maybe anybody has a quick idea? >>>>>>>>>>> Just an idea (have not evaluated it carefully): >>>>>>>>>>> perhaps we should set keepBlockingEDT to false not in >>>>>>>>>>> hideAndDisposeHandler(), >>>>>>>>>>> but in WakingRunnable.run() instead. >>>>>>>>>> I'm looking at this problem at the moment. The problem is the instance >>>>>>>>>> of WakingRunnable is not run on EDT at all - I don't know why. >>>>>>>>> I know why. It is because the DisposeAction is run _immediately_, before >>>>>>>>> the WakingRunnable had a chance. This DisposeAction calls removeNotify(), >>>>>>>>> which leads to all events on the EQ that are related to the Dialog beeing >>>>>>>>> discarded. >>>>>>>> Could you, please, point to the place where all the events are discarded? >>>>>>>> I don't see any. >>>>>>> In Component.removeNotify(), we call this: >>>>>>> >>>>>>> Toolkit.getEventQueue().removeSourceEvents(this, false); >>>>>> OK, I see. What a wonderful code... >>>>>> >>>>>>> which removes all events related to the component. removeNotify() is >>>>>>> called from inside the DisposeAction. >>>>>> For this particular case it's enough to add some additional check to >>>>>> hideAndDisposeHandler: >>>>>> >>>>>> if (showAppContext != curAppContext) { >>>>>> // Wake up event dispatch thread on which the dialog was >>>>>> // initially shown >>>>>> SunToolkit.postEvent(showAppContext, wakingEvent); >>>>>> showAppContext = null; >>>>>> + } else if (EventQueue.isDispatchThread()) { >>>>>> + waking.run(); >>>>>> } else { >>>>>> Toolkit.getEventQueue().postEvent(wakingEvent); >>>>>> } >>>>> this change will fix this particular test, but the same problem may >>>>> exists even when >>>>> we call hide() not on EDT, it is just a little bit harder to write >>>>> test for this ;) >>>>> >>>>> What about moving resetting keepBlockingEDT to WakingEvent.run(), or, >>>>> perhaps, we can simply change >>>>> target of WakingEvent from a dialog to toolkit. >>>>> What do you think? >>>> Setting the target of the WakingEvent to the toolkit sounds like an >>>> elegant and efficient solution to me. Simply executing the event >>>> directly when on the EDT (as Artem proposed) sounds like crying for more >>>> side-effects. >>> So what should we do about it? >> I'm fine with changing event's target to Toolkit. Could you send a patch >> for review then? >> >> Thanks, >> >> Artem >> >>> /Roman >>> From roman.kennke at aicas.com Tue Mar 24 04:09:02 2009 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 24 Mar 2009 12:09:02 +0100 Subject: [PATCH]: Fix modal dialog (was Problem with modal Dialog) In-Reply-To: <49C8BC6F.3060505@sun.com> References: <4995A5D6.7000902@aicas.com> <4995D8A8.8090408@aicas.com> <271e55d20902131940i269b315bx6f4f048369b1aa25@mail.gmail.com> <4999454A.1090401@aicas.com> <271e55d20902160307l582e13c7y18e9dc72176f2c0c@mail.gmail.com> <49996510.9050104@sun.com> <499969E4.6040108@aicas.com> <49996AFB.9080205@sun.com> <49996EC5.3030905@aicas.com> <49999138.30708@sun.com> <271e55d20902161115n1ec573e0x470a6e668f48bc1@mail.gmail.com> <4999C7D0.4030302@aicas.com> <1236257029.6164.0.camel@moonlight> <49C21010.8010001@sun.com> <1237462284.9445.4.camel@moonlight> <49C8BC6F.3060505@sun.com> Message-ID: <1237892942.6754.1.camel@saturn> Hi Artem, > Looks fine. Great. Do we have a bug report that I can reference in my commit message? And do I need another review before committing? /Roman > > Thanks, > > Artem > > Roman Kennke wrote: > > So this is the patch I propose to fix this modal dialog problem. > > > > /Roman > > > > Am Donnerstag, den 19.03.2009, 12:27 +0300 schrieb Artem Ananiev: > >> Roman Kennke wrote: > >>> Hi there, > >>> > >>>>>>>>>>>> BTW, simply sending this over the EQ is no solution either, because > >>>>>>>>>>>> then > >>>>>>>>>>>> later it will fail to invokeAndWait(). I will think a little more > >>>>>>>>>>>> about > >>>>>>>>>>>> this, or maybe anybody has a quick idea? > >>>>>>>>>>> Just an idea (have not evaluated it carefully): > >>>>>>>>>>> perhaps we should set keepBlockingEDT to false not in > >>>>>>>>>>> hideAndDisposeHandler(), > >>>>>>>>>>> but in WakingRunnable.run() instead. > >>>>>>>>>> I'm looking at this problem at the moment. The problem is the instance > >>>>>>>>>> of WakingRunnable is not run on EDT at all - I don't know why. > >>>>>>>>> I know why. It is because the DisposeAction is run _immediately_, before > >>>>>>>>> the WakingRunnable had a chance. This DisposeAction calls removeNotify(), > >>>>>>>>> which leads to all events on the EQ that are related to the Dialog beeing > >>>>>>>>> discarded. > >>>>>>>> Could you, please, point to the place where all the events are discarded? > >>>>>>>> I don't see any. > >>>>>>> In Component.removeNotify(), we call this: > >>>>>>> > >>>>>>> Toolkit.getEventQueue().removeSourceEvents(this, false); > >>>>>> OK, I see. What a wonderful code... > >>>>>> > >>>>>>> which removes all events related to the component. removeNotify() is > >>>>>>> called from inside the DisposeAction. > >>>>>> For this particular case it's enough to add some additional check to > >>>>>> hideAndDisposeHandler: > >>>>>> > >>>>>> if (showAppContext != curAppContext) { > >>>>>> // Wake up event dispatch thread on which the dialog was > >>>>>> // initially shown > >>>>>> SunToolkit.postEvent(showAppContext, wakingEvent); > >>>>>> showAppContext = null; > >>>>>> + } else if (EventQueue.isDispatchThread()) { > >>>>>> + waking.run(); > >>>>>> } else { > >>>>>> Toolkit.getEventQueue().postEvent(wakingEvent); > >>>>>> } > >>>>> this change will fix this particular test, but the same problem may > >>>>> exists even when > >>>>> we call hide() not on EDT, it is just a little bit harder to write > >>>>> test for this ;) > >>>>> > >>>>> What about moving resetting keepBlockingEDT to WakingEvent.run(), or, > >>>>> perhaps, we can simply change > >>>>> target of WakingEvent from a dialog to toolkit. > >>>>> What do you think? > >>>> Setting the target of the WakingEvent to the toolkit sounds like an > >>>> elegant and efficient solution to me. Simply executing the event > >>>> directly when on the EDT (as Artem proposed) sounds like crying for more > >>>> side-effects. > >>> So what should we do about it? > >> I'm fine with changing event's target to Toolkit. Could you send a patch > >> for review then? > >> > >> Thanks, > >> > >> Artem > >> > >>> /Roman > >>> -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From Artem.Ananiev at Sun.COM Tue Mar 24 05:04:12 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Tue, 24 Mar 2009 15:04:12 +0300 Subject: [PATCH]: Fix modal dialog (was Problem with modal Dialog) In-Reply-To: <1237892942.6754.1.camel@saturn> References: <4995A5D6.7000902@aicas.com> <4995D8A8.8090408@aicas.com> <271e55d20902131940i269b315bx6f4f048369b1aa25@mail.gmail.com> <4999454A.1090401@aicas.com> <271e55d20902160307l582e13c7y18e9dc72176f2c0c@mail.gmail.com> <49996510.9050104@sun.com> <499969E4.6040108@aicas.com> <49996AFB.9080205@sun.com> <49996EC5.3030905@aicas.com> <49999138.30708@sun.com> <271e55d20902161115n1ec573e0x470a6e668f48bc1@mail.gmail.com> <4999C7D0.4030302@aicas.com> <1236257029.6164.0.camel@moonlight> <49C21010.8010001@sun.com> <1237462284.9445.4.camel@moonlight> <49C8BC6F.3060505@sun.com> <1237892942.6754.1.camel@saturn> Message-ID: <49C8CC3C.5020108@sun.com> Roman Kennke wrote: > Hi Artem, > >> Looks fine. > > Great. Do we have a bug report that I can reference in my commit > message? And do I need another review before committing? I filed a bug some time ago: 6809233: Modal dialog blocks calling thread after it is hidden and disposed I hope Oleg will look at your patch soon, and this will be enough to commit the change. For all the subsequent bugs, new OpenJDK tools: http://bugs.openjdk.java.net and https://cr.openjdk.java.net should be used. Thanks, Artem > /Roman > >> Thanks, >> >> Artem >> >> Roman Kennke wrote: >>> So this is the patch I propose to fix this modal dialog problem. >>> >>> /Roman >>> >>> Am Donnerstag, den 19.03.2009, 12:27 +0300 schrieb Artem Ananiev: >>>> Roman Kennke wrote: >>>>> Hi there, >>>>> >>>>>>>>>>>>>> BTW, simply sending this over the EQ is no solution either, because >>>>>>>>>>>>>> then >>>>>>>>>>>>>> later it will fail to invokeAndWait(). I will think a little more >>>>>>>>>>>>>> about >>>>>>>>>>>>>> this, or maybe anybody has a quick idea? >>>>>>>>>>>>> Just an idea (have not evaluated it carefully): >>>>>>>>>>>>> perhaps we should set keepBlockingEDT to false not in >>>>>>>>>>>>> hideAndDisposeHandler(), >>>>>>>>>>>>> but in WakingRunnable.run() instead. >>>>>>>>>>>> I'm looking at this problem at the moment. The problem is the instance >>>>>>>>>>>> of WakingRunnable is not run on EDT at all - I don't know why. >>>>>>>>>>> I know why. It is because the DisposeAction is run _immediately_, before >>>>>>>>>>> the WakingRunnable had a chance. This DisposeAction calls removeNotify(), >>>>>>>>>>> which leads to all events on the EQ that are related to the Dialog beeing >>>>>>>>>>> discarded. >>>>>>>>>> Could you, please, point to the place where all the events are discarded? >>>>>>>>>> I don't see any. >>>>>>>>> In Component.removeNotify(), we call this: >>>>>>>>> >>>>>>>>> Toolkit.getEventQueue().removeSourceEvents(this, false); >>>>>>>> OK, I see. What a wonderful code... >>>>>>>> >>>>>>>>> which removes all events related to the component. removeNotify() is >>>>>>>>> called from inside the DisposeAction. >>>>>>>> For this particular case it's enough to add some additional check to >>>>>>>> hideAndDisposeHandler: >>>>>>>> >>>>>>>> if (showAppContext != curAppContext) { >>>>>>>> // Wake up event dispatch thread on which the dialog was >>>>>>>> // initially shown >>>>>>>> SunToolkit.postEvent(showAppContext, wakingEvent); >>>>>>>> showAppContext = null; >>>>>>>> + } else if (EventQueue.isDispatchThread()) { >>>>>>>> + waking.run(); >>>>>>>> } else { >>>>>>>> Toolkit.getEventQueue().postEvent(wakingEvent); >>>>>>>> } >>>>>>> this change will fix this particular test, but the same problem may >>>>>>> exists even when >>>>>>> we call hide() not on EDT, it is just a little bit harder to write >>>>>>> test for this ;) >>>>>>> >>>>>>> What about moving resetting keepBlockingEDT to WakingEvent.run(), or, >>>>>>> perhaps, we can simply change >>>>>>> target of WakingEvent from a dialog to toolkit. >>>>>>> What do you think? >>>>>> Setting the target of the WakingEvent to the toolkit sounds like an >>>>>> elegant and efficient solution to me. Simply executing the event >>>>>> directly when on the EDT (as Artem proposed) sounds like crying for more >>>>>> side-effects. >>>>> So what should we do about it? >>>> I'm fine with changing event's target to Toolkit. Could you send a patch >>>> for review then? >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>>> /Roman >>>>> From son.two at gmail.com Tue Mar 24 06:31:07 2009 From: son.two at gmail.com (Oleg Sukhodolsky) Date: Tue, 24 Mar 2009 16:31:07 +0300 Subject: [PATCH]: Fix modal dialog (was Problem with modal Dialog) In-Reply-To: <49C8CC3C.5020108@sun.com> References: <4995A5D6.7000902@aicas.com> <49999138.30708@sun.com> <271e55d20902161115n1ec573e0x470a6e668f48bc1@mail.gmail.com> <4999C7D0.4030302@aicas.com> <1236257029.6164.0.camel@moonlight> <49C21010.8010001@sun.com> <1237462284.9445.4.camel@moonlight> <49C8BC6F.3060505@sun.com> <1237892942.6754.1.camel@saturn> <49C8CC3C.5020108@sun.com> Message-ID: <271e55d20903240631m37ac1ae7t8899223fe0b7f1fb@mail.gmail.com> 2009/3/24 Artem Ananiev : > > Roman Kennke wrote: >> >> Hi Artem, >> >>> Looks fine. >> >> Great. Do we have a bug report that I can reference in my commit >> message? And do I need another review before committing? > > I filed a bug some time ago: > > 6809233: Modal dialog blocks calling thread after it is hidden and disposed > > I hope Oleg will look at your patch soon, and this will be enough to commit > the change. For all the subsequent bugs, new OpenJDK tools: The fix looks fine for me. (It is just a little surprise that someone still waits my reviews for AWT fixes ;) Oleg. > > http://bugs.openjdk.java.net > > and > > https://cr.openjdk.java.net > > should be used. > > Thanks, > > Artem > >> /Roman >> >>> Thanks, >>> >>> Artem >>> >>> Roman Kennke wrote: >>>> >>>> So this is the patch I propose to fix this modal dialog problem. >>>> >>>> /Roman >>>> >>>> Am Donnerstag, den 19.03.2009, 12:27 +0300 schrieb Artem Ananiev: >>>>> >>>>> Roman Kennke wrote: >>>>>> >>>>>> Hi there, >>>>>> >>>>>>>>>>>>>>> BTW, simply sending this over the EQ is no solution either, >>>>>>>>>>>>>>> because >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>> later it will fail to invokeAndWait(). I will think a little >>>>>>>>>>>>>>> more >>>>>>>>>>>>>>> about >>>>>>>>>>>>>>> this, or maybe anybody has a quick idea? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just an idea (have not evaluated it carefully): >>>>>>>>>>>>>> perhaps we should set keepBlockingEDT to false not in >>>>>>>>>>>>>> hideAndDisposeHandler(), >>>>>>>>>>>>>> but in WakingRunnable.run() instead. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm looking at this problem at the moment. The problem is the >>>>>>>>>>>>> instance >>>>>>>>>>>>> of WakingRunnable is not run on EDT at all - I don't know why. >>>>>>>>>>>> >>>>>>>>>>>> I know why. It is because the DisposeAction is run >>>>>>>>>>>> _immediately_, before >>>>>>>>>>>> the WakingRunnable had a chance. This DisposeAction calls >>>>>>>>>>>> removeNotify(), >>>>>>>>>>>> which leads to all events on the EQ that are related to the >>>>>>>>>>>> Dialog beeing >>>>>>>>>>>> discarded. >>>>>>>>>>> >>>>>>>>>>> Could you, please, point to the place where all the events are >>>>>>>>>>> discarded? >>>>>>>>>>> I don't see any. >>>>>>>>>> >>>>>>>>>> In Component.removeNotify(), we call this: >>>>>>>>>> >>>>>>>>>> Toolkit.getEventQueue().removeSourceEvents(this, false); >>>>>>>>> >>>>>>>>> OK, I see. What a wonderful code... >>>>>>>>> >>>>>>>>>> which removes all events related to the component. removeNotify() >>>>>>>>>> is >>>>>>>>>> called from inside the DisposeAction. >>>>>>>>> >>>>>>>>> For this particular case it's enough to add some additional check >>>>>>>>> to >>>>>>>>> hideAndDisposeHandler: >>>>>>>>> >>>>>>>>> ? ? ? ?if (showAppContext != curAppContext) { >>>>>>>>> ? ? ? ? ? ?// Wake up event dispatch thread on which the dialog was >>>>>>>>> ? ? ? ? ? ?// initially shown >>>>>>>>> ? ? ? ? ? ?SunToolkit.postEvent(showAppContext, wakingEvent); >>>>>>>>> ? ? ? ? ? ?showAppContext = null; >>>>>>>>> + ? ? ? ?} else if (EventQueue.isDispatchThread()) { >>>>>>>>> + ? ? ? ? ? ?waking.run(); >>>>>>>>> ? ? ? ?} else { >>>>>>>>> ? ? ? ? ? ?Toolkit.getEventQueue().postEvent(wakingEvent); >>>>>>>>> ? ? ? ?} >>>>>>>> >>>>>>>> this change will fix this particular test, but the same problem may >>>>>>>> exists even when >>>>>>>> we call hide() not on EDT, it is just a little bit harder to write >>>>>>>> test for this ;) >>>>>>>> >>>>>>>> What about moving resetting keepBlockingEDT to WakingEvent.run(), >>>>>>>> or, >>>>>>>> perhaps, we can simply change >>>>>>>> target of WakingEvent from a dialog to toolkit. >>>>>>>> What do you think? >>>>>>> >>>>>>> Setting the target of the WakingEvent to the toolkit sounds like an >>>>>>> elegant and efficient solution to me. Simply executing the event directly >>>>>>> when on the EDT (as Artem proposed) sounds like crying for more >>>>>>> side-effects. >>>>>> >>>>>> So what should we do about it? >>>>> >>>>> I'm fine with changing event's target to Toolkit. Could you send a >>>>> patch for review then? >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>>> /Roman >>>>>> > From roman.kennke at aicas.com Tue Mar 24 06:50:11 2009 From: roman.kennke at aicas.com (Roman Kennke) Date: Tue, 24 Mar 2009 14:50:11 +0100 Subject: [PATCH]: Fix modal dialog (was Problem with modal Dialog) In-Reply-To: <271e55d20903240631m37ac1ae7t8899223fe0b7f1fb@mail.gmail.com> References: <4995A5D6.7000902@aicas.com> <49999138.30708@sun.com> <271e55d20902161115n1ec573e0x470a6e668f48bc1@mail.gmail.com> <4999C7D0.4030302@aicas.com> <1236257029.6164.0.camel@moonlight> <49C21010.8010001@sun.com> <1237462284.9445.4.camel@moonlight> <49C8BC6F.3060505@sun.com> <1237892942.6754.1.camel@saturn> <49C8CC3C.5020108@sun.com> <271e55d20903240631m37ac1ae7t8899223fe0b7f1fb@mail.gmail.com> Message-ID: <1237902611.6754.17.camel@saturn> Hi Oleg, > >> Hi Artem, > >> > >>> Looks fine. > >> > >> Great. Do we have a bug report that I can reference in my commit > >> message? And do I need another review before committing? > > > > I filed a bug some time ago: > > > > 6809233: Modal dialog blocks calling thread after it is hidden and disposed > > > > I hope Oleg will look at your patch soon, and this will be enough to commit > > the change. For all the subsequent bugs, new OpenJDK tools: > > The fix looks fine for me. Thanks. I'll prepare the changeset then.. > (It is just a little surprise that someone > still waits my reviews for AWT fixes ;) Well. _I_ think this is a great step forward, if non-Sun-engineers are involved in reviewing patches. Why not? This could actually be a first. Yay! /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From Anthony.Petrov at Sun.COM Tue Mar 24 07:49:21 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Tue, 24 Mar 2009 17:49:21 +0300 Subject: Review request: 6819601 Fix AWT JTReg tests which fail to compile Message-ID: <49C8F2F1.1060505@sun.com> Hello fellow AWT developers, Please review the fix at: http://cr.openjdk.java.net/~anthony/webrev-6819601.0/ This is a patch submitted by Andrew John Hughes. Please see https://bugs.openjdk.java.net/show_bug.cgi?id=100012 for details. Thank you in advance. -- best regards, Anthony From son.two at gmail.com Tue Mar 24 07:55:25 2009 From: son.two at gmail.com (Oleg Sukhodolsky) Date: Tue, 24 Mar 2009 17:55:25 +0300 Subject: Review request: 6819601 Fix AWT JTReg tests which fail to compile In-Reply-To: <49C8F2F1.1060505@sun.com> References: <49C8F2F1.1060505@sun.com> Message-ID: <271e55d20903240755peb69229h5b709534c565c746@mail.gmail.com> test/java/awt/EventQueue/6638195/bug6638195.java I would suggest to either log exceptions or (even better) throw RuntimeException ot cause test failure. Oleg. On Tue, Mar 24, 2009 at 5:49 PM, Anthony Petrov wrote: > Hello fellow AWT developers, > > Please review the fix at: > > http://cr.openjdk.java.net/~anthony/webrev-6819601.0/ > > This is a patch submitted by Andrew John Hughes. Please see > https://bugs.openjdk.java.net/show_bug.cgi?id=100012 for details. > > Thank you in advance. > > -- > best regards, > Anthony > From Artem.Ananiev at Sun.COM Tue Mar 24 08:08:55 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Tue, 24 Mar 2009 18:08:55 +0300 Subject: Review request: 6819601 Fix AWT JTReg tests which fail to compile In-Reply-To: <271e55d20903240755peb69229h5b709534c565c746@mail.gmail.com> References: <49C8F2F1.1060505@sun.com> <271e55d20903240755peb69229h5b709534c565c746@mail.gmail.com> Message-ID: <49C8F787.2070200@sun.com> Oleg Sukhodolsky wrote: > test/java/awt/EventQueue/6638195/bug6638195.java > > I would suggest to either log exceptions or (even better) throw > RuntimeException ot cause test failure. +1 Some comments about StubPeerCrash.java: I'd expect this test to fail often in the future as it contains an implementation of ComponentPeer (which is known to change time to time). Is it possible to get rid of this peer or make it extend some existing one? Thanks, Artem > Oleg. > > On Tue, Mar 24, 2009 at 5:49 PM, Anthony Petrov wrote: >> Hello fellow AWT developers, >> >> Please review the fix at: >> >> http://cr.openjdk.java.net/~anthony/webrev-6819601.0/ >> >> This is a patch submitted by Andrew John Hughes. Please see >> https://bugs.openjdk.java.net/show_bug.cgi?id=100012 for details. >> >> Thank you in advance. >> >> -- >> best regards, >> Anthony >> From son.two at gmail.com Tue Mar 24 08:37:30 2009 From: son.two at gmail.com (Oleg Sukhodolsky) Date: Tue, 24 Mar 2009 18:37:30 +0300 Subject: Review request: 6819601 Fix AWT JTReg tests which fail to compile In-Reply-To: <49C8F787.2070200@sun.com> References: <49C8F2F1.1060505@sun.com> <271e55d20903240755peb69229h5b709534c565c746@mail.gmail.com> <49C8F787.2070200@sun.com> Message-ID: <271e55d20903240837t14c42d13mae2f67f18c7e8755@mail.gmail.com> It should be possible to use java.lang.reflect.Proxy for dummy implementation. 2009/3/24 Artem Ananiev : > > Oleg Sukhodolsky wrote: >> >> test/java/awt/EventQueue/6638195/bug6638195.java >> >> I would suggest to either log exceptions or (even better) throw >> RuntimeException ot cause test failure. > > +1 > > Some comments about StubPeerCrash.java: I'd expect this test to fail often > in the future as it contains an implementation of ComponentPeer (which is > known to change time to time). Is it possible to get rid of this peer or > make it extend some existing one? > > Thanks, > > Artem > >> Oleg. >> >> On Tue, Mar 24, 2009 at 5:49 PM, Anthony Petrov >> wrote: >>> >>> Hello fellow AWT developers, >>> >>> Please review the fix at: >>> >>> http://cr.openjdk.java.net/~anthony/webrev-6819601.0/ >>> >>> This is a patch submitted by Andrew John Hughes. Please see >>> https://bugs.openjdk.java.net/show_bug.cgi?id=100012 for details. >>> >>> Thank you in advance. >>> >>> -- >>> best regards, >>> Anthony >>> > From Anthony.Petrov at Sun.COM Tue Mar 24 10:12:40 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Tue, 24 Mar 2009 20:12:40 +0300 Subject: Review request: 6819601 Fix AWT JTReg tests which fail to compile In-Reply-To: <271e55d20903240837t14c42d13mae2f67f18c7e8755@mail.gmail.com> References: <49C8F2F1.1060505@sun.com> <271e55d20903240755peb69229h5b709534c565c746@mail.gmail.com> <49C8F787.2070200@sun.com> <271e55d20903240837t14c42d13mae2f67f18c7e8755@mail.gmail.com> Message-ID: <49C91488.2090208@sun.com> Hi Andrew, Just want to let you jump into the discussion in case you're not currently subscribed to the awt-dev mailing list. I should admit Oleg and Artem propose quite reasonable suggestions. -- best regards, Anthony On 3/24/2009 6:37 PM Oleg Sukhodolsky wrote: > It should be possible to use java.lang.reflect.Proxy for dummy implementation. > > 2009/3/24 Artem Ananiev : >> Oleg Sukhodolsky wrote: >>> test/java/awt/EventQueue/6638195/bug6638195.java >>> >>> I would suggest to either log exceptions or (even better) throw >>> RuntimeException ot cause test failure. >> +1 >> >> Some comments about StubPeerCrash.java: I'd expect this test to fail often >> in the future as it contains an implementation of ComponentPeer (which is >> known to change time to time). Is it possible to get rid of this peer or >> make it extend some existing one? >> >> Thanks, >> >> Artem >> >>> Oleg. >>> >>> On Tue, Mar 24, 2009 at 5:49 PM, Anthony Petrov >>> wrote: >>>> Hello fellow AWT developers, >>>> >>>> Please review the fix at: >>>> >>>> http://cr.openjdk.java.net/~anthony/webrev-6819601.0/ >>>> >>>> This is a patch submitted by Andrew John Hughes. Please see >>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100012 for details. >>>> >>>> Thank you in advance. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> From gnu_andrew at member.fsf.org Tue Mar 24 10:46:56 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 24 Mar 2009 17:46:56 +0000 Subject: Review request: 6819601 Fix AWT JTReg tests which fail to compile In-Reply-To: <49C91488.2090208@sun.com> References: <49C8F2F1.1060505@sun.com> <271e55d20903240755peb69229h5b709534c565c746@mail.gmail.com> <49C8F787.2070200@sun.com> <271e55d20903240837t14c42d13mae2f67f18c7e8755@mail.gmail.com> <49C91488.2090208@sun.com> Message-ID: <17c6771e0903241046ka0f3b1fxe4eaeadaf0d27207@mail.gmail.com> 2009/3/24 Anthony Petrov : > Hi Andrew, > > Just want to let you jump into the discussion in case you're not currently > subscribed to the awt-dev mailing list. I should admit Oleg and Artem > propose quite reasonable suggestions. > > -- > best regards, > Anthony > > On 3/24/2009 6:37 PM Oleg Sukhodolsky wrote: >> >> It should be possible to use java.lang.reflect.Proxy for dummy >> implementation. >> >> 2009/3/24 Artem Ananiev : >>> >>> Oleg Sukhodolsky wrote: >>>> >>>> test/java/awt/EventQueue/6638195/bug6638195.java >>>> >>>> I would suggest to either log exceptions or (even better) throw >>>> RuntimeException ot cause test failure. >>> >>> +1 >>> >>> Some comments about StubPeerCrash.java: I'd expect this test to fail >>> often >>> in the future as it contains an implementation of ComponentPeer (which is >>> known to change time to time). Is it possible to get rid of this peer or >>> make it extend some existing one? >>> >>> Thanks, >>> >>> Artem >>> >>>> Oleg. >>>> >>>> On Tue, Mar 24, 2009 at 5:49 PM, Anthony Petrov >>>> wrote: >>>>> >>>>> Hello fellow AWT developers, >>>>> >>>>> Please review the fix at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/webrev-6819601.0/ >>>>> >>>>> This is a patch submitted by Andrew John Hughes. Please see >>>>> https://bugs.openjdk.java.net/show_bug.cgi?id=100012 for details. >>>>> >>>>> Thank you in advance. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> > Yes I am on this list, but the intention of a bug report is for such discussions to go on there. It is now harder to follow the progress of this patch as it's discussed in two separate places. I could have posted the patch to the mailing list to begin with, should I have wanted discussion to take place here. I agree with the comment about the exception, as that's usually how I would handle it too - it's bad to swallow exceptions. I also agree with the comment about the proxy, but such a refactoring warrants a new bug. Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From roman at kennke.org Tue Mar 24 14:02:46 2009 From: roman at kennke.org (roman at kennke.org) Date: Tue, 24 Mar 2009 21:02:46 +0000 Subject: hg: jdk7/awt/jdk: 6809233: Modal dialog blocks calling thread after it is hidden and disposed Message-ID: <20090324210317.CA564E884@hg.openjdk.java.net> Changeset: f3ed90be28fc Author: rkennke Date: 2009-03-24 21:57 +0100 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/f3ed90be28fc 6809233: Modal dialog blocks calling thread after it is hidden and disposed Summary: Send WakingRunnable to toolkit to prevent early cleanup. Reviewed-by: art, son ! src/share/classes/java/awt/Dialog.java From anthony.petrov at sun.com Wed Mar 25 03:41:29 2009 From: anthony.petrov at sun.com (anthony.petrov at sun.com) Date: Wed, 25 Mar 2009 10:41:29 +0000 Subject: hg: jdk7/awt/jdk: 6714678: IDE (Netbeans, Eclipse, JDeveloper) Debugger hangs process on Linux Message-ID: <20090325104205.700EAE9CA@hg.openjdk.java.net> Changeset: a702e8ff83bd Author: anthony Date: 2009-03-25 13:37 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/a702e8ff83bd 6714678: IDE (Netbeans, Eclipse, JDeveloper) Debugger hangs process on Linux Summary: Added the system property sun.awt.disablegrab Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XToolkit.java From anthony.petrov at sun.com Thu Mar 26 04:42:58 2009 From: anthony.petrov at sun.com (anthony.petrov at sun.com) Date: Thu, 26 Mar 2009 11:42:58 +0000 Subject: hg: jdk7/awt/jdk: 6693253: Security Warning appearance requires enhancements; ... Message-ID: <20090326114325.3F25AEA4C@hg.openjdk.java.net> Changeset: 0cbcc4bdf95a Author: anthony Date: 2009-03-26 14:38 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/0cbcc4bdf95a 6693253: Security Warning appearance requires enhancements 6779717: A Window does not show applet security warning icon on X platforms 6785058: Parent dn't get the focus after dialog is closed if security warning is applied Summary: Forward-port from 6u10-6u14 Reviewed-by: art, dcherepanov ! make/sun/awt/Depend.mak ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/README ! make/sun/awt/make.depend ! make/sun/xawt/FILES_c_unix.gmk ! make/sun/xawt/Makefile ! make/sun/xawt/mapfile-vers + src/share/classes/com/sun/awt/SecurityWarning.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/peer/WindowPeer.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/EmbeddedFrame.java + src/solaris/classes/sun/awt/X11/InfoWindow.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/solaris/classes/sun/awt/X11/XNETProtocol.java ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XWarningWindow.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java + src/solaris/classes/sun/awt/X11/security-icon-bw16.png + src/solaris/classes/sun/awt/X11/security-icon-bw24.png + src/solaris/classes/sun/awt/X11/security-icon-bw32.png + src/solaris/classes/sun/awt/X11/security-icon-bw48.png + src/solaris/classes/sun/awt/X11/security-icon-interim16.png + src/solaris/classes/sun/awt/X11/security-icon-interim24.png + src/solaris/classes/sun/awt/X11/security-icon-interim32.png + src/solaris/classes/sun/awt/X11/security-icon-interim48.png + src/solaris/classes/sun/awt/X11/security-icon-yellow16.png + src/solaris/classes/sun/awt/X11/security-icon-yellow24.png + src/solaris/classes/sun/awt/X11/security-icon-yellow32.png + src/solaris/classes/sun/awt/X11/security-icon-yellow48.png ! src/solaris/native/sun/awt/utility/rect.h ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/windows/classes/sun/awt/windows/WWindowPeer.java ! src/windows/native/sun/windows/ComCtl32Util.cpp ! src/windows/native/sun/windows/ComCtl32Util.h + src/windows/native/sun/windows/DllUtil.cpp + src/windows/native/sun/windows/DllUtil.h ! src/windows/native/sun/windows/awt.rc ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Dialog.h ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h + src/windows/native/sun/windows/security_warning.ico + src/windows/native/sun/windows/security_warning_bw.ico + src/windows/native/sun/windows/security_warning_int.ico + test/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java + test/java/awt/Focus/CloseDialogActivateOwnerTest/java.policy + test/java/awt/Focus/OwnedWindowFocusIMECrashTest/OwnedWindowFocusIMECrashTest.java From yuri.nesterenko at sun.com Fri Mar 27 02:06:41 2009 From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com) Date: Fri, 27 Mar 2009 09:06:41 +0000 Subject: hg: jdk7/awt/jdk: 6680988: KeyEvent is still missing VK values for many keyboards Message-ID: <20090327090714.A4F95EB76@hg.openjdk.java.net> Changeset: abf3b2ecfa06 Author: yan Date: 2009-03-27 12:01 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/abf3b2ecfa06 6680988: KeyEvent is still missing VK values for many keyboards Summary: 2 new methods and some fields added to KeyEvent, plus hash of constants introduced Reviewed-by: art ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/FILES_export_windows.gmk ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/MenuShortcut.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/Action.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/KeyStroke.java ! src/share/classes/javax/swing/KeyboardManager.java ! src/share/classes/javax/swing/SwingUtilities.java + src/share/classes/sun/awt/ExtendedKeyCodes.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java ! src/solaris/classes/sun/awt/X11/generator/xlibtypes.txt ! src/solaris/classes/sun/awt/X11/keysym2ucs.h ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_KeyEvent.cpp ! src/windows/native/sun/windows/awt_KeyEvent.h + test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.html + test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.java From Anthony.Petrov at Sun.COM Fri Mar 27 09:19:29 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Fri, 27 Mar 2009 19:19:29 +0300 Subject: Review request: 6819601 Fix AWT JTReg tests which fail to compile In-Reply-To: <17c6771e0903241046ka0f3b1fxe4eaeadaf0d27207@mail.gmail.com> References: <49C8F2F1.1060505@sun.com> <271e55d20903240755peb69229h5b709534c565c746@mail.gmail.com> <49C8F787.2070200@sun.com> <271e55d20903240837t14c42d13mae2f67f18c7e8755@mail.gmail.com> <49C91488.2090208@sun.com> <17c6771e0903241046ka0f3b1fxe4eaeadaf0d27207@mail.gmail.com> Message-ID: <49CCFC91.4040002@sun.com> Hi Andrew, On 03/24/2009 08:46 PM Andrew John Hughes wrote: > Yes I am on this list, but the intention of a bug report is for such > discussions to go on there. It is now harder to follow the progress > of this patch as it's discussed in two separate places. I could have > posted the patch to the mailing list to begin with, should I have > wanted discussion to take place here. I totally agree with you. However, we currently don't have much choice: if I wouldn't send the review request to this list, nobody but a few people, that I would ask to review the fix personally, would be informed about this patch. On the other hand, sending the review request here I can't tell people not to post their replies here, but rather use the bugzilla comments to discuss the patch. Yes, I understand that the current process is odd and awkward. This is being worked on right now at Sun. I believe we'll come up with a better procedure to work with bugzilla-submitted patches soon. For now, let us please do the reviewing the way we can. > I agree with the comment about the exception, as that's usually how I > would handle it too - it's bad to swallow exceptions. Could you please send an updated patch? > I also agree with the comment about the proxy, but such a refactoring > warrants a new bug. I'm OK with this. -- best regards, Anthony From yuri.nesterenko at sun.com Mon Mar 30 05:38:35 2009 From: yuri.nesterenko at sun.com (yuri.nesterenko at sun.com) Date: Mon, 30 Mar 2009 12:38:35 +0000 Subject: hg: jdk7/awt/jdk: 6823589: Remake sizes.64-solaris-i386 with newly added fields; ... Message-ID: <20090330123926.D1E6AEC87@hg.openjdk.java.net> Changeset: 9d26016be6fa Author: yan Date: 2009-03-30 16:33 +0400 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/9d26016be6fa 6823589: Remake sizes.64-solaris-i386 with newly added fields 6782746: Keyboard hotkeys don't work in locales where non latin characters are used 6299348: Zero keycode returned in keyPressed and keyReleased for some keys in non-english layout - Win32 6316369: Provide a method to convert a character to VK_* Java keycode, if possible. 6446568: KeyEvent lacks 3 virtual keys of Danish keyboards 6559449: Support for converting from char to KeyEvent VK_ keycode 6182651: Need to identify any key pressed/released with a unique code Summary: Various by-products of 6680988 fix. Reviewed-by: art ! src/solaris/classes/sun/awt/X11/generator/sizes.64-solaris-i386 From gnu_andrew at member.fsf.org Mon Mar 30 15:23:40 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 30 Mar 2009 22:23:40 +0000 Subject: Review request: 6819601 Fix AWT JTReg tests which fail to compile In-Reply-To: <49CCFC91.4040002@sun.com> References: <49C8F2F1.1060505@sun.com> <271e55d20903240755peb69229h5b709534c565c746@mail.gmail.com> <49C8F787.2070200@sun.com> <271e55d20903240837t14c42d13mae2f67f18c7e8755@mail.gmail.com> <49C91488.2090208@sun.com> <17c6771e0903241046ka0f3b1fxe4eaeadaf0d27207@mail.gmail.com> <49CCFC91.4040002@sun.com> Message-ID: <17c6771e0903301523of207b34ifd5684c047b34771@mail.gmail.com> 2009/3/27 Anthony Petrov : > Hi Andrew, > > On 03/24/2009 08:46 PM Andrew John Hughes wrote: >> >> Yes I am on this list, but the intention of a bug report is for such >> discussions to go on there. ?It is now harder to follow the progress >> of this patch as it's discussed in two separate places. ?I could have >> posted the patch to the mailing list to begin with, should I have >> wanted discussion to take place here. > > I totally agree with you. However, we currently don't have much choice: if I > wouldn't send the review request to this list, nobody but a few people, that > I would ask to review the fix personally, would be informed about this > patch. On the other hand, sending the review request here I can't tell > people not to post their replies here, but rather use the bugzilla comments > to discuss the patch. > > Yes, I understand that the current process is odd and awkward. This is being > worked on right now at Sun. I believe we'll come up with a better procedure > to work with bugzilla-submitted patches soon. For now, let us please do the > reviewing the way we can. > >> I agree with the comment about the exception, as that's usually how I >> would handle it too - it's bad to swallow exceptions. > > Could you please send an updated patch? > >> I also agree with the comment about the proxy, but such a refactoring >> warrants a new bug. > > I'm OK with this. > > -- > best regards, > Anthony > Revised version attached. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-tests-jdk-awt.patch Type: application/octet-stream Size: 2547 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20090330/c329851e/icedtea-tests-jdk-awt.patch From son.two at gmail.com Mon Mar 30 20:40:53 2009 From: son.two at gmail.com (Oleg Sukhodolsky) Date: Tue, 31 Mar 2009 07:40:53 +0400 Subject: Review request: 6819601 Fix AWT JTReg tests which fail to compile In-Reply-To: <17c6771e0903301523of207b34ifd5684c047b34771@mail.gmail.com> References: <49C8F2F1.1060505@sun.com> <271e55d20903240755peb69229h5b709534c565c746@mail.gmail.com> <49C8F787.2070200@sun.com> <271e55d20903240837t14c42d13mae2f67f18c7e8755@mail.gmail.com> <49C91488.2090208@sun.com> <17c6771e0903241046ka0f3b1fxe4eaeadaf0d27207@mail.gmail.com> <49CCFC91.4040002@sun.com> <17c6771e0903301523of207b34ifd5684c047b34771@mail.gmail.com> Message-ID: <271e55d20903302040n16fce47cm29cb69b946c983aa@mail.gmail.com> Looks fine for me. And I hope that someone will file a bug about changing StubPeerCrash. Oleg. On Tue, Mar 31, 2009 at 2:23 AM, Andrew John Hughes wrote: > 2009/3/27 Anthony Petrov : >> Hi Andrew, >> >> On 03/24/2009 08:46 PM Andrew John Hughes wrote: >>> >>> Yes I am on this list, but the intention of a bug report is for such >>> discussions to go on there. ?It is now harder to follow the progress >>> of this patch as it's discussed in two separate places. ?I could have >>> posted the patch to the mailing list to begin with, should I have >>> wanted discussion to take place here. >> >> I totally agree with you. However, we currently don't have much choice: if I >> wouldn't send the review request to this list, nobody but a few people, that >> I would ask to review the fix personally, would be informed about this >> patch. On the other hand, sending the review request here I can't tell >> people not to post their replies here, but rather use the bugzilla comments >> to discuss the patch. >> >> Yes, I understand that the current process is odd and awkward. This is being >> worked on right now at Sun. I believe we'll come up with a better procedure >> to work with bugzilla-submitted patches soon. For now, let us please do the >> reviewing the way we can. >> >>> I agree with the comment about the exception, as that's usually how I >>> would handle it too - it's bad to swallow exceptions. >> >> Could you please send an updated patch? >> >>> I also agree with the comment about the proxy, but such a refactoring >>> warrants a new bug. >> >> I'm OK with this. >> >> -- >> best regards, >> Anthony >> > > Revised version attached. > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > From Anthony.Petrov at Sun.COM Tue Mar 31 07:35:18 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Tue, 31 Mar 2009 18:35:18 +0400 Subject: Review request: 6819601 Fix AWT JTReg tests which fail to compile In-Reply-To: <17c6771e0903301523of207b34ifd5684c047b34771@mail.gmail.com> References: <49C8F2F1.1060505@sun.com> <271e55d20903240755peb69229h5b709534c565c746@mail.gmail.com> <49C8F787.2070200@sun.com> <271e55d20903240837t14c42d13mae2f67f18c7e8755@mail.gmail.com> <49C91488.2090208@sun.com> <17c6771e0903241046ka0f3b1fxe4eaeadaf0d27207@mail.gmail.com> <49CCFC91.4040002@sun.com> <17c6771e0903301523of207b34ifd5684c047b34771@mail.gmail.com> Message-ID: <49D22A26.9000000@sun.com> On 03/31/2009 02:23 AM Andrew John Hughes wrote: >>> I agree with the comment about the exception, as that's usually how I >>> would handle it too - it's bad to swallow exceptions. >> Could you please send an updated patch? >> >>> I also agree with the comment about the proxy, but such a refactoring >>> warrants a new bug. >> I'm OK with this. >> > > Revised version attached. Looks awesome. Thank you for the contribution! I'll push the changeset soon. -- best regards, Anthony From Anthony.Petrov at Sun.COM Tue Mar 31 07:36:49 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Tue, 31 Mar 2009 18:36:49 +0400 Subject: Review request: 6819601 Fix AWT JTReg tests which fail to compile In-Reply-To: <271e55d20903302040n16fce47cm29cb69b946c983aa@mail.gmail.com> References: <49C8F2F1.1060505@sun.com> <271e55d20903240755peb69229h5b709534c565c746@mail.gmail.com> <49C8F787.2070200@sun.com> <271e55d20903240837t14c42d13mae2f67f18c7e8755@mail.gmail.com> <49C91488.2090208@sun.com> <17c6771e0903241046ka0f3b1fxe4eaeadaf0d27207@mail.gmail.com> <49CCFC91.4040002@sun.com> <17c6771e0903301523of207b34ifd5684c047b34771@mail.gmail.com> <271e55d20903302040n16fce47cm29cb69b946c983aa@mail.gmail.com> Message-ID: <49D22A81.70400@sun.com> Hi Oleg, On 03/31/2009 07:40 AM Oleg Sukhodolsky wrote: > Looks fine for me. And I hope that someone will file a bug about > changing StubPeerCrash. Would you like to test our brand-new bugzilla instance, and file the bug report yourself? Perhaps with a patch? ;) -- best regards, Anthony From anthony.petrov at sun.com Tue Mar 31 07:52:05 2009 From: anthony.petrov at sun.com (anthony.petrov at sun.com) Date: Tue, 31 Mar 2009 14:52:05 +0000 Subject: hg: jdk7/awt/jdk: 6819601: Fix AWT JTReg tests which fail to compile Message-ID: <20090331145229.BAC4EECFE@hg.openjdk.java.net> Changeset: 3a9ae1117c12 Author: anthony Date: 2009-03-31 18:47 +0400 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/3a9ae1117c12 6819601: Fix AWT JTReg tests which fail to compile Summary: Fix compilation of tests. Reviewed-by: anthony, son Contributed-by: Andrew John Hughes ! test/java/awt/Component/isLightweightCrash/StubPeerCrash.java ! test/java/awt/EventQueue/6638195/bug6638195.java From Anthony.Petrov at Sun.COM Tue Mar 31 07:53:04 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Tue, 31 Mar 2009 18:53:04 +0400 Subject: Review request: 6819601 Fix AWT JTReg tests which fail to compile In-Reply-To: <17c6771e0903301523of207b34ifd5684c047b34771@mail.gmail.com> References: <49C8F2F1.1060505@sun.com> <271e55d20903240755peb69229h5b709534c565c746@mail.gmail.com> <49C8F787.2070200@sun.com> <271e55d20903240837t14c42d13mae2f67f18c7e8755@mail.gmail.com> <49C91488.2090208@sun.com> <17c6771e0903241046ka0f3b1fxe4eaeadaf0d27207@mail.gmail.com> <49CCFC91.4040002@sun.com> <17c6771e0903301523of207b34ifd5684c047b34771@mail.gmail.com> Message-ID: <49D22E50.4020709@sun.com> Andrew, By the way, your patch contained some tab characters and trailing spaces. Those are prohibited according to the OpenJDK Codding Conventions (not sure if there's a web-page describing them, though). I fixed the patch myself. -- best regards, Anthony On 03/31/2009 02:23 AM Andrew John Hughes wrote: > 2009/3/27 Anthony Petrov : >> Hi Andrew, >> >> On 03/24/2009 08:46 PM Andrew John Hughes wrote: >>> Yes I am on this list, but the intention of a bug report is for such >>> discussions to go on there. It is now harder to follow the progress >>> of this patch as it's discussed in two separate places. I could have >>> posted the patch to the mailing list to begin with, should I have >>> wanted discussion to take place here. >> I totally agree with you. However, we currently don't have much choice: if I >> wouldn't send the review request to this list, nobody but a few people, that >> I would ask to review the fix personally, would be informed about this >> patch. On the other hand, sending the review request here I can't tell >> people not to post their replies here, but rather use the bugzilla comments >> to discuss the patch. >> >> Yes, I understand that the current process is odd and awkward. This is being >> worked on right now at Sun. I believe we'll come up with a better procedure >> to work with bugzilla-submitted patches soon. For now, let us please do the >> reviewing the way we can. >> >>> I agree with the comment about the exception, as that's usually how I >>> would handle it too - it's bad to swallow exceptions. >> Could you please send an updated patch? >> >>> I also agree with the comment about the proxy, but such a refactoring >>> warrants a new bug. >> I'm OK with this. >> >> -- >> best regards, >> Anthony >> > > Revised version attached. From gnu_andrew at member.fsf.org Tue Mar 31 08:06:22 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 31 Mar 2009 15:06:22 +0000 Subject: Review request: 6819601 Fix AWT JTReg tests which fail to compile In-Reply-To: <49D22E50.4020709@sun.com> References: <49C8F2F1.1060505@sun.com> <271e55d20903240755peb69229h5b709534c565c746@mail.gmail.com> <49C8F787.2070200@sun.com> <271e55d20903240837t14c42d13mae2f67f18c7e8755@mail.gmail.com> <49C91488.2090208@sun.com> <17c6771e0903241046ka0f3b1fxe4eaeadaf0d27207@mail.gmail.com> <49CCFC91.4040002@sun.com> <17c6771e0903301523of207b34ifd5684c047b34771@mail.gmail.com> <49D22E50.4020709@sun.com> Message-ID: <17c6771e0903310806s6d0139a5ub49efff9f1e5187f@mail.gmail.com> 2009/3/31 Anthony Petrov : > Andrew, > > By the way, your patch contained some tab characters and trailing spaces. > Those are prohibited according to the OpenJDK Codding Conventions (not sure > if there's a web-page describing them, though). I fixed the patch myself. > > -- > best regards, > Anthony > > > On 03/31/2009 02:23 AM Andrew John Hughes wrote: >> >> 2009/3/27 Anthony Petrov : >>> >>> Hi Andrew, >>> >>> On 03/24/2009 08:46 PM Andrew John Hughes wrote: >>>> >>>> Yes I am on this list, but the intention of a bug report is for such >>>> discussions to go on there. ?It is now harder to follow the progress >>>> of this patch as it's discussed in two separate places. ?I could have >>>> posted the patch to the mailing list to begin with, should I have >>>> wanted discussion to take place here. >>> >>> I totally agree with you. However, we currently don't have much choice: >>> if I >>> wouldn't send the review request to this list, nobody but a few people, >>> that >>> I would ask to review the fix personally, would be informed about this >>> patch. On the other hand, sending the review request here I can't tell >>> people not to post their replies here, but rather use the bugzilla >>> comments >>> to discuss the patch. >>> >>> Yes, I understand that the current process is odd and awkward. This is >>> being >>> worked on right now at Sun. I believe we'll come up with a better >>> procedure >>> to work with bugzilla-submitted patches soon. For now, let us please do >>> the >>> reviewing the way we can. >>> >>>> I agree with the comment about the exception, as that's usually how I >>>> would handle it too - it's bad to swallow exceptions. >>> >>> Could you please send an updated patch? >>> >>>> I also agree with the comment about the proxy, but such a refactoring >>>> warrants a new bug. >>> >>> I'm OK with this. >>> >>> -- >>> best regards, >>> Anthony >>> >> >> Revised version attached. > Weird. Didn't see any in the diff here. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8