From alexandr.scherbatiy at oracle.com Tue Aug 7 04:17:40 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 07 Aug 2012 15:17:40 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. Message-ID: <5020F954.4090203@oracle.com> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ This is a regression after the fix 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In the case where a toolbar is created under a mouse and it is dragged over the initial window the mouse enter/exit events should not be generated for the components which are under the toolbar. The current fix is supposed to solve this regression and also to fix generation of mouse enter/exit events for all cases where a mouse is dragged from one window to another or a new window is created under a mouse (like it is implemented for toolbar). Let's see the following cases 1) Mouse is dragged from a window and back to the same window. The Mac OS X system generates a mouse exit event only the first time when a mouse is dragged from a window and does not generate mouse enter/exit events next times during one drag trace. 2) Mouse is dragged from one window to another. The Mac OS X system does not generate mouse enter/exit events for the second window. 3) Mouse is dragged from one window to another and released. In this case the Mac OS X system generates mouse enter event for the second window only after releasing the mouse. 4) Clicking on window creates a new window after that the new window is dragged (toolbar dragging). However the Java system generates mouse enter/exit events each time when a mouse is dragged over any window. To fix this the following methods are introduced: - Get topmost window under mouse - Synthesize mouse enter/exit events for all windows The dispatchMouseEvent method from the LWWindowPeer class is handled previous and next components and is able to generate mouse enter/exit events for them. However the the AWTView native class contains isMouseOver flag which value becomes inconsistent if we do not updated it. Because of this the fix generates the mouse enter/exit window events on the native side. Generating mouse enter/exit events always should be in order where mouse exit events are generated before the mouse enter events. The synthesizeMouseEnteredExitedEventsForAllWindows method tries to generate mouse enter/exit events for all windows during mouse drag or window creation/window bounds changing. However only those windows which isMouseOver flag is differ from the isTopMostWindowUnderMouse state are affected. This method also tries to generate both mouse enter and exit event for the same window but only one of them can be applicable because the isTopMostWindowUnderMouse state is not changed for these calls. So the window enter/exit events now are always generated from the native system and component enter/exit events are generated in the LWWindowPeer class. LWWindowPeer class now uses three links to components: current, last and topmostUnderMouse. All of them are necessary because in case when a mouse is dragged from one window to another the current component receives drag events and last and topmostUnderMouse links handle components mouse exit/enter events on the second window. Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Tue Aug 7 04:33:57 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 07 Aug 2012 15:33:57 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <5020F954.4090203@oracle.com> References: <5020F954.4090203@oracle.com> Message-ID: <5020FD25.7090702@oracle.com> Hi, Alexander. Probably all this stuff can be simplified? Can you try to change TrackingRect to TrackingArea with appropriate flags like NSTrackingEnabledDuringMouseDrag etc. 07.08.2012 15:17, Alexander Scherbatiy wrote: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 > webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ > > This is a regression after the fix 7154048 [macosx] At least drag > twice, the toolbar can be dragged to the left side. > > In the case where a toolbar is created under a mouse and it is dragged > over the initial window the mouse enter/exit events should not be > generated for the components which are under the toolbar. > > The current fix is supposed to solve this regression and also to fix > generation of mouse enter/exit events for all cases where a mouse is > dragged from one window to another or a new window is created under a > mouse (like it is implemented for toolbar). > > Let's see the following cases > 1) Mouse is dragged from a window and back to the same window. > The Mac OS X system generates a mouse exit event only the first time > when a mouse is dragged from a window and does not generate mouse > enter/exit events next times during one drag trace. > > 2) Mouse is dragged from one window to another. > The Mac OS X system does not generate mouse enter/exit events for > the second window. > > 3) Mouse is dragged from one window to another and released. > In this case the Mac OS X system generates mouse enter event for the > second window only after releasing the mouse. > > 4) Clicking on window creates a new window after that the new window > is dragged (toolbar dragging). > > However the Java system generates mouse enter/exit events each time > when a mouse is dragged over any window. > > To fix this the following methods are introduced: > - Get topmost window under mouse > - Synthesize mouse enter/exit events for all windows > > > The dispatchMouseEvent method from the LWWindowPeer class is handled > previous and next components and is able to generate mouse enter/exit > events for them. > However the the AWTView native class contains isMouseOver flag which > value becomes inconsistent if we do not updated it. Because of this > the fix generates the mouse enter/exit window events on the native side. > > Generating mouse enter/exit events always should be in order where > mouse exit events are generated before the mouse enter events. > > The synthesizeMouseEnteredExitedEventsForAllWindows method tries to > generate mouse enter/exit events for all windows during mouse drag or > window creation/window bounds changing. > However only those windows which isMouseOver flag is differ from the > isTopMostWindowUnderMouse state are affected. > This method also tries to generate both mouse enter and exit event for > the same window but only one of them can be applicable because the > isTopMostWindowUnderMouse state is not changed for these calls. > > So the window enter/exit events now are always generated from the > native system and component enter/exit events are generated in the > LWWindowPeer class. > > LWWindowPeer class now uses three links to components: current, last > and topmostUnderMouse. All of them are necessary because in case when > a mouse is dragged from one window to another the current component > receives drag events and last and topmostUnderMouse links handle > components mouse exit/enter events on the second window. > > Thanks, > Alexandr. > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 7 04:39:39 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 07 Aug 2012 15:39:39 +0400 Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) Message-ID: <5020FE7B.6020402@oracle.com> Hi Everyone, Please review the fix. When we translate calls from our swing menu components to awt peer we resets information about shortcut in the setLabel(). This happens because of ScreenMenuItem.setAccelerator() method call peers setLabel(..,..,..) directly and does not initialize ScreenMenuItem.shortcut property. But default implementation of ScreenMenuItem.setLabel() assumes that this field(shortcut) will be initialized. This works on jdk6 because it does not reset shortcut if null or empty shortcut is provided. As a solution we can use peers methods directly in both cases. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 Webrev can be found at: http://cr.openjdk.java.net/~serb/7186371/webrev.00 -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Aug 7 06:18:17 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 07 Aug 2012 17:18:17 +0400 Subject: JAWT Breakage in OpenJDK 7/8 In-Reply-To: <5016B905.2070106@redhat.com> References: <500ED0D6.2080908@redhat.com> <500FBD79.5050601@oracle.com> <50100574.9020607@redhat.com> <501683E9.8040201@oracle.com> <5016B905.2070106@redhat.com> Message-ID: <50211599.6030207@oracle.com> Hi Omair, On 7/30/2012 8:40 PM, Omair Majid wrote: > Hi Artem, > > Thanks for your thoughts and comments. > > On 07/30/2012 08:54 AM, Artem Ananiev wrote: >> On 7/25/2012 6:40 PM, Omair Majid wrote: >>> On 07/25/2012 05:33 AM, Artem Ananiev wrote: >>>> Hi, Omair, >>>> >>>> I don't remember the exact reason for LD_LIBRARY_PATH changes, but it's >>>> very unlikely they can be reverted. Your proposed patch will probably >>>> solve the problem (I haven't checked, though), but it has major >>>> side-effect: increased startup time. >>> I am not sure how significant that would be. It's a tiny library after >>> all - only 0.5KB on my machine. >> I would be really surprised if it takes 1 sec to load, but even few >> milliseconds matter during startup. > > Good point. Do you have any suggestion on how to measure the impact on > startup? Obviously, I cant run this code in a loop and average it out. > Would a delay of a few milliseconds (let's say 5, as an example) or of a > few percentage (say, startup of a no-op awt program slowed down by 1%) > be acceptable? > >>>> That's why I vote for just updating JAWT documentation to include >>>> System.loadLibrary() call in the application code. >>> While I agree that the docs should be updated, I dont think it's >>> sufficient: existing applications that rely on this are currently >>> broken. If the applications can not be modified (third-party or >>> read-only) then this (for all intents and purposes) breaks the promised >>> "binary compatibility" of OpenJDK :( >> What is "binary compatibility"? It's impossible to make any change in >> JDK and don't break someone's code, that relies on unspecified behavior. >> My personal attitude to "binary compatibility" is the same as to "bug to >> bug compatibility", which was never supported by JDK. > > Fair enough. > > But looking around the OpenJDK mailing lists, I see that many developers > go to great lengths to ensure programs remain working, even if the > programs are using unspecified and undocumented behaviour: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184401 > > Please consider this fix in the same spirit - it keeps third-party > programs working. In fact, this keeps the behaviour that's documented > (if not very clearly) working. > >> As for formal JDK specification, is there anything broken in JDK7/8 >> version of JAWT? > > I can't actually seem to find a specification for this. All I see is > http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html > which is not so much a spec as it is a guide for developers. My concern > is that, even if i were to write a new application that follows > everything listed in that guide today, the application would be broken. > >> Is there any wording about loadLibrary("jawt") in the >> spec? > > There's nothing in the developer guide about loadLibrary("jawt"). I am > not sure about the spec :( > >> If an application developer creates an application and links it to a >> library, who is responsible for the library to be accessible by the >> native loader (PATH, LD_LIBRARY_PATH, etc.)? > > This is a great question. Something I don't a good answer to, unfortunately. > > That said, I think some factors are important to consider when trying to > come up with the answer: > > 1. All the developer docs talk about is linking the native library > against "libjawt.so". Nothing about a System.loadLibrary("jawt") is > mentioned in the example. The demo is normally an ideal program, so this > (to me, at least) says developers should not use System.loadLibrary("jawt"). > > 2. The JDK/JRE directory is designed to be relocatable. And applications > aren't supposed to be installed into it. Together, I think that means > that programs aren't located inside the JDK/JRE and don't know the path > to it. The only way linking to a library inside would work would be > either if the library was already loaded or the JRE would be able to > find it. > > Together, I take this to mean that what the existing applications are > not responsible for invoking either System.loadLibrary("jawt") or > linking to the exact path of the libjawt.so. > >> I'm even not sure that >> there is a specification that declares System.loadLibrary("jawt") to >> work everywhere. > > Well, the developer docs explicitly talk about linking against the > native awt library (and provide the name as "libjawt.so"). > System.loadLibrary is the java-version of that. > > If you still think preloading libjawt.so is a non-starter, then I > believe the next best option would be to modify the java launcher so it > can find libjawt.so. The only problem is the "fix" will be far from the > problem, and may get ignored if, say, libjawt.so is moved around. > > What do you think is the best option? I agree with Artem that pre-loading the jawt library unconditionally is a bad thing to do, because even tiny milliseconds matter. Besides, a fair amount of Java GUI applications simply don't require jawt, so this pre-loading looks unnecessary. I also agree with Omair and Mario on that old applications cannot be modified sometimes, and therefore, whilst it makes some sense to update the doc and suggest developers to System.loadLibrary("jawt") in their app, we should still make sure old applications work as expected. I've also read the discussion that took place on build-dev@ regarding this issue, and it seems to me that adding an RPATH entry to launchers is the right solution for this issue. We may want to also add a comment there and state that this entry is added specifically to address the jawt use case. Perhaps it makes sense to also add a comment somewhere in a jawt makefile to state that we rely on this RPATH entry in the launcher. This way we can ensure that even if the jawt library is moved around, the relevant RPATH entry gets updated accordingly as well. -- best regards, Anthony From anthony.petrov at oracle.com Tue Aug 7 06:24:06 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 07 Aug 2012 17:24:06 +0400 Subject: [8] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category In-Reply-To: <70556E1E-06E7-4D9D-A8AA-11BE1A78DA41@oracle.com> References: <70556E1E-06E7-4D9D-A8AA-11BE1A78DA41@oracle.com> Message-ID: <502116F6.9010204@oracle.com> The fix looks good to me. -- best regards, Anthony On 7/26/2012 5:24 PM, Leonid Romanov wrote: > Hi, > Please review a fix for 7159381: [macosx] Dock Icon defaults to Generic > Java Application Category. This is a forward port of the fix that went > into 7u6. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7159381 > Webrev: http://cr.openjdk.java.net/~leonidr/7159381/webrev.01/ > > Thanks, > Leonid. From neugens at redhat.com Tue Aug 7 06:38:32 2012 From: neugens at redhat.com (Mario Torre) Date: Tue, 07 Aug 2012 15:38:32 +0200 Subject: JAWT Breakage in OpenJDK 7/8 In-Reply-To: <50211599.6030207@oracle.com> References: <500ED0D6.2080908@redhat.com> <500FBD79.5050601@oracle.com> <50100574.9020607@redhat.com> <501683E9.8040201@oracle.com> <5016B905.2070106@redhat.com> <50211599.6030207@oracle.com> Message-ID: <1344346712.17556.3.camel@pegasus> Il giorno mar, 07/08/2012 alle 17.18 +0400, Anthony Petrov ha scritto: > I agree with Artem that pre-loading the jawt library unconditionally is > a bad thing to do, because even tiny milliseconds matter. Besides, a > fair amount of Java GUI applications simply don't require jawt, so this > pre-loading looks unnecessary. > > I also agree with Omair and Mario on that old applications cannot be > modified sometimes, and therefore, whilst it makes some sense to update > the doc and suggest developers to System.loadLibrary("jawt") in their > app, we should still make sure old applications work as expected. > > I've also read the discussion that took place on build-dev@ regarding > this issue, and it seems to me that adding an RPATH entry to launchers > is the right solution for this issue. We may want to also add a comment > there and state that this entry is added specifically to address the > jawt use case. Perhaps it makes sense to also add a comment somewhere in > a jawt makefile to state that we rely on this RPATH entry in the > launcher. This way we can ensure that even if the jawt library is moved > around, the relevant RPATH entry gets updated accordingly as well. This sounds to me a pretty good solution, yes, Thanks for looking at this issue! Cheers, Mario From swingler at apple.com Tue Aug 7 07:47:10 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 07 Aug 2012 07:47:10 -0700 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <5020FD25.7090702@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> Message-ID: I noticed that, NSWindow's windowNumber is NSInteger, which is 32 bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a simple 32 bit int is probably not what you intended to do. Also, have you considered simply calling -[NSWindow setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then removing the calls that flip it on and off in -[AWTView mouseEntered:] and -[AWTView mouseExited"]? This would also require a change in Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), which has a comment that states it only turns on mouse moved events if the window is currently under the mouse. I would think that AppKit should be more than happy to send you mouse-over/enter/exited events as long as you say you want them. Was this approach tried and didn't work for some reason? Regards, Mike Swingler Apple Inc. On Aug 7, 2012, at 4:33 AM, Sergey Bylokhov wrote: > Hi, Alexander. > Probably all this stuff can be simplified? Can you try to change TrackingRect to TrackingArea with appropriate flags like NSTrackingEnabledDuringMouseDrag etc. > > 07.08.2012 15:17, Alexander Scherbatiy wrote: >> >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >> >> This is a regression after the fix 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. >> >> In the case where a toolbar is created under a mouse and it is dragged over the initial window the mouse enter/exit events should not be generated for the components which are under the toolbar. >> >> The current fix is supposed to solve this regression and also to fix generation of mouse enter/exit events for all cases where a mouse is dragged from one window to another or a new window is created under a mouse (like it is implemented for toolbar). >> >> Let's see the following cases >> 1) Mouse is dragged from a window and back to the same window. >> The Mac OS X system generates a mouse exit event only the first time when a mouse is dragged from a window and does not generate mouse enter/exit events next times during one drag trace. >> >> 2) Mouse is dragged from one window to another. >> The Mac OS X system does not generate mouse enter/exit events for the second window. >> >> 3) Mouse is dragged from one window to another and released. >> In this case the Mac OS X system generates mouse enter event for the second window only after releasing the mouse. >> >> 4) Clicking on window creates a new window after that the new window is dragged (toolbar dragging). >> >> However the Java system generates mouse enter/exit events each time when a mouse is dragged over any window. >> >> To fix this the following methods are introduced: >> - Get topmost window under mouse >> - Synthesize mouse enter/exit events for all windows >> >> >> The dispatchMouseEvent method from the LWWindowPeer class is handled previous and next components and is able to generate mouse enter/exit events for them. >> However the the AWTView native class contains isMouseOver flag which value becomes inconsistent if we do not updated it. Because of this the fix generates the mouse enter/exit window events on the native side. >> >> Generating mouse enter/exit events always should be in order where mouse exit events are generated before the mouse enter events. >> >> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to generate mouse enter/exit events for all windows during mouse drag or window creation/window bounds changing. >> However only those windows which isMouseOver flag is differ from the isTopMostWindowUnderMouse state are affected. >> This method also tries to generate both mouse enter and exit event for the same window but only one of them can be applicable because the isTopMostWindowUnderMouse state is not changed for these calls. >> >> So the window enter/exit events now are always generated from the native system and component enter/exit events are generated in the LWWindowPeer class. >> >> LWWindowPeer class now uses three links to components: current, last and topmostUnderMouse. All of them are necessary because in case when a mouse is dragged from one window to another the current component receives drag events and last and topmostUnderMouse links handle components mouse exit/enter events on the second window. >> >> Thanks, >> Alexandr. >> >> > > > -- > Best regards, Sergey. > From lana.steuck at oracle.com Tue Aug 7 17:42:58 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 00:42:58 +0000 Subject: hg: jdk8/awt: Added tag jdk8-b50 for changeset 2fd67618b9a3 Message-ID: <20120808004259.92248473F1@hg.openjdk.java.net> Changeset: 57c0aee73090 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/57c0aee73090 Added tag jdk8-b50 for changeset 2fd67618b9a3 ! .hgtags From lana.steuck at oracle.com Tue Aug 7 17:42:58 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 00:42:58 +0000 Subject: hg: jdk8/awt/corba: Added tag jdk8-b50 for changeset d20d9eb9f093 Message-ID: <20120808004303.3E5F0473F2@hg.openjdk.java.net> Changeset: 9b0f841ca9f7 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/9b0f841ca9f7 Added tag jdk8-b50 for changeset d20d9eb9f093 ! .hgtags From lana.steuck at oracle.com Tue Aug 7 17:43:00 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 00:43:00 +0000 Subject: hg: jdk8/awt/jaxws: Added tag jdk8-b50 for changeset bdab72e87b83 Message-ID: <20120808004309.23E4D473F3@hg.openjdk.java.net> Changeset: 1a70b6333ebe Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/1a70b6333ebe Added tag jdk8-b50 for changeset bdab72e87b83 ! .hgtags From lana.steuck at oracle.com Tue Aug 7 17:43:10 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 00:43:10 +0000 Subject: hg: jdk8/awt/langtools: Added tag jdk8-b50 for changeset b2d8a270f5f2 Message-ID: <20120808004313.2F0D6473F4@hg.openjdk.java.net> Changeset: c4cd4cab2220 Author: katleman Date: 2012-08-02 15:37 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/c4cd4cab2220 Added tag jdk8-b50 for changeset b2d8a270f5f2 ! .hgtags From lana.steuck at oracle.com Tue Aug 7 17:43:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 00:43:07 +0000 Subject: hg: jdk8/awt/jaxp: Added tag jdk8-b50 for changeset 2791ec55f66b Message-ID: <20120808004315.2A294473F5@hg.openjdk.java.net> Changeset: dc1ea77ed9d9 Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/dc1ea77ed9d9 Added tag jdk8-b50 for changeset 2791ec55f66b ! .hgtags From lana.steuck at oracle.com Tue Aug 7 17:43:20 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 00:43:20 +0000 Subject: hg: jdk8/awt/hotspot: 37 new changesets Message-ID: <20120808004444.619F7473F6@hg.openjdk.java.net> Changeset: 54e66510c9cd Author: amurillo Date: 2012-07-13 14:16 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/54e66510c9cd 7184050: new hotspot build - hs24-b17 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8150fa46d2ed Author: jiangli Date: 2012-06-26 19:08 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8150fa46d2ed 7178145: Change constMethodOop::_exception_table to optionally inlined u2 table. Summary: Change constMethodOop::_exception_table to optionally inlined u2 table. Reviewed-by: bdelsart, coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java + agent/src/share/classes/sun/jvm/hotspot/oops/ExceptionTableElement.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constMethodOop.cpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f0b82641fb7e Author: bdelsart Date: 2012-07-02 04:19 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f0b82641fb7e Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: d68b1274b9ba Author: jiangli Date: 2012-07-05 18:47 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d68b1274b9ba 7180914: Compilation warning after: 7172967: Eliminate the constMethod's _method backpointer to the methodOop. Summary: Use read_pointer(J...) to access from 'constMethod' base in name_for_methodOop(), libjvm_db.c. Reviewed-by: kvn, coleenp ! src/os/solaris/dtrace/libjvm_db.c Changeset: 161ae369407d Author: jiangli Date: 2012-07-05 20:54 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/161ae369407d 7181632: nsk classLoad001_14 failure and CompileTheWorld crash after 7178145. Summary: Need to copy the inlined exception table to the new constMethodOop during method rewriting. Reviewed-by: coleenp, dholmes ! src/share/vm/oops/methodOop.cpp Changeset: e74da3c2b827 Author: jiangli Date: 2012-07-13 20:14 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e74da3c2b827 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 0bca41b2fa63 Author: jiangli Date: 2012-07-17 12:32 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/0bca41b2fa63 Merge Changeset: 922993931b3d Author: brutisso Date: 2012-07-11 22:47 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/922993931b3d 7178361: G1: Make sure that PrintGC and PrintGCDetails use the same timing for the GC pause Summary: Also reviewed by: vitalyd at gmail.com. Move the timing out of G1CollectorPolicy into the G1GCPhaseTimes class Reviewed-by: johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 3a431b605145 Author: jmasa Date: 2012-07-16 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3a431b605145 Merge ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 7553d441b878 Author: jmasa Date: 2012-07-17 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7553d441b878 Merge Changeset: 6d8f36bcef55 Author: jrose Date: 2012-07-12 00:39 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6d8f36bcef55 6711908: JVM needs direct access to some annotations Summary: Add annotation extraction code to class file parser. Reviewed-by: twisti, jrose, kvn Contributed-by: michael.haupt at oracle.com ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/methodOop.hpp Changeset: ed21db7b3fda Author: kvn Date: 2012-07-13 17:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ed21db7b3fda 7123926: Some CTW test crash: !_control.contains(ctrl) Summary: Don't eliminate Integer::toString() call node during String concatenation optimization if it has several uses. Reviewed-by: twisti ! src/share/vm/opto/stringopts.cpp Changeset: 56c4f88474b3 Author: twisti Date: 2012-07-16 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/56c4f88474b3 7087357: JSR 292: remove obsolete code after 7085860 Reviewed-by: kvn, never ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 2c368ea3e844 Author: kvn Date: 2012-07-16 17:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/2c368ea3e844 7181494: cleanup avx and vectors code Summary: renamed mach nodes which use scalar AVX instructions, added integer vectors shuffling instructions Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86.ad ! src/share/vm/code/vmreg.hpp Changeset: 9c9fb30d2b3b Author: kvn Date: 2012-07-16 19:50 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/9c9fb30d2b3b Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/unsafe.cpp Changeset: dd785aabe02b Author: kvn Date: 2012-07-17 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/dd785aabe02b Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp Changeset: bc3e01899804 Author: kvn Date: 2012-07-19 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/bc3e01899804 Merge Changeset: d900d95bfdb0 Author: fparain Date: 2012-07-16 04:06 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d900d95bfdb0 7183754: Test runtime/6294277/Test6294277.sh runs wrong JVM Reviewed-by: kamg, coleenp, ctornqvi ! test/runtime/6294277/SourceDebugExtension.java - test/runtime/6294277/Test6294277.sh Changeset: 149c36689fcb Author: asaha Date: 2012-07-17 22:16 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/149c36689fcb 7053586: TEST: runtime/7020373/Test7020373.sh fails on 64-bit platforms Reviewed-by: kamg ! test/runtime/7020373/Test7020373.sh Changeset: 7e5976e66c62 Author: zgu Date: 2012-07-19 09:05 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7e5976e66c62 7182543: NMT ON: Aggregate a few NMT related bugs Summary: 1) Fixed MemTrackWorker::generations_in_used() calculation 2) Ensured NMT not to leak memory recorders after shutdown 3) Used ThreadCritical to block safepoint safe threads Reviewed-by: acorn, coleenp, dholmes, kvn ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: f1f45dddb0bd Author: zgu Date: 2012-07-16 14:10 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f1f45dddb0bd 7181986: NMT ON: Assertion failure when running jdi ExpiredRequestDeletionTest Summary: Changed _query_lock to heap object from static object. Also fixed _query_lock and snapshot lock ranks, so they can participate deadlock detection. Reviewed-by: coleenp, dholmes, kvn ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: d5bc62fcfac7 Author: zgu Date: 2012-07-19 09:10 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d5bc62fcfac7 Merge ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 04a9b3789683 Author: zgu Date: 2012-07-16 14:05 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/04a9b3789683 7181989: NMT ON: Assertion failure when NMT checks thread's native stack base address Summary: Assertion on stack base is not necessary Reviewed-by: coleenp, dholmes, kvn ! src/share/vm/services/memTracker.cpp Changeset: 58a04a45a549 Author: zgu Date: 2012-07-19 09:15 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/58a04a45a549 Merge ! src/share/vm/services/memTracker.cpp Changeset: 950ed41429e5 Author: zgu Date: 2012-07-19 06:24 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/950ed41429e5 Merge Changeset: 12fc2571a6e2 Author: coleenp Date: 2012-07-20 12:09 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/12fc2571a6e2 Merge - test/runtime/6294277/Test6294277.sh Changeset: bd54fe36b5e5 Author: amurillo Date: 2012-07-23 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/bd54fe36b5e5 Merge - test/runtime/6294277/Test6294277.sh Changeset: 15eb2b903b04 Author: amurillo Date: 2012-07-23 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/15eb2b903b04 Added tag hs24-b17 for changeset bd54fe36b5e5 ! .hgtags Changeset: aba91a731143 Author: amurillo Date: 2012-07-23 13:04 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/aba91a731143 7185775: new hotspot build - hs24-b18 Reviewed-by: jcoomes ! make/hotspot_version Changeset: fe94b4e7212b Author: asaha Date: 2012-07-23 14:28 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/fe94b4e7212b 7185550: TEST: runtime/7020373/Test7020373.sh fails because there is no test/runtime/7020373/testcase.jar Reviewed-by: coleenp ! test/runtime/7020373/Test7020373.sh + test/runtime/7020373/testcase.jar Changeset: 43541217e9f7 Author: jiangli Date: 2012-07-26 17:24 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/43541217e9f7 7187046: Crash in ClassFileParser on solaris-ia32 during RetransformClasses. Summary: Lower compiler optimization level when compiling jvmtiClassFileReconstituter.cpp as a workaround for the solaris x86 5.10 cc bug. Reviewed-by: kvn, coleenp ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make Changeset: 611e8a669a2c Author: dlong Date: 2012-07-16 15:31 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/611e8a669a2c 7147464: Java crashed while executing method with over 8k of dneg operations Summary: replace recursive method with iterative Reviewed-by: kvn, twisti Contributed-by: dean.long at oracle.com ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp Changeset: a93a6d2c9e6c Author: jiangli Date: 2012-07-24 13:16 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a93a6d2c9e6c Merge Changeset: bcd1b9d98558 Author: jiangli Date: 2012-07-26 16:55 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/bcd1b9d98558 Merge Changeset: 72e0362c3f0c Author: amurillo Date: 2012-07-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/72e0362c3f0c Merge ! .hgtags - test/runtime/6294277/Test6294277.sh Changeset: 58f237a9e83a Author: amurillo Date: 2012-07-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/58f237a9e83a Added tag hs24-b18 for changeset 72e0362c3f0c ! .hgtags Changeset: c01c8e05ec8c Author: katleman Date: 2012-08-02 15:33 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/c01c8e05ec8c Added tag jdk8-b50 for changeset 58f237a9e83a ! .hgtags From lana.steuck at oracle.com Tue Aug 7 17:43:41 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 00:43:41 +0000 Subject: hg: jdk8/awt/jdk: 20 new changesets Message-ID: <20120808004742.C3E3C473F7@hg.openjdk.java.net> Changeset: 79c9847d4a5f Author: katleman Date: 2012-08-02 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/79c9847d4a5f Added tag jdk8-b50 for changeset e4bae5c53fca ! .hgtags Changeset: 773474da570b Author: khazra Date: 2012-07-18 15:19 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/773474da570b 7185051: Remove TestProviderLeak.java from the ProblemList Summary: Remove TestProviderLeak.java from jdk test problem list. Reviewed-by: khazra Contributed-by: dan.xu at oracle.com ! test/ProblemList.txt Changeset: 2c2e4ecc8f7e Author: chegar Date: 2012-07-19 18:19 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2c2e4ecc8f7e 7081476: test/java/net/InetSocketAddress/B6469803.java failing intermittently Reviewed-by: chegar Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/net/DatagramPacket/ReuseBuf.java Changeset: 84cd98a5641c Author: sherman Date: 2012-07-19 21:23 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/84cd98a5641c 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X Summary: to support Unicode nfd/nfc file path on Macos Reviewed-by: alanb ! make/java/nio/Makefile ! src/share/native/java/io/io_util.h ! src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MacOSXFileSystem.java + src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MacOSXNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h + src/solaris/native/sun/nio/fs/MacOSXNativeDispatcher.c + test/java/io/File/MacPathTest.java + test/java/io/File/MacPathTest.sh + test/java/nio/file/Path/MacPathTest.java + test/java/nio/file/Path/MacPathTest.sh Changeset: 5dc3f32c0d26 Author: weijun Date: 2012-07-21 19:56 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5dc3f32c0d26 7180907: Jarsigner -verify fails if rsa file used sha-256 with authenticated attributes Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 7e49c6f7507e Author: weijun Date: 2012-07-21 19:56 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7e49c6f7507e 7178649: TEST BUG: BadKdc3.java needs improvement to ignore the unlikely but possible timeout Reviewed-by: xuelei ! test/sun/security/krb5/auto/BadKdc.java ! test/sun/security/krb5/auto/BadKdc1.java ! test/sun/security/krb5/auto/BadKdc2.java ! test/sun/security/krb5/auto/BadKdc3.java ! test/sun/security/krb5/auto/BadKdc4.java Changeset: 11d5ddc6a6d4 Author: alanb Date: 2012-07-22 20:32 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/11d5ddc6a6d4 6633549: (dc) Include-mode filtering of IPv6 sources does not block datagrams on Linux Reviewed-by: chegar ! src/solaris/native/sun/nio/ch/DatagramDispatcher.c ! src/solaris/native/sun/nio/ch/Net.c ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java Changeset: f7731fc8c98a Author: weijun Date: 2012-07-24 09:20 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f7731fc8c98a 7179796: GSSExceptionImpl outputs duplicate mech oid Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java Changeset: e0e7cc711bda Author: xuelei Date: 2012-07-24 03:31 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e0e7cc711bda 7185576: Need to consider the connection timeout at test/com/sun/jndi/ldap/InvalidLdapFilters.java Reviewed-by: vinnie ! test/com/sun/jndi/ldap/InvalidLdapFilters.java Changeset: a18f2806bef2 Author: sherman Date: 2012-07-24 12:17 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a18f2806bef2 6653797: Reimplement JDK charset repository charsets.jar Summary: Migrated all jis based charsets to new implementation Reviewed-by: okutsu ! make/java/nio/FILES_java.gmk ! make/java/sun_nio/FILES_java.gmk ! make/sun/nio/cs/FILES_java.gmk ! make/tools/CharsetMapping/DoubleByte-X.java.template + make/tools/CharsetMapping/JIS_X_0201.c2b ! make/tools/CharsetMapping/JIS_X_0201.map + make/tools/CharsetMapping/JIS_X_0208.map + make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b + make/tools/CharsetMapping/JIS_X_0208_MS5022X.map + make/tools/CharsetMapping/JIS_X_0208_MS932.map + make/tools/CharsetMapping/JIS_X_0208_MS932.nr + make/tools/CharsetMapping/JIS_X_0208_Solaris.map + make/tools/CharsetMapping/JIS_X_0208_Solaris.nr + make/tools/CharsetMapping/JIS_X_0212.map + make/tools/CharsetMapping/JIS_X_0212_MS5022X.map + make/tools/CharsetMapping/JIS_X_0212_Solaris.map + make/tools/CharsetMapping/JIS_X_0212_Solaris.nr + make/tools/CharsetMapping/PCK.c2b + make/tools/CharsetMapping/PCK.map + make/tools/CharsetMapping/PCK.nr + make/tools/CharsetMapping/SJIS.c2b + make/tools/CharsetMapping/SJIS.map ! make/tools/CharsetMapping/dbcs ! make/tools/CharsetMapping/extsbcs ! make/tools/src/build/tools/charsetmapping/DBCS.java ! make/tools/src/build/tools/charsetmapping/SBCS.java ! src/share/classes/sun/nio/cs/SingleByte.java - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/IBM834.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java ! src/share/classes/sun/nio/cs/ext/MS50220.java ! src/share/classes/sun/nio/cs/ext/MS50221.java ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java ! src/solaris/classes/sun/awt/motif/X11JIS0201.java ! src/solaris/classes/sun/awt/motif/X11JIS0208.java ! src/solaris/classes/sun/awt/motif/X11JIS0212.java ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/sun/nio/cs/OLD/DoubleByteDecoder.java ! test/sun/nio/cs/OLD/DoubleByteEncoder.java + test/sun/nio/cs/OLD/EUC_JP_LINUX_OLD.java + test/sun/nio/cs/OLD/EUC_JP_OLD.java + test/sun/nio/cs/OLD/EUC_JP_Open_OLD.java + test/sun/nio/cs/OLD/JIS_X_0201_OLD.java + test/sun/nio/cs/OLD/JIS_X_0208_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0208_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0208_OLD.java + test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0212_OLD.java + test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Encoder.java ! test/sun/nio/cs/OLD/MS932_OLD.java + test/sun/nio/cs/OLD/PCK_OLD.java + test/sun/nio/cs/OLD/SJIS_OLD.java + test/sun/nio/cs/OLD/SingleByteDecoder.java + test/sun/nio/cs/OLD/SingleByteEncoder.java ! test/sun/nio/cs/OLD/TestIBMDB.java ! test/sun/nio/cs/TestX11JIS0201.java Changeset: 74ceda3a98a0 Author: khazra Date: 2012-07-24 13:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/74ceda3a98a0 7184287: (prefs) BackingStoreException when calling flush on root node[macosx] Summary: Change implementation to enable user without administrative privileges to call flush Reviewed-by: alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! test/ProblemList.txt Changeset: 42eac77355d2 Author: sherman Date: 2012-07-25 12:47 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/42eac77355d2 7186829: test/sun/nio/cs/OLD/JIS_X_0201_OLD.java failed in jdk8 TL nightly build Summary: fixed the test case Reviewed-by: alanb ! test/sun/nio/cs/OLD/JIS_X_0201_OLD.java Changeset: f267302093d4 Author: weijun Date: 2012-07-26 20:38 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f267302093d4 7187051: ShortRSAKeynnn.sh tests should do cleanup before start test Reviewed-by: xuelei ! test/sun/security/mscapi/ShortRSAKey1024.sh Changeset: 35fec642fd32 Author: coffeys Date: 2012-07-26 22:00 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/35fec642fd32 7179879: SSLSocket connect times out instead of throwing socket closed exception Reviewed-by: xuelei, chegar ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 018e555a7a07 Author: dmocek Date: 2012-07-27 16:53 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/018e555a7a07 7186111: fix bugs in java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup Reviewed-by: smarks, jgish ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/security.policy Changeset: a093f6247b52 Author: lana Date: 2012-07-27 22:26 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a093f6247b52 Merge Changeset: 78644d4a9a32 Author: dxu Date: 2012-07-30 04:57 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/78644d4a9a32 7185340: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Leaky.java failing intermittently [win] Reviewed-by: alanb ! test/java/nio/channels/AsynchronousSocketChannel/Leaky.java Changeset: 38263aa28324 Author: michaelm Date: 2012-07-30 22:32 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/38263aa28324 7120665: Change Java SE spec so that external networking not required Reviewed-by: alanb ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/package.html Changeset: b08697af1c56 Author: lana Date: 2012-07-31 18:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b08697af1c56 Merge - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java Changeset: e865efbc7105 Author: lana Date: 2012-08-06 15:53 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e865efbc7105 Merge - make/sunw/Makefile - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java From leonid.romanov at oracle.com Tue Aug 7 23:20:28 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 8 Aug 2012 10:20:28 +0400 Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: <5020FE7B.6020402@oracle.com> References: <5020FE7B.6020402@oracle.com> Message-ID: <001201cd752d$e9476200$bbd62600$@oracle.com> Looks reasonable. -----Original Message----- From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] Sent: Tuesday, August 07, 2012 3:40 PM To: Leonid Romanov; Mike Swingler; awt-dev at openjdk.java.net; macosx-port-dev at openjdk.java.net Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) Hi Everyone, Please review the fix. When we translate calls from our swing menu components to awt peer we resets information about shortcut in the setLabel(). This happens because of ScreenMenuItem.setAccelerator() method call peers setLabel(..,..,..) directly and does not initialize ScreenMenuItem.shortcut property. But default implementation of ScreenMenuItem.setLabel() assumes that this field(shortcut) will be initialized. This works on jdk6 because it does not reset shortcut if null or empty shortcut is provided. As a solution we can use peers methods directly in both cases. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 Webrev can be found at: http://cr.openjdk.java.net/~serb/7186371/webrev.00 -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Aug 8 09:32:12 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 08 Aug 2012 20:32:12 +0400 Subject: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders Message-ID: <5022948C.9090104@oracle.com> Hi Everyone, Please review the fix. We should support "apple.awt.fileDialogForDirectories" Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 Webrev can be found at: http://cr.openjdk.java.net/~serb/7161437/webrev.00/ Fix was contributed-by: Marco Dinacci Discussion here: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004295.html -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120808/2eca19f3/attachment.html From anthony.petrov at oracle.com Wed Aug 8 12:11:04 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 08 Aug 2012 23:11:04 +0400 Subject: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders In-Reply-To: <5022948C.9090104@oracle.com> References: <5022948C.9090104@oracle.com> Message-ID: <5022B9C8.8080501@oracle.com> The fix looks fine to me. Thanks Marco! -- best regards, Anthony On 8/8/2012 8:32 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > We should support "apple.awt.fileDialogForDirectories" > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7161437/webrev.00/ > > Fix was contributed-by: Marco Dinacci > Discussion here: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004295.html > > -- > Best regards, Sergey. > From omajid at redhat.com Wed Aug 8 15:37:50 2012 From: omajid at redhat.com (Omair Majid) Date: Wed, 08 Aug 2012 18:37:50 -0400 Subject: JAWT Breakage in OpenJDK 7/8 In-Reply-To: <50211599.6030207@oracle.com> References: <500ED0D6.2080908@redhat.com> <500FBD79.5050601@oracle.com> <50100574.9020607@redhat.com> <501683E9.8040201@oracle.com> <5016B905.2070106@redhat.com> <50211599.6030207@oracle.com> Message-ID: <5022EA3E.3040802@redhat.com> Hi Anthony, On 08/07/2012 09:18 AM, Anthony Petrov wrote: > I've also read the discussion that took place on build-dev@ regarding > this issue, and it seems to me that adding an RPATH entry to launchers > is the right solution for this issue. We may want to also add a comment > there and state that this entry is added specifically to address the > jawt use case. Perhaps it makes sense to also add a comment somewhere in > a jawt makefile to state that we rely on this RPATH entry in the > launcher. This way we can ensure that even if the jawt library is moved > around, the relevant RPATH entry gets updated accordingly as well. Thanks for you suggestions! I am going to post a patch based on your suggestions to build-dev. Thanks, Omair From Sergey.Bylokhov at oracle.com Thu Aug 9 00:46:11 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 09 Aug 2012 11:46:11 +0400 Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: References: <5020FE7B.6020402@oracle.com> Message-ID: <50236AC3.4090601@oracle.com> 09.08.2012 06:09, J.S. Ferguson wrote: > Seems to fix the menu visual problem, but now actions are firing twice when the accelerator is used as described in bug 7160951. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160951 Yes this bug on our radar. > > On Aug 7, 2012, at 4:39 AM, Sergey Bylokhov wrote: > >> Hi Everyone, >> Please review the fix. >> When we translate calls from our swing menu components to awt peer we resets information about shortcut in the setLabel(). >> This happens because of ScreenMenuItem.setAccelerator() method call peers setLabel(..,..,..) directly and does not initialize ScreenMenuItem.shortcut property. >> But default implementation of ScreenMenuItem.setLabel() assumes that this field(shortcut) will be initialized. >> >> This works on jdk6 because it does not reset shortcut if null or empty shortcut is provided. >> As a solution we can use peers methods directly in both cases. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 >> Webrev can be found at: http://cr.openjdk.java.net/~serb/7186371/webrev.00 >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey. From marco.dinacci at gmail.com Thu Aug 9 01:54:21 2012 From: marco.dinacci at gmail.com (Marco Dinacci) Date: Thu, 9 Aug 2012 09:54:21 +0100 Subject: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders In-Reply-To: <1344472884.55337.YahooMailNeo@web126004.mail.ne1.yahoo.com> References: <5022948C.9090104@oracle.com> <1344472884.55337.YahooMailNeo@web126004.mail.ne1.yahoo.com> Message-ID: Hi, > Just so that you know, the behavior of this dialog is different than the default OS X directory chooser behavior in that directory choosers to not allow users to also select files. True but unfortunately if you allow only for directory selection (by passing NO to setCanChooseFiles: when fCanChooseDirectories is YES) then there's no way to allow for both file and directory selection. The best would be to have control over both setCanChooseFiles and setCanChooseDirectories from Java but I guess that's part of the RFE. >Also the default select button should read [Choose] and not [Open]. So in the CFileDialog.m file the private method : The CFileDialog doesn't explicitly set the prompt string so I guess the behaviour depends on the OS version or on the localization. Setting it explicitly would override the default string and potentially confuse users. This test program on OSX Lion always displays "Open" no matter which combination of YES an NO I pass to setCanChooseFiles and setCanChooseDirectories. On which OS version do you see "Choose" ? #import "AppDelegate.h" @implementation AppDelegate @synthesize window = _window; - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { NSButton *button = [[[NSButton alloc] initWithFrame: NSMakeRect(10,10,120,40)] autorelease]; [[_window contentView] addSubview: button]; [button setTitle: @"Button"]; [button setTarget:self]; [button setAction:@selector(openDialog)]; } - (void)openDialog { NSOpenPanel* openDlg = [NSOpenPanel openPanel]; [openDlg setCanChooseFiles:YES]; [openDlg setCanChooseDirectories:YES]; [openDlg runModalForDirectory:nil file:nil]; } @end Best, Marco From artem.ananiev at oracle.com Fri Aug 10 02:30:29 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 10 Aug 2012 13:30:29 +0400 Subject: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders In-Reply-To: <5022948C.9090104@oracle.com> References: <5022948C.9090104@oracle.com> Message-ID: <5024D4B5.2060000@oracle.com> Hi, Sergey, Marco, the fix looks fine. Thanks, Artem On 8/8/2012 8:32 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > We should support "apple.awt.fileDialogForDirectories" > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7161437/webrev.00/ > > Fix was contributed-by: Marco Dinacci > Discussion here: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004295.html > > -- > Best regards, Sergey. > From anthony.petrov at oracle.com Fri Aug 10 05:25:09 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 10 Aug 2012 16:25:09 +0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <5024E2D8.4020208@oracle.COM> References: <2050199910.2465202.1344510954312.JavaMail.root@redhat.com> <50243012.6010300@redhat.com> <5024CB92.6000407@oracle.com> <5024E2D8.4020208@oracle.COM> Message-ID: <5024FDA5.3020802@oracle.com> Hi Kumar, Omair, [ adding awt-dev@ in the loop ] On 8/10/2012 2:30 PM, Kumar Srinivasan wrote: > a. although this is a build change, I have requested Omair to provide a > regression > test, IMO if we had a regression test to begin with, this would not > have been removed > during the RPATH work. We may have to check in a ".so" for linux and > solaris > variants. So my question to you. Where should such a test be parked, > in awt regression > test hierarchy ? We have a test for this already, actually, although it is closed and doesn't use jtreg. I filed 7190587 to fix this. For now Omair may proceed w/o a regression test. > b. this should be pushed via awt integration repo, thus allowing all > awt PITs to be run. I don't mind that. -- best regards, Anthony > > Thanks > > Kumar > >> Hi Omair, >> >> The fix looks good to me. I think Kumar needs to take a look at it, >> too, before the fix can be pushed to a repo. >> >> Thanks for finding and fixing this issue. >> >> -- >> best regards, >> Anthony >> >> On 8/10/2012 1:48 AM, Omair Majid wrote: >>> On 08/09/2012 07:15 AM, Andrew Hughes wrote: >>>> ----- Original Message ----- >>>>> Hi Kumar, >>>>> >>>>> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: >>>>>> My suggestion is to see if System.loadLibrary can be used, this >>>>>> will >>>>>> bode well for the modularization effort. >>>>> I discussed this with the folks at awt-dev and they would prefer to >>>>> avoid loading as much as possible. They are strongly against always >>>>> preloading libjawt.so. >>>>> >>>> For my 2c, I'm against it too. It doesn't seem the right fix. >>> >>> I can see your point, but both the solutions feel wrong to me. I can't >>> make up my mind which is the less bad. >>> >>>> I don't see an attachment :-( >>> >>> I guess the mailing list software stripped it out. I did attach it. >>> >>>> Shouldn't it be a webrev anyway? >>> >>> Old habits :) >>> >>> Webrev is at: >>> http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/ >>> >>> I have also put up a test case at: >>> http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz >>> >>> The test case is the exact same as that on >>> http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, >>> >>> except it automates the building and running. You will have to edit the >>> makefile to set the value of JDK_HOME. It should point to a j2sdk-image >>> directory. >>> >>> Then do: >>> $ make >>> $ make run >>> >>> Without the fix it should print an UnsatisfiedLinkError. With the fix, >>> it should show a window. >>> >>>> I built jdk8/build successfully just last week. What issues are you >>>> seeing? >>> >>> Errors building hotspot, I seem to recall. But I cant reproduce it >>> anymore after pulling today. I can now confirm that the fix works for me >>> with jdk8 too. >>> >>> Thanks, >>> Omair > From alexander.zuev at oracle.com Fri Aug 10 05:26:16 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 10 Aug 2012 16:26:16 +0400 Subject: [8] Please review fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) Message-ID: <5024FDE8.9080309@oracle.com> Hello, please review my fix for CR 7177144: [macosx] Drag and drop not working (regression in 7u6) I still tink we shouldn't move the instanceof check to the earlier stage since this check may be costly so it should not be performed unless other possibilities are ruled out by the less expensive checks. Bug description is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 Webrev can be found here: http://cr.openjdk.java.net/~kizune/7177144/webrev.01 With best regards, Alex From anthony.petrov at oracle.com Fri Aug 10 05:26:51 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 10 Aug 2012 16:26:51 +0400 Subject: [PATCH] Update RPATH to make loading libjawt possible In-Reply-To: <5024E585.5020707@oracle.COM> References: <2050199910.2465202.1344510954312.JavaMail.root@redhat.com> <50243012.6010300@redhat.com> <5024CB92.6000407@oracle.com> <5024E2D8.4020208@oracle.COM> <5024E585.5020707@oracle.COM> Message-ID: <5024FE0B.6030100@oracle.com> Well, it's complicated. There's problems with JAWT on the Mac currently, which makes it hard or even impossible to use it on that platform. We'll add support for the Mac to a test open-sourced with 7190587 once JAWT is working fine on the Mac in general. -- best regards, Anthony On 8/10/2012 2:42 PM, Kumar Srinivasan wrote: > Hi Anthony, Omair, > > Shouldn't there be a case for MacOSX as well ? > > Kumar > >> Hi Anthony, >> >> a. although this is a build change, I have requested Omair to provide >> a regression >> test, IMO if we had a regression test to begin with, this would >> not have been removed >> during the RPATH work. We may have to check in a ".so" for linux >> and solaris >> variants. So my question to you. Where should such a test be >> parked, in awt regression >> test hierarchy ? >> >> b. this should be pushed via awt integration repo, thus allowing all >> awt PITs to be run. >> >> Thanks >> >> Kumar >> >>> Hi Omair, >>> >>> The fix looks good to me. I think Kumar needs to take a look at it, >>> too, before the fix can be pushed to a repo. >>> >>> Thanks for finding and fixing this issue. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 8/10/2012 1:48 AM, Omair Majid wrote: >>>> On 08/09/2012 07:15 AM, Andrew Hughes wrote: >>>>> ----- Original Message ----- >>>>>> Hi Kumar, >>>>>> >>>>>> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote: >>>>>>> My suggestion is to see if System.loadLibrary can be used, this >>>>>>> will >>>>>>> bode well for the modularization effort. >>>>>> I discussed this with the folks at awt-dev and they would prefer to >>>>>> avoid loading as much as possible. They are strongly against always >>>>>> preloading libjawt.so. >>>>>> >>>>> For my 2c, I'm against it too. It doesn't seem the right fix. >>>> >>>> I can see your point, but both the solutions feel wrong to me. I can't >>>> make up my mind which is the less bad. >>>> >>>>> I don't see an attachment :-( >>>> >>>> I guess the mailing list software stripped it out. I did attach it. >>>> >>>>> Shouldn't it be a webrev anyway? >>>> >>>> Old habits :) >>>> >>>> Webrev is at: >>>> http://cr.openjdk.java.net/~omajid/webrevs/jawt-link-regression/00/ >>>> >>>> I have also put up a test case at: >>>> http://cr.openjdk.java.net/~omajid/jawt-test.tar.gz >>>> >>>> The test case is the exact same as that on >>>> http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html, >>>> >>>> except it automates the building and running. You will have to edit the >>>> makefile to set the value of JDK_HOME. It should point to a j2sdk-image >>>> directory. >>>> >>>> Then do: >>>> $ make >>>> $ make run >>>> >>>> Without the fix it should print an UnsatisfiedLinkError. With the fix, >>>> it should show a window. >>>> >>>>> I built jdk8/build successfully just last week. What issues are >>>>> you seeing? >>>> >>>> Errors building hotspot, I seem to recall. But I cant reproduce it >>>> anymore after pulling today. I can now confirm that the fix works >>>> for me >>>> with jdk8 too. >>>> >>>> Thanks, >>>> Omair >> > From Sergey.Bylokhov at oracle.com Fri Aug 10 06:10:28 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 10 Aug 2012 17:10:28 +0400 Subject: [8] Please review fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <5024FDE8.9080309@oracle.com> References: <5024FDE8.9080309@oracle.com> Message-ID: <50250844.1020706@oracle.com> 10.08.2012 16:26, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7177144: [macosx] Drag and drop not > working (regression in 7u6) > > I still tink we shouldn't move the instanceof check to the earlier > stage since this check may be costly > so it should not be performed unless other possibilities are ruled out > by the less expensive checks. At least one of them can be moved from coalesceMouseEvent to coalesceEvent if (e instanceof MouseEvent && !(e instanceof SunDropTargetEvent)) { } in cacheEQItem() it executes almost always. Why we should not cache these events? > > Bug description is: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 > Webrev can be found here: > http://cr.openjdk.java.net/~kizune/7177144/webrev.01 > > With best regards, > Alex -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Aug 10 06:11:50 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 10 Aug 2012 17:11:50 +0400 Subject: [8] Please review fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <5024FDE8.9080309@oracle.com> References: <5024FDE8.9080309@oracle.com> Message-ID: <50250896.5000009@oracle.com> 10.08.2012 16:26, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7177144: [macosx] Drag and drop not > working (regression in 7u6) > > I still tink we shouldn't move the instanceof check to the earlier > stage since this check may be costly > so it should not be performed unless other possibilities are ruled out > by the less expensive checks. At least one of them can be moved from coalesceMouseEvent to coalesceEvent if (e instanceof MouseEvent && !(e instanceof SunDropTargetEvent)) { } in cacheEQItem() it executes almost always. Why we should not cache these events? This fix affects all platforms it should? > > Bug description is: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 > Webrev can be found here: > http://cr.openjdk.java.net/~kizune/7177144/webrev.01 > > With best regards, > Alex -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri Aug 10 07:00:38 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 10 Aug 2012 18:00:38 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> Message-ID: <50251406.6060708@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ The comments are below: On 8/7/2012 6:47 PM, Mike Swingler wrote: > I noticed that, NSWindow's windowNumber is NSInteger, which is 32 bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a simple 32 bit int is probably not what you intended to do. fixed. > Also, have you considered simply calling -[NSWindow setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then removing the calls that flip it on and off in -[AWTView mouseEntered:] and -[AWTView mouseExited"]? This would also require a change in Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), which has a comment that states it only turns on mouse moved events if the window is currently under the mouse. I tried it. The result that I got is that a dragging mouse from one window to another does not generate mouse enter/exit events on the second window in case when tracking rect is used and the acceptsMouseMovedEvents flag is always set to YES. > I would think that AppKit should be more than happy to send you mouse-over/enter/exited events as long as you say you want them. Was this approach tried and didn't work for some reason? >> Hi, Alexander. >> Probably all this stuff can be simplified? Can you try to change TrackingRect to TrackingArea with appropriate flags like NSTrackingEnabledDuringMouseDrag etc. I changed the TrackingRect to TrackingArea in the updated fix. It now generates the mouse enter/exit events on the second window during drag. So it is not necessary to generates such events from our side. The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit events for component in case when a mouse is dragged from one window to another. Where the second window contains it's own components and the only way to know about tracking over them are drag events which receives the first window. I think that the LWWindowPeer class code can be simplified if we assume that window mouse enter/exit events are always come to the current window. So the component mouse enter/exit events can be tracked only in the current or topmost window. For this case I separated the global lastCommonMouseEventPeer which is necessary for the cursor manager and the local lastMouseEventPeer. According to the specification: The proper order of mouse-entered and mouse-exited events received by tracking-area objects in an application cannot be guaranteed. https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html So it seems it is not possible to have one lastMouseEventPeer instead of two: lastCommonMouseEventPeer and lastMouseEventPeer. And there are possible situations that we can receive mouse drag event between enter and exit. To handle this the isMouseOver flag is added to the LWWindowPeer class. So the component mouse enter/exit events are not generated if the window mouse exited event is received and window mouse entered is not. There is the test: test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java It shows that even using the TrackingArea some mouse enter/exit events are not generateed in the following cases: - window is created under the mouse - window changes it's bounds so it becomes under the mouse For this cases it still necessary to generate mouse enter/exit events from our side. I just moved the related code to one method synthesizeMouseEnteredExitedEventsForAllWindows. Thanks, Alexandr. >> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>> >>> This is a regression after the fix 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. >>> >>> In the case where a toolbar is created under a mouse and it is dragged over the initial window the mouse enter/exit events should not be generated for the components which are under the toolbar. >>> >>> The current fix is supposed to solve this regression and also to fix generation of mouse enter/exit events for all cases where a mouse is dragged from one window to another or a new window is created under a mouse (like it is implemented for toolbar). >>> >>> Let's see the following cases >>> 1) Mouse is dragged from a window and back to the same window. >>> The Mac OS X system generates a mouse exit event only the first time when a mouse is dragged from a window and does not generate mouse enter/exit events next times during one drag trace. >>> >>> 2) Mouse is dragged from one window to another. >>> The Mac OS X system does not generate mouse enter/exit events for the second window. >>> >>> 3) Mouse is dragged from one window to another and released. >>> In this case the Mac OS X system generates mouse enter event for the second window only after releasing the mouse. >>> >>> 4) Clicking on window creates a new window after that the new window is dragged (toolbar dragging). >>> >>> However the Java system generates mouse enter/exit events each time when a mouse is dragged over any window. >>> >>> To fix this the following methods are introduced: >>> - Get topmost window under mouse >>> - Synthesize mouse enter/exit events for all windows >>> >>> >>> The dispatchMouseEvent method from the LWWindowPeer class is handled previous and next components and is able to generate mouse enter/exit events for them. >>> However the the AWTView native class contains isMouseOver flag which value becomes inconsistent if we do not updated it. Because of this the fix generates the mouse enter/exit window events on the native side. >>> >>> Generating mouse enter/exit events always should be in order where mouse exit events are generated before the mouse enter events. >>> >>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to generate mouse enter/exit events for all windows during mouse drag or window creation/window bounds changing. >>> However only those windows which isMouseOver flag is differ from the isTopMostWindowUnderMouse state are affected. >>> This method also tries to generate both mouse enter and exit event for the same window but only one of them can be applicable because the isTopMostWindowUnderMouse state is not changed for these calls. >>> >>> So the window enter/exit events now are always generated from the native system and component enter/exit events are generated in the LWWindowPeer class. >>> >>> LWWindowPeer class now uses three links to components: current, last and topmostUnderMouse. All of them are necessary because in case when a mouse is dragged from one window to another the current component receives drag events and last and topmostUnderMouse links handle components mouse exit/enter events on the second window. >>> >>> Thanks, >>> Alexandr. >>> >>> >> >> -- >> Best regards, Sergey. >> From anthony.petrov at oracle.com Fri Aug 10 07:50:29 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 10 Aug 2012 18:50:29 +0400 Subject: [8] Please review fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <5024FDE8.9080309@oracle.com> References: <5024FDE8.9080309@oracle.com> Message-ID: <50251FB5.6010309@oracle.com> Alexander, Please insert a space after 'if' at the following line: > 437 if(entry.event instanceof SunDropTargetEvent) { For more details see: http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html section 8.2, point #1. -- best regards, Anthony On 8/10/2012 4:26 PM, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7177144: [macosx] Drag and drop not > working (regression in 7u6) > > I still tink we shouldn't move the instanceof check to the earlier > stage since this check may be costly > so it should not be performed unless other possibilities are ruled out > by the less expensive checks. > > Bug description is: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 > Webrev can be found here: > http://cr.openjdk.java.net/~kizune/7177144/webrev.01 > > With best regards, > Alex From artem.ananiev at oracle.com Fri Aug 10 08:41:11 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 10 Aug 2012 19:41:11 +0400 Subject: [8] Please review fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <5024FDE8.9080309@oracle.com> References: <5024FDE8.9080309@oracle.com> Message-ID: <50252B97.6060306@oracle.com> Hi, Alex, what about putting the instanceof check to eventToCacheIndex(), under MOUSE_DRAGGED switch, and return -1 for dnd events? We don't cache such unknown events, as well as don't coalesce them. Thanks, Artem On 8/10/2012 4:26 PM, Alexander Zuev wrote: > Hello, > > please review my fix for CR 7177144: [macosx] Drag and drop not working > (regression in 7u6) > > I still tink we shouldn't move the instanceof check to the earlier stage > since this check may be costly > so it should not be performed unless other possibilities are ruled out > by the less expensive checks. > > Bug description is: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 > Webrev can be found here: > http://cr.openjdk.java.net/~kizune/7177144/webrev.01 > > With best regards, > Alex From alexander.zuev at oracle.com Fri Aug 10 08:36:50 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Fri, 10 Aug 2012 19:36:50 +0400 Subject: [8] Please review fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <50250896.5000009@oracle.com> References: <5024FDE8.9080309@oracle.com> <50250896.5000009@oracle.com> Message-ID: <50252A92.2040900@oracle.com> Updated webrev can be found at http://cr.openjdk.java.net/~kizune/7177144/webrev.02 See comments inside. On 8/10/12 17:11, Sergey Bylokhov wrote: > 10.08.2012 16:26, Alexander Zuev wrote: >> Hello, >> >> please review my fix for CR 7177144: [macosx] Drag and drop not >> working (regression in 7u6) >> >> I still tink we shouldn't move the instanceof check to the earlier >> stage since this check may be costly >> so it should not be performed unless other possibilities are ruled >> out by the less expensive checks. > At least one of them can be moved from coalesceMouseEvent to > coalesceEvent > > if (e instanceof MouseEvent && !(e instanceof > SunDropTargetEvent)) { > > } Ok, fixed. > > in cacheEQItem() it executes almost always. Why we should not cache > these events? This fix affects all platforms it should? Because most of the SunDropTargetEvents are synchronous and if we drop the new one without calling consume() or processing it then DnD may simply lock. I have no idea why this does not happen more often but we can't afford to coalesce these events. Every incoming SunDropTargetEvent should go trough the normal processing. > >> >> Bug description is: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 >> Webrev can be found here: >> http://cr.openjdk.java.net/~kizune/7177144/webrev.01 >> >> With best regards, >> Alex > > From lana.steuck at oracle.com Fri Aug 10 14:28:31 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:28:31 +0000 Subject: hg: jdk8/awt/corba: Added tag jdk8-b51 for changeset 9b0f841ca9f7 Message-ID: <20120810212837.CFDD14749C@hg.openjdk.java.net> Changeset: 80689ff9cb49 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/80689ff9cb49 Added tag jdk8-b51 for changeset 9b0f841ca9f7 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:28:38 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:28:38 +0000 Subject: hg: jdk8/awt: Added tag jdk8-b51 for changeset 57c0aee73090 Message-ID: <20120810212839.44E484749D@hg.openjdk.java.net> Changeset: 8d24def5ceb3 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/8d24def5ceb3 Added tag jdk8-b51 for changeset 57c0aee73090 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:28:47 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:28:47 +0000 Subject: hg: jdk8/awt/jaxws: Added tag jdk8-b51 for changeset 1a70b6333ebe Message-ID: <20120810212853.266324749E@hg.openjdk.java.net> Changeset: f62bc618122e Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/f62bc618122e Added tag jdk8-b51 for changeset 1a70b6333ebe ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:28:43 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:28:43 +0000 Subject: hg: jdk8/awt/jaxp: Added tag jdk8-b51 for changeset dc1ea77ed9d9 Message-ID: <20120810212853.4838A4749F@hg.openjdk.java.net> Changeset: bd3c00d57614 Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/bd3c00d57614 Added tag jdk8-b51 for changeset dc1ea77ed9d9 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:28:44 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:28:44 +0000 Subject: hg: jdk8/awt/langtools: 7 new changesets Message-ID: <20120810212906.16986474A0@hg.openjdk.java.net> Changeset: 23032c78b2d1 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/23032c78b2d1 Added tag jdk8-b51 for changeset c4cd4cab2220 ! .hgtags Changeset: cddc2c894cc6 Author: mcimadamore Date: 2012-08-02 18:22 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/cddc2c894cc6 7175911: Simplify error reporting API in Check.CheckContext interface Summary: Make error messages generated during Check.checkType more uniform and more scalable Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/6979683/TestCast6979683_BAD34.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD35.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD36.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD37.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD38.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD39.java.errlog ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/OverrideChecks/6400189/T6400189a.out ! test/tools/javac/OverrideChecks/6400189/T6400189b.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel1.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel2.out ! test/tools/javac/T6326754.out ! test/tools/javac/TryWithResources/TwrOnNonResource.out ! test/tools/javac/cast/6270087/T6270087neg.out ! test/tools/javac/cast/6557182/T6557182.out ! test/tools/javac/cast/6665356/T6665356.out ! test/tools/javac/cast/6795580/T6795580.out ! test/tools/javac/cast/6932571/T6932571neg.out ! test/tools/javac/cast/7005095/T7005095neg.out ! test/tools/javac/cast/7005671/T7005671.out ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/IncompatibleTypes1.java ! test/tools/javac/diags/examples/InconvertibleTypes.java ! test/tools/javac/diags/examples/InferNoConformingAssignment.java ! test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java ! test/tools/javac/diags/examples/InferredDoNotConformToLower.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NoUniqueMaximalInstance.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PossibleLossPrecision.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/6207386/T6207386.out ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/diamond/neg/Neg10.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/generics/inference/6838943/T6838943.out ! test/tools/javac/generics/inference/7086586/T7086586.out ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/generics/rawOverride/7062745/T7062745neg.out ! test/tools/javac/generics/wildcards/6886247/T6886247_2.out ! test/tools/javac/multicatch/Neg06.out ! test/tools/javac/multicatch/Neg07.out ! test/tools/javac/types/CastObjectToPrimitiveTest.out ! test/tools/javac/varargs/6313164/T6313164.out ! test/tools/javac/varargs/7097436/T7097436.out Changeset: e5cf1569d3a4 Author: mcimadamore Date: 2012-08-02 18:23 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/e5cf1569d3a4 7175538: Integrate efectively final check with DA/DU analysis Summary: Allow generalized effectively-final analysis for all local variables Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java + test/tools/javac/lambda/EffectivelyFinalTest.java + test/tools/javac/lambda/EffectivelyFinalTest01.out + test/tools/javac/lambda/EffectivelyFinalTest02.out Changeset: 2d75e7c952b8 Author: mcimadamore Date: 2012-08-02 18:24 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/2d75e7c952b8 7187104: Inference cleanup: remove redundant exception classes in Infer.java Summary: Remove unused exception classes in Infer.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java Changeset: cfa70d7ac944 Author: lana Date: 2012-08-07 20:24 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/cfa70d7ac944 Merge Changeset: f071cd32d297 Author: sundar Date: 2012-08-08 22:17 +0530 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/f071cd32d297 7178324: Crash when compiling for(i : x) try(AutoCloseable x = ...) {} Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/TryWithResources/T7178324.java Changeset: 1d2db0e5eabc Author: lana Date: 2012-08-10 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/1d2db0e5eabc Merge From lana.steuck at oracle.com Fri Aug 10 14:28:47 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:28:47 +0000 Subject: hg: jdk8/awt/hotspot: 15 new changesets Message-ID: <20120810212928.77C07474A1@hg.openjdk.java.net> Changeset: 86a687be3f02 Author: amurillo Date: 2012-07-27 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/86a687be3f02 7187463: new hotspot build - hs24-b19 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 594dff5e3c2e Author: johnc Date: 2012-07-17 11:52 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/594dff5e3c2e 7173712: G1: Duplicated code in G1UpdateRSOrPushRefOopClosure::do_oop_nv() Summary: Duplicated code from G1RemSet::par_write_ref() inlined into G1UpdateRSOrPushRefOopClosure::do_oop_nv() was showing up in profiles with a fairly high amount of CPU time. Manually inline the main part of G1RemSet::par_write_ref() to eliminate the code duplication. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: d42fe3c3001d Author: johnc Date: 2012-07-17 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d42fe3c3001d 7184772: G1: Incorrect assert in HeapRegionLinkedList::add_as_head() Summary: Assertion incorrectly checks that _head is NULL and should be checking that _tail is NULL instead. Reviewed-by: johnc Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp Changeset: db823a892a55 Author: johnc Date: 2012-07-17 12:24 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/db823a892a55 7182260: G1: Fine grain RSet freeing bottleneck Summary: Chain the fine grain PerRegionTables in an individual RSet together and free them in bulk using a single operation. Reviewed-by: johnc, brutisso Contributed-by: Thomas Schatzl ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp Changeset: a2f7274eb6ef Author: tonyp Date: 2012-07-19 15:15 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a2f7274eb6ef 7114678: G1: various small fixes, code cleanup, and refactoring Summary: Various cleanups as a prelude to introducing iterators for HeapRegions. Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp Changeset: 113f4c73df61 Author: jmasa Date: 2012-07-24 14:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/113f4c73df61 Merge Changeset: 3080f4743cf2 Author: jmasa Date: 2012-07-26 23:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3080f4743cf2 Merge Changeset: ff58dfd5b977 Author: jmasa Date: 2012-07-27 21:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ff58dfd5b977 Merge Changeset: 3b01d0321dfa Author: zgu Date: 2012-07-30 10:25 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3b01d0321dfa 7186778: MachO decoder implementation for MacOSX Summary: Implementation of decoder for Apple's MacOSX. The implementation is based on the patch provided by Kevin Walls. Reviewed-by: coleenp, kamg, kevinw ! src/os/bsd/vm/decoder_machO.cpp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp Changeset: 4bfef6df8881 Author: zgu Date: 2012-07-30 07:21 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/4bfef6df8881 Merge Changeset: 5e2dc722e70d Author: andrew Date: 2012-07-31 16:01 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/5e2dc722e70d 7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 Summary: Templates need this object if not using template parameter in call Reviewed-by: coleenp, kamg, dholmes ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: e37a5219e297 Author: dcubed Date: 2012-07-31 18:37 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e37a5219e297 Merge Changeset: 3b3ad1642970 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3b3ad1642970 Merge Changeset: 663fc23da8d5 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/663fc23da8d5 Added tag hs24-b19 for changeset 3b3ad1642970 ! .hgtags Changeset: abc951e44e1b Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/abc951e44e1b Added tag jdk8-b51 for changeset 663fc23da8d5 ! .hgtags From oleg.pekhovskiy at oracle.com Fri Aug 10 14:26:39 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Sat, 11 Aug 2012 01:26:39 +0400 Subject: [8] Review request for 7153339: InternalError when drawLine with Xor and Antialiasing Message-ID: <50257C8F.1010201@oracle.com> Hi, Please review the fix for CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153339 Webrev: http://cr.openjdk.java.net/~bagiras/8/7153339.1/ Comments: XOR is not supported for D3D (see comments inside D3DSurfaceData.validatePipe()) and software rendering is used invalidating current D3DSurfaceData. So we have situation when component's peer has invalid SurfaceData and it's retrieved in SunGraphics2D.revalidateAll() through SurfaceData.getReplacement() without any check. That's why I added validity check there. Thanks, Oleg From lana.steuck at oracle.com Fri Aug 10 14:29:35 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:29:35 +0000 Subject: hg: jdk8/awt/jdk: 18 new changesets Message-ID: <20120810213308.19A83474A2@hg.openjdk.java.net> Changeset: b3b0d75cb117 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b3b0d75cb117 Added tag jdk8-b51 for changeset e865efbc7105 ! .hgtags Changeset: 21c590fdc8cb Author: mullan Date: 2012-08-01 11:06 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/21c590fdc8cb 7179715: OCSP revocation checking fails if the signer certificate is identified using the key ID Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 9a5a3741bac9 Author: mullan Date: 2012-08-01 11:08 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9a5a3741bac9 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 184da100cf45 Author: jgish Date: 2012-07-27 16:17 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/184da100cf45 6914123: (str) Missing synchronization in java.lang.String#contentEquals(CharSequence) Summary: Change contentEquals( CharSequence cs ) to do synchronization if cs is a StringBuffer Reviewed-by: mduigou Contributed-by: Jim Gish ! src/share/classes/java/lang/String.java Changeset: 75bda37d0337 Author: omajid Date: 2012-08-01 22:13 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/75bda37d0337 6844255: Potential stack corruption in GetJavaProperties Summary: Use dynamically allocated buffers for temp and encoding. Reviewed-by: alanb, andrew ! src/solaris/native/java/lang/java_props_md.c Changeset: b0bfa441d70f Author: mullan Date: 2012-08-02 10:40 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b0bfa441d70f 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) Reviewed-by: mullan, xuelei, weijun Contributed-by: jason.uh at oracle.com ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java + test/sun/security/x509/X509CRLImpl/Verify.java + test/sun/security/x509/X509CertImpl/Verify.java Changeset: 4e8bafdcefda Author: mullan Date: 2012-08-02 10:42 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4e8bafdcefda Merge Changeset: 8a82e5f9c47f Author: dmocek Date: 2012-08-02 18:12 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8a82e5f9c47f 7187876: ClassCastException in TCPTransport.executeAcceptLoop Reviewed-by: dholmes, smarks ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java Changeset: 1468b0af0d06 Author: sherman Date: 2012-08-03 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1468b0af0d06 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native Summary: re-implemented getBytesRead/Writtten() at java level Reviewed-by: andrew, alanb ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/zlib-1.2.5/compress.c ! src/share/native/java/util/zip/zlib-1.2.5/inflate.c ! src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java ! src/share/native/java/util/zip/zlib-1.2.5/zlib.h + test/java/util/zip/TotalInOut.java Changeset: 3521fcad4b5f Author: ksrini Date: 2012-07-31 06:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3521fcad4b5f 7188114: (launcher) need an alternate command line parser for Windows Reviewed-by: darcy, dholmes, jjh Contributed-by: akhil.arora at oracle.com + src/windows/bin/cmdtoargs.c Changeset: 2dd41a2dfe54 Author: ksrini Date: 2012-07-31 06:14 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2dd41a2dfe54 7146424: Wildcard expansion for single entry classpath Reviewed-by: dholmes, darcy, jjh, sherman ! make/common/Program.gmk ! make/java/jli/Makefile ! make/java/jli/mapfile-vers ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/jli_util.c ! src/share/bin/jli_util.h ! src/share/bin/main.c ! src/share/bin/wildcard.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties - src/solaris/bin/java_md.c ! src/solaris/bin/java_md_common.c ! src/windows/bin/java_md.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java ! test/tools/launcher/ToolsOpts.java Changeset: e0ef14d89741 Author: alanb Date: 2012-08-07 12:47 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e0ef14d89741 7076644: TEST_BUG: test/java/io/File/Basic.java fails with cygwin Reviewed-by: alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/io/File/basic.sh Changeset: b0d6552ba301 Author: lana Date: 2012-08-07 20:23 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b0d6552ba301 Merge - make/sunw/Makefile - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java ! src/solaris/native/java/lang/java_props_md.c Changeset: d87e86aaf2b3 Author: andrew Date: 2012-08-08 12:37 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d87e86aaf2b3 7189533: GetJavaProperties should free temporary file if subsequent allocations fails Summary: Add missing calls to free Reviewed-by: alanb, dholmes, sherman ! src/solaris/native/java/lang/java_props_md.c Changeset: a50e92a980a5 Author: alanb Date: 2012-08-08 15:31 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a50e92a980a5 7189886: (aio) Add test coverage for AsynchronousChannelGroup.withThreadPool Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java Changeset: a44671e0b6d7 Author: ksrini Date: 2012-08-08 09:29 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a44671e0b6d7 7189944: (launcher) test/tools/launcher/Arrrrghs.java needs a couple of minor fixes Reviewed-by: darcy, jgish ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: bf85c3ab2637 Author: dsamersoff Date: 2012-08-09 14:52 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/bf85c3ab2637 7183753: [TEST] Some colon in the diff for this test Summary: Reference output file contains extra colon Reviewed-by: sspitsyn, mgronlun ! test/sun/tools/jcmd/help_help.out Changeset: da8649489aff Author: lana Date: 2012-08-10 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/da8649489aff Merge From oleg.pekhovskiy at oracle.com Fri Aug 10 14:29:42 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Sat, 11 Aug 2012 01:29:42 +0400 Subject: [8] Review request for 7153339: InternalError when drawLine with Xor and Antialiasing Message-ID: <50257D46.7000702@oracle.com> Hi! Please review the fix for CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153339 Webrev: http://cr.openjdk.java.net/~bagiras/8/7153339.1/ Comments: XOR mode is not supported for D3D (see comments inside D3DSurfaceData.validatePipe()) and software rendering is used instead invalidating current D3DSurfaceData. So we have situation when component's peer has invalid SurfaceData and it's retrieved in SunGraphics2D.revalidateAll() through SurfaceData.getReplacement() without any check. That's why I added validity check there. Thanks, Oleg From philip.race at oracle.com Fri Aug 10 16:10:56 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 10 Aug 2012 16:10:56 -0700 Subject: [8] Review request for 7153339: InternalError when drawLine with Xor and Antialiasing In-Reply-To: <50257C8F.1010201@oracle.com> References: <50257C8F.1010201@oracle.com> Message-ID: <50259500.3050203@oracle.com> Oleg, This looks OK to me but since this is a shared code change I have to ask what testing you've done ? Also why not provide a regression test ? The provided test was interactive but I think it can be automated. You need another review and I'd like Jim to take a look. -phil. On 8/10/2012 2:26 PM, Oleg Pekhovskiy wrote: > Hi, > > Please review the fix for CR: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153339 > > Webrev: > http://cr.openjdk.java.net/~bagiras/8/7153339.1/ > > Comments: > XOR is not supported for D3D (see comments inside > D3DSurfaceData.validatePipe()) and > software rendering is used invalidating current D3DSurfaceData. > So we have situation when component's peer has invalid SurfaceData and > it's retrieved in > SunGraphics2D.revalidateAll() through SurfaceData.getReplacement() > without any check. > That's why I added validity check there. > > Thanks, > Oleg > > From niagarasoft20-macosxportdev at yahoo.com Thu Aug 9 06:29:21 2012 From: niagarasoft20-macosxportdev at yahoo.com (niagarasoft20-macosxportdev at yahoo.com) Date: Thu, 9 Aug 2012 06:29:21 -0700 (PDT) Subject: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders In-Reply-To: References: <5022948C.9090104@oracle.com> <1344472884.55337.YahooMailNeo@web126004.mail.ne1.yahoo.com> Message-ID: <1344518961.45115.YahooMailNeo@web126006.mail.ne1.yahoo.com> Marco, I don't know, but I'm just describing the same behaviors that was in the previous Apple Java implementations (i.e. choosing directories only + using [Choose] ) when setting the apple.awt.fileDialogForDirectoriessystem property flag. I should know because, about 2 years ago, I filed the same bug for Apple Java to be consistent with it's previous versions. It looks like they just hard coded the [Choose] button text because when I run it with different locales set, it always says [Choose]. Thanks again for all your hard work! Mike >________________________________ > From: Marco Dinacci >To: "niagarasoft20-macosxportdev at yahoo.com" >Cc: Sergey Bylokhov ; "macosx-port-dev at openjdk.java.net" ; "awt-dev at openjdk.java.net" ; Anthony Petrov >Sent: Thursday, August 9, 2012 4:54 AM >Subject: Re: [8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders > >Hi, > >> Just so that you know, the behavior of this dialog is different than the default OS X directory chooser behavior in that directory choosers to not allow users to also select files. > >True but unfortunately if you allow only for directory selection (by >passing NO to setCanChooseFiles: when fCanChooseDirectories is YES) >then there's no way to allow for both file and directory selection. >The best would be to have control over both setCanChooseFiles and >setCanChooseDirectories from Java but I guess that's part of the RFE. > >>Also the default select button should read [Choose] and not [Open]. So in the CFileDialog.m file the private method : > >The CFileDialog doesn't explicitly set the prompt string so I guess >the behaviour depends on the OS version or on the localization. >Setting it explicitly would override the default string and >potentially confuse users. This test program on OSX Lion always >displays "Open" no matter which combination of YES an NO I pass to >setCanChooseFiles and setCanChooseDirectories. On which OS version do >you see "Choose" ? > >#import "AppDelegate.h" > >@implementation AppDelegate > >@synthesize window = _window; > >- (void)applicationDidFinishLaunching:(NSNotification *)aNotification >{ >??? NSButton *button = [[[NSButton alloc] initWithFrame: >??? ??? ??? ??? ??? NSMakeRect(10,10,120,40)] autorelease]; >??? [[_window contentView] addSubview: button]; >??? [button setTitle: @"Button"]; >??? [button setTarget:self]; >??? [button setAction:@selector(openDialog)]; >} > >- (void)openDialog >{ >??? NSOpenPanel* openDlg = [NSOpenPanel openPanel]; >??? [openDlg setCanChooseFiles:YES]; >??? [openDlg setCanChooseDirectories:YES]; >??? [openDlg runModalForDirectory:nil file:nil]; >} > >@end > >Best, >Marco > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120809/7760db93/attachment.html From sergey.bylokhov at oracle.com Mon Aug 13 06:52:17 2012 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Mon, 13 Aug 2012 13:52:17 +0000 Subject: hg: jdk8/awt/jdk: 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders Message-ID: <20120813135259.F1CC7474E0@hg.openjdk.java.net> Changeset: b41845694f39 Author: serb Date: 2012-08-13 17:43 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b41845694f39 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders Reviewed-by: art, anthony Contributed-by: Marco Dinacci ! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/macosx/native/sun/awt/CFileDialog.h ! src/macosx/native/sun/awt/CFileDialog.m From alexander.zuev at oracle.com Mon Aug 13 07:28:12 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 13 Aug 2012 18:28:12 +0400 Subject: [8] Please review fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <50252B97.6060306@oracle.com> References: <5024FDE8.9080309@oracle.com> <50252B97.6060306@oracle.com> Message-ID: <50290EFC.1030104@oracle.com> Well, it works this way too and fix is much more compact so here it is - a new version available at http://cr.openjdk.java.net/~kizune/7177144/webrev.03 WBR, Alex On 8/10/12 19:41, Artem Ananiev wrote: > Hi, Alex, > > what about putting the instanceof check to eventToCacheIndex(), under > MOUSE_DRAGGED switch, and return -1 for dnd events? We don't cache > such unknown events, as well as don't coalesce them. > > Thanks, > > Artem > > On 8/10/2012 4:26 PM, Alexander Zuev wrote: >> Hello, >> >> please review my fix for CR 7177144: [macosx] Drag and drop not working >> (regression in 7u6) >> >> I still tink we shouldn't move the instanceof check to the earlier stage >> since this check may be costly >> so it should not be performed unless other possibilities are ruled out >> by the less expensive checks. >> >> Bug description is: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 >> Webrev can be found here: >> http://cr.openjdk.java.net/~kizune/7177144/webrev.01 >> >> With best regards, >> Alex From artem.ananiev at oracle.com Mon Aug 13 07:44:28 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 13 Aug 2012 18:44:28 +0400 Subject: [8] Please review fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <50290EFC.1030104@oracle.com> References: <5024FDE8.9080309@oracle.com> <50252B97.6060306@oracle.com> <50290EFC.1030104@oracle.com> Message-ID: <502912CC.5070906@oracle.com> Hi, Alex, I like this version of the fix much more than the previous one :) Could you also add a short comment to the code, why we handle DnD events this way, please? Thanks, Artem On 8/13/2012 6:28 PM, Alexander Zuev wrote: > Well, it works this way too and fix is much more compact so here it is - > a new version available at > > http://cr.openjdk.java.net/~kizune/7177144/webrev.03 > > WBR, > Alex > > On 8/10/12 19:41, Artem Ananiev wrote: >> Hi, Alex, >> >> what about putting the instanceof check to eventToCacheIndex(), under >> MOUSE_DRAGGED switch, and return -1 for dnd events? We don't cache >> such unknown events, as well as don't coalesce them. >> >> Thanks, >> >> Artem >> >> On 8/10/2012 4:26 PM, Alexander Zuev wrote: >>> Hello, >>> >>> please review my fix for CR 7177144: [macosx] Drag and drop not working >>> (regression in 7u6) >>> >>> I still tink we shouldn't move the instanceof check to the earlier stage >>> since this check may be costly >>> so it should not be performed unless other possibilities are ruled out >>> by the less expensive checks. >>> >>> Bug description is: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 >>> Webrev can be found here: >>> http://cr.openjdk.java.net/~kizune/7177144/webrev.01 >>> >>> With best regards, >>> Alex > From Sergey.Bylokhov at oracle.com Mon Aug 13 07:40:03 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 13 Aug 2012 18:40:03 +0400 Subject: [7u8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders Message-ID: <502911C3.6030805@oracle.com> Hi Everyone, Please review the fix. This is a direct back port from jdk 8 to jdk 7u8. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 Webrev can be found at: http://cr.openjdk.java.net/~serb/7161437/webrev.00/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b41845694f39 Fix was contributed-by: Marco Dinacci Discussion here: http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004295.html -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Aug 13 08:10:45 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 13 Aug 2012 19:10:45 +0400 Subject: [8] Please review fix for 7177144: [macosx] Drag and drop not working (regression in 7u6) In-Reply-To: <50290EFC.1030104@oracle.com> References: <5024FDE8.9080309@oracle.com> <50252B97.6060306@oracle.com> <50290EFC.1030104@oracle.com> Message-ID: <502918F5.9010400@oracle.com> Hi, Alexander. Fix looks good. 13.08.2012 18:28, Alexander Zuev wrote: > Well, it works this way too and fix is much more compact so here it is > - a new version available at > > http://cr.openjdk.java.net/~kizune/7177144/webrev.03 > > WBR, > Alex > > On 8/10/12 19:41, Artem Ananiev wrote: >> Hi, Alex, >> >> what about putting the instanceof check to eventToCacheIndex(), under >> MOUSE_DRAGGED switch, and return -1 for dnd events? We don't cache >> such unknown events, as well as don't coalesce them. >> >> Thanks, >> >> Artem >> >> On 8/10/2012 4:26 PM, Alexander Zuev wrote: >>> Hello, >>> >>> please review my fix for CR 7177144: [macosx] Drag and drop not working >>> (regression in 7u6) >>> >>> I still tink we shouldn't move the instanceof check to the earlier >>> stage >>> since this check may be costly >>> so it should not be performed unless other possibilities are ruled out >>> by the less expensive checks. >>> >>> Bug description is: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177144 >>> Webrev can be found here: >>> http://cr.openjdk.java.net/~kizune/7177144/webrev.01 >>> >>> With best regards, >>> Alex > -- Best regards, Sergey. From anthony.petrov at oracle.com Mon Aug 13 08:15:01 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 13 Aug 2012 19:15:01 +0400 Subject: [7u8] Review request for 7161437: [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders In-Reply-To: <502911C3.6030805@oracle.com> References: <502911C3.6030805@oracle.com> Message-ID: <502919F5.2070508@oracle.com> Looks fine. -- best regards, Anthony On 08/13/12 18:40, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > This is a direct back port from jdk 8 to jdk 7u8. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7161437/webrev.00/ > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b41845694f39 > > Fix was contributed-by: Marco Dinacci > Discussion here: > http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-May/004295.html > From alexander.zuev at oracle.com Mon Aug 13 08:20:02 2012 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Mon, 13 Aug 2012 15:20:02 +0000 Subject: hg: jdk8/awt/jdk: 2 new changesets Message-ID: <20120813152059.1AABD474E1@hg.openjdk.java.net> Changeset: adbef77870e1 Author: leonidr Date: 2012-08-13 17:53 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/adbef77870e1 7159381: [macosx] Dock Icon defaults to Generic Java Application Category Reviewed-by: anthony ! src/macosx/native/sun/osxapp/NSApplicationAWT.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.m Changeset: f63010f4655d Author: kizune Date: 2012-08-13 19:19 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f63010f4655d Merge From Sergey.Bylokhov at oracle.com Mon Aug 13 08:26:59 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 13 Aug 2012 19:26:59 +0400 Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: <001201cd752d$e9476200$bbd62600$@oracle.com> References: <5020FE7B.6020402@oracle.com> <001201cd752d$e9476200$bbd62600$@oracle.com> Message-ID: <50291CC3.8010002@oracle.com> Thanks Leonid. Does anybody has a chance to review it? 08.08.2012 10:20, Leonid Romanov wrote: > Looks reasonable. > > -----Original Message----- > From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] > Sent: Tuesday, August 07, 2012 3:40 PM > To: Leonid Romanov; Mike Swingler; awt-dev at openjdk.java.net; macosx-port-dev at openjdk.java.net > Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) > > Hi Everyone, > Please review the fix. > When we translate calls from our swing menu components to awt peer we > resets information about shortcut in the setLabel(). > This happens because of ScreenMenuItem.setAccelerator() method call > peers setLabel(..,..,..) directly and does not initialize > ScreenMenuItem.shortcut property. > But default implementation of ScreenMenuItem.setLabel() assumes that > this field(shortcut) will be initialized. > > This works on jdk6 because it does not reset shortcut if null or empty > shortcut is provided. > As a solution we can use peers methods directly in both cases. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7186371/webrev.00 > -- Best regards, Sergey. From alexander.zuev at oracle.com Mon Aug 13 08:49:41 2012 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Mon, 13 Aug 2012 15:49:41 +0000 Subject: hg: jdk8/awt/jdk: 7177144: [macosx] Drag and drop not working (regression in 7u6) Message-ID: <20120813154955.B4783474E2@hg.openjdk.java.net> Changeset: 0025dab4c283 Author: kizune Date: 2012-08-13 19:49 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0025dab4c283 7177144: [macosx] Drag and drop not working (regression in 7u6) Reviewed-by: art, serb ! src/share/classes/java/awt/EventQueue.java From leonid.romanov at oracle.com Tue Aug 14 07:12:01 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 14 Aug 2012 18:12:01 +0400 Subject: [8] Review request for 2226249: [macosx] Java processes on Mac should not use default Apple icon Message-ID: <83532F56-ED5B-49D9-ACBD-D1900A8591CD@oracle.com> Hi, This is a forward port of the fix that went into 7u6. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2226249 Webrev: http://cr.openjdk.java.net/~leonidr/2226249/webrev.00/ Thanks, Leonid. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120814/932eb5fd/attachment.html From anthony.petrov at oracle.com Tue Aug 14 07:26:45 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 14 Aug 2012 18:26:45 +0400 Subject: [8] Review request for 2226249: [macosx] Java processes on Mac should not use default Apple icon In-Reply-To: <83532F56-ED5B-49D9-ACBD-D1900A8591CD@oracle.com> References: <83532F56-ED5B-49D9-ACBD-D1900A8591CD@oracle.com> Message-ID: <502A6025.8060708@oracle.com> Hi Leonid, I do understand that the OS will install an icon from the bundle automatically if it is present, however, the following piece of code still looks strange since the bundleIcon is never used: > 268 NSString* bundleIcon = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CFBundleIconFile"]; > 269 if (bundleIcon == nil) { > 270 NSData* iconData; > 271 iconData = [[NSData alloc] initWithBytesNoCopy: sAWTIconData length: sizeof(sAWTIconData) freeWhenDone: NO]; > 272 iconImage = [[NSImage alloc] initWithData: iconData]; > 273 [iconData release]; > 274 } How about adding a short comment stating why it is unused in this code block? Otherwise the fix looks fine. -- best regards, Anthony On 8/14/2012 6:12 PM, Leonid Romanov wrote: > Hi, > This is a forward port of the fix that went into 7u6. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2226249 > Webrev: http://cr.openjdk.java.net/~leonidr/2226249/webrev.00/ > > Thanks, > Leonid. > > From Sergey.Bylokhov at oracle.com Tue Aug 14 07:30:07 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 14 Aug 2012 18:30:07 +0400 Subject: [8] Review request for 7172187 [macosx] JAWT native CALayer not positioned over Canvas Message-ID: <502A60EF.1060307@oracle.com> Hi Everyone, Please review the fix. Description of main changes: CPlatformComponent.java: -Unused peer and target references were removed. -Wrong return value for nativeSetBounds() was changed from long to void. AWTSurfaceLayers.m: -layer.bounds was replaced by layer.frame, because layer.bounds doesn't honour x and y position of the layer. -Wrong position inversion was removed. Also related fields were marked as volatile, if they were used in the different threads + javadoc cleanup. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172187 Webrev can be found at: http://cr.openjdk.java.net/~serb/7172187/webrev.00 -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120814/49fa10f3/attachment.html From artem.ananiev at oracle.com Tue Aug 14 07:39:11 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 14 Aug 2012 18:39:11 +0400 Subject: [8] Review request for 7172187 [macosx] JAWT native CALayer not positioned over Canvas In-Reply-To: <502A60EF.1060307@oracle.com> References: <502A60EF.1060307@oracle.com> Message-ID: <502A630F.3020306@oracle.com> Looks fine. Thanks, Artem On 8/14/2012 6:30 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. > Description of main changes: > > CPlatformComponent.java: > -Unused peer and target references were removed. > -Wrong return value for nativeSetBounds() was changed from long to > void. > AWTSurfaceLayers.m: > -layer.bounds was replaced by layer.frame, because layer.bounds > doesn't honour x and y position of the layer. > -Wrong position inversion was removed. > Also related fields were marked as volatile, if they were used in the > different threads + javadoc cleanup. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172187 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7172187/webrev.00 > > -- > Best regards, Sergey. > From anthony.petrov at oracle.com Tue Aug 14 07:40:47 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 14 Aug 2012 18:40:47 +0400 Subject: [8] Review request for 7172187 [macosx] JAWT native CALayer not positioned over Canvas In-Reply-To: <502A630F.3020306@oracle.com> References: <502A60EF.1060307@oracle.com> <502A630F.3020306@oracle.com> Message-ID: <502A636F.7040500@oracle.com> +1. -- best regards, Anthony On 8/14/2012 6:39 PM, Artem Ananiev wrote: > > Looks fine. > > Thanks, > > Artem > > On 8/14/2012 6:30 PM, Sergey Bylokhov wrote: >> Hi Everyone, >> Please review the fix. >> Description of main changes: >> >> CPlatformComponent.java: >> -Unused peer and target references were removed. >> -Wrong return value for nativeSetBounds() was changed from long to >> void. >> AWTSurfaceLayers.m: >> -layer.bounds was replaced by layer.frame, because layer.bounds >> doesn't honour x and y position of the layer. >> -Wrong position inversion was removed. >> Also related fields were marked as volatile, if they were used in the >> different threads + javadoc cleanup. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172187 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7172187/webrev.00 >> >> -- >> Best regards, Sergey. >> From oleg.pekhovskiy at oracle.com Tue Aug 14 13:09:20 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Wed, 15 Aug 2012 00:09:20 +0400 Subject: 7171412: awt Choice doesn't fire ItemStateChange when selecting item after select() call In-Reply-To: References: Message-ID: <502AB070.4030205@oracle.com> Hi Tim, sorry for long-awaited answer, thank you for your work and here are my comments... Reviewing the code related to 7171412 I found another issue 6770017 where 'm_selectedItem' was added. The purpose of that variable is to avoid surplus sending of ItemEvent when the user selects the same item once again (combo-box send CBN_CHANGE on Windows XP each time regardless the index chosen). From the other side mirroring index variable is not a clear solution. So your second version of fix is more suitable. Retrieving field value is better by performance but requires more changes like implementation of 'initIDs()' native method and calling it from Choice static section (when in non-headless mode) to initialize 'jfieldID' for 'selectedIndex'. 7171412 has 'medium' priority that is enough for the issue that touches a specific behavior of one component only and is not so critical as crash or deadlock. It would be nice to have an automatic regression test for this issue :) Thanks, Oleg 25.07.2012 1:31, Tim English wrote: > newb here.. Trying to follow procedure and run this by awt-dev before > I dive into this. > I ran into 7171412, produced a similar test case to the one in the bug > report, and then found the existing bug report. > I consider this High priority since any GUI that uses an awt Choice > could be showing the end user the wrong information > if the GUI is counting on the ItemListener for correct state. > The code in AwtChoice::WmNotify looks like it is trying to prevent > notifications if the user keeps selecting the same item over and over. > I came across a bug/feature request along those lines when searching > for 7171412. > Possible Fix 1 update m_selectedItem when select(int) called > void AwtChoice::_Select(void *param) > { > JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2); > SelectStruct *ss = (SelectStruct *)param; > jobject choice = ss->choice; > jint index = ss->index; > AwtChoice *c = NULL; > PDATA pData; > JNI_CHECK_PEER_GOTO(choice, done); > c = (AwtChoice *)pData; > if (::IsWindow(c->GetHWnd())) > { > c->SendMessage(CB_SETCURSEL, index); > + m_selectedItem = index; > // c->VerifyState(); > } > done: > env->DeleteGlobalRef(choice); > delete ss; > } > Possible Fix 2 Eliminate m_selectedItem and replace it with java > object value > Only notify java if java's selected index does not match the Windows > control selected index > This eliminates the m_selectedItem so we only have 2 copies of the > state instead of 3. > It is probably more efficient to hit the java field, directly, but I > have not researched jfieldID. > This is just a first stab. > MsgRouting AwtChoice::WmNotify(UINT notifyCode) > { > if (notifyCode == CBN_SELCHANGE) { > int selectedItem = (int)SendMessage(CB_GETCURSEL); > + // tim_english: not sure if it is legal to call from here > + JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2); > + jobject target = GetTarget(env); > + int javaIndex = JNU_CallMethodByName(env, NULL, target, > "getSelectedIndex", "()I").i; > + env->DeleteLocalRef(target); > > + if (selectedItem != CB_ERR && javaIndex != selectedItem){ > - if (selectedItem != CB_ERR && m_selectedItem != selectedItem){ > - m_selectedItem = selectedItem; > DoCallback("handleAction", "(I)V", selectedItem); > } > } else if (notifyCode == CBN_DROPDOWN) { > > > > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3a2355dcef13 > > http://hg.openjdk.java.net/jdk7u/jdk7u6/jdk/rev/3a2355dcef13 > > Any advice is appreciated.. > Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120815/e69e4581/attachment.html From omajid at redhat.com Tue Aug 14 14:20:11 2012 From: omajid at redhat.com (omajid at redhat.com) Date: Tue, 14 Aug 2012 21:20:11 +0000 Subject: hg: jdk8/awt/jdk: 7190813: (launcher) RPATH needs to have additional paths Message-ID: <20120814212038.644444751B@hg.openjdk.java.net> Changeset: f003387c33ad Author: omajid Date: 2012-08-14 17:11 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f003387c33ad 7190813: (launcher) RPATH needs to have additional paths Reviewed-by: anthony, ksrini ! make/common/Program.gmk ! make/sun/jawt/Makefile + test/tools/launcher/RunpathTest.java From pavel.porvatov at oracle.com Wed Aug 15 03:36:21 2012 From: pavel.porvatov at oracle.com (pavel.porvatov at oracle.com) Date: Wed, 15 Aug 2012 10:36:21 +0000 Subject: hg: jdk8/awt/jdk: 7190543: Nimbus LaF: regression: JSplitPane is not opaque -- or should it? Message-ID: <20120815103649.19D814752E@hg.openjdk.java.net> Changeset: 164919db548b Author: rupashka Date: 2012-08-15 14:33 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/164919db548b 7190543: Nimbus LaF: regression: JSplitPane is not opaque -- or should it? Reviewed-by: alexsch + test/javax/swing/JSplitPane/4201995/bug4201995.java From sergey.bylokhov at oracle.com Wed Aug 15 04:44:32 2012 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Wed, 15 Aug 2012 11:44:32 +0000 Subject: hg: jdk8/awt/jdk: 7172187: [macosx] JAWT native CALayer not positioned over Canvas Message-ID: <20120815114452.726B24752F@hg.openjdk.java.net> Changeset: 65d874d16d59 Author: serb Date: 2012-08-15 15:02 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/65d874d16d59 7172187: [macosx] JAWT native CALayer not positioned over Canvas Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/PlatformComponent.java ! src/macosx/classes/sun/lwawt/macosx/CFRetainedResource.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java ! src/macosx/native/sun/awt/AWTSurfaceLayers.m From oleg.pekhovskiy at oracle.com Wed Aug 15 15:52:29 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 16 Aug 2012 02:52:29 +0400 Subject: 7171412: awt Choice doesn't fire ItemStateChange when selecting item after select() call In-Reply-To: References: , <502AB070.4030205@oracle.com> Message-ID: <502C282D.2050804@oracle.com> Hi Tim, please see my comments below... Thanks, Oleg 15.08.2012 23:11, Tim English wrote: > Thanks for the reply, Oleg. > > Should I try jumping on jdk7u8? I first started with jdk8, but > following the procedures for it seemed like there were lots of > pieces/scripts that were missing from jdk8. The rule is simple: if fixes to jdk8 and jdk7u are different you prepare them separately, if they are equal you prepare the fix to jdk8 first, then do backport. http://openjdk.java.net/contribute/ (5. Know what to expect, last paragraph). > > I was thinking that Fix 1 would be appropriate for a jdk7u > implementation as a patch. Merge it into 8 (or patch 8 with Fix 1 -> > 7uN) but then supersede it in 8 by something along the lines of Fix 2. > > Since the 7 code is already stable, future maintenance concerns > that Fix 2 address would not be as critical in 7. If new code is ever > added to 8 or later, the strategy of Fix 2 should reduce other > regressions. > > If your rating is "crash" == priority High, I agree this would be > Medium on your radar. > > On our internal rating scale, anything that will insert incorrect data > into the database is what we consider "Show Stopper". > > This falls in our "Show Stopper" category since the user might might > be looking at "A" on the windows control, but the Java control just > /knows /that the value is"B". "B" gets inserted into the DB. Fail. I > just ran a query and there are over 1100 Choice fields in our codebase. > I agree that for your application that could be "show stopper", But the fix for 6770017 was pushed before jdk7 was released. It means that such behavior is "normal" for jdk7 and its updates. In other words somebody could rely on such behavior having workaround and thus by fixing that we could break its logic. Nevertheless, I'm not the person who make the final decision on issue's priority :) > Slightly different topic around gmake: > > I would try to get a regression for this (using the "robot" API?), Yes, you should use robot for that. > but I could never get the "sanity" target to build cleanly. That is > also the reason I have not tried committing (to the "gate"?). I am > positive (have you ever heard that before?), that Fix 1 is safe and > will fix 7171412, but it would be nice to see it work! If I could > have compiled it and confirmed the change, I probably would have > just emailed the fix in and hope someone else would commit it. > Just review the boundary points between java and the windows control > via the SendMessage calls; they are nice and isolated. > > I think my cygwin is too new and that is why make is failing. Some > conlicft in the gmake system where windows drive letter colons are > confusing the make parser. *Is there a mercurial repository where they > keep the preferred versions of cygwin, etc used in the build > process?* (open source tools of course, we wouldn't want to check > in VS2010)**The minimum cygwin version is specified in the docs, > but the current cygwin is far beyond that older version. I will have > to try to hunt up an older version. > > I tried remapping everything via cygdrive to work around the colons, > but there were still a few references I was having trouble shaking. I > think it was from some derived names. > > > I have been leaving the sanityCheckMessages.txt open in my desktop to > remind me of this. > I suspect that TOPDIR(.) is resolving to S:\jdk7u6 when it is > substituted, when I need . to resolve to /cygdrive/s/jdk7u6. > > Build Directory Structure: > CWD = /cygdrive/s/jdk7u6 > TOPDIR = *. > * I strongly recommend you to read "OpenJDK Build README" from here: http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html Pay attention to the notes about GNU Make 3.81 usage (it could be downloaded from here http://ftp.gnu.org/pub/gnu/make/ ). I also advice you to build just jdk workspace (http://hg.openjdk.java.net/jdk7u/jdk7u/jdk) and use ALT_JDK_IMPORT_PATH with the path to the latest jdk8 (http://jdk8.java.net/download.html) or jdk7u (http://jdk7.java.net/download.html) build. > I stopped after 3 or 4 days, because I have to work on some of my own > code "opportunities" before I will get a chance to try again. > Hopefully, I will get back to the gmake/cygwin stuffit next week. > > Thanks, > Tim > > > *I am a newb to committing for JDK, not to Java nor programming. I > have been using Java since 1.0, and I used to program WinAPI starting > with 2.1 and stopping after NT 4.0. Seriously, the WinAPI really has > NOT changed much since 2.1, Protected Memory and Combo Boxes > were radical advances for 3.0. You could commit to your local repository but you couldn't push to hg.openjdk.java.net. There are rules to become a committer ("pusher" indeed): http://openjdk.java.net/projects/ > > *From the rash of emails the last few weeks, I can tell that you all > have been BUSY! > > *Funny story here... while updating from mercurial, McAfee clobbered a > test jar as an "invalid format" that was commited as part of a > regression test that ....drum roll, please... checks for "invalid > format". I don't think this is considered a PASS since the test case > won't find the bad jar! lol > > ------------------------------------------------------------------------ > Date: Wed, 15 Aug 2012 00:09:20 +0400 > From: oleg.pekhovskiy at oracle.com > To: tim_english at hotmail.com; awt-dev at openjdk.java.net > Subject: Re: 7171412: awt Choice doesn't fire > ItemStateChange when selecting item after select() call > > Hi Tim, > > sorry for long-awaited answer, thank you for your work and here are my > comments... > > Reviewing the code related to 7171412 I found another issue 6770017 > where 'm_selectedItem' was added. > The purpose of that variable is to avoid surplus sending of ItemEvent > when the user selects the same item once again > (combo-box send CBN_CHANGE on Windows XP each time regardless the > index chosen). > From the other side mirroring index variable is not a clear solution. > So your second version of fix is more suitable. > > Retrieving field value is better by performance but requires more > changes like implementation of 'initIDs()' native method > and calling it from Choice static section (when in non-headless mode) > to initialize 'jfieldID' for 'selectedIndex'. > > 7171412 has 'medium' priority that is enough for the issue that > touches a specific behavior of one component only > and is not so critical as crash or deadlock. > > It would be nice to have an automatic regression test for this issue :) > > Thanks, > Oleg > > 25.07.2012 1:31, Tim English wrote: > > newb here.. Trying to follow procedure and run this by awt-dev > before I dive into this. > I ran into 7171412, produced a similar test case to the one in the > bug report, and then found the existing bug report. > I consider this High priority since any GUI that uses an awt > Choice could be showing the end user the wrong information > if the GUI is counting on the ItemListener for correct state. > The code in AwtChoice::WmNotify looks like it is trying to prevent > notifications if the user keeps selecting the same item over and over. > I came across a bug/feature request along those lines when > searching for 7171412. > Possible Fix 1 update m_selectedItem when select(int) called > void AwtChoice::_Select(void *param) > { > JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2); > SelectStruct *ss = (SelectStruct *)param; > jobject choice = ss->choice; > jint index = ss->index; > AwtChoice *c = NULL; > PDATA pData; > JNI_CHECK_PEER_GOTO(choice, done); > c = (AwtChoice *)pData; > if (::IsWindow(c->GetHWnd())) > { > c->SendMessage(CB_SETCURSEL, index); > + m_selectedItem = index; > // c->VerifyState(); > } > done: > env->DeleteGlobalRef(choice); > delete ss; > } > Possible Fix 2 Eliminate m_selectedItem and replace it with java > object value > Only notify java if java's selected index does not match the > Windows control selected index > This eliminates the m_selectedItem so we only have 2 copies of the > state instead of 3. > It is probably more efficient to hit the java field, directly, but > I have not researched jfieldID. > This is just a first stab. > MsgRouting AwtChoice::WmNotify(UINT notifyCode) > { > if (notifyCode == CBN_SELCHANGE) { > int selectedItem = (int)SendMessage(CB_GETCURSEL); > + // tim_english: not sure if it is legal to call from here > + JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2); > + jobject target = GetTarget(env); > + int javaIndex = JNU_CallMethodByName(env, NULL, target, > "getSelectedIndex", "()I").i; > + env->DeleteLocalRef(target); > > + if (selectedItem != CB_ERR && javaIndex != selectedItem){ > - if (selectedItem != CB_ERR && m_selectedItem != > selectedItem){ > - m_selectedItem = selectedItem; > DoCallback("handleAction", "(I)V", selectedItem); > } > } else if (notifyCode == CBN_DROPDOWN) { > > > > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3a2355dcef13 > > http://hg.openjdk.java.net/jdk7u/jdk7u6/jdk/rev/3a2355dcef13 > > Any advice is appreciated.. > Tim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120816/112f5595/attachment.html From artem.ananiev at oracle.com Thu Aug 16 09:57:11 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 16 Aug 2012 20:57:11 +0400 Subject: 7171412: awt Choice doesn't fire ItemStateChange when selecting item after select() call In-Reply-To: References: Message-ID: <502D2667.2010304@oracle.com> Hi, Tim, see my comments below. On 7/25/2012 1:31 AM, Tim English wrote: > newb here.. Trying to follow procedure and run this by awt-dev before I > dive into this. > I ran into 7171412, produced a similar test case to the one in the bug > report, and then found the existing bug report. > I consider this High priority since any GUI that uses an awt Choice > could be showing the end user the wrong information > if the GUI is counting on the ItemListener for correct state. I don't say counting on ItemEvents is wrong, but application developers should be careful here. And the problem is with missing events on Choice.select() calls. > The code in AwtChoice::WmNotify looks like it is trying to prevent > notifications if the user keeps selecting the same item over and over. Correct. > I came across a bug/feature request along those lines when searching for > 7171412. > Possible Fix 1 update m_selectedItem when select(int) called > void AwtChoice::_Select(void *param) > { > JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2); > SelectStruct *ss = (SelectStruct *)param; > jobject choice = ss->choice; > jint index = ss->index; > AwtChoice *c = NULL; > PDATA pData; > JNI_CHECK_PEER_GOTO(choice, done); > c = (AwtChoice *)pData; > if (::IsWindow(c->GetHWnd())) > { > c->SendMessage(CB_SETCURSEL, index); > + m_selectedItem = index; > // c->VerifyState(); > } > done: > env->DeleteGlobalRef(choice); > delete ss; > } This fix #1 looks fine. > Possible Fix 2 Eliminate m_selectedItem and replace it with java object > value > Only notify java if java's selected index does not match the Windows > control selected index > This eliminates the m_selectedItem so we only have 2 copies of the state > instead of 3. > It is probably more efficient to hit the java field, directly, but I > have not researched jfieldID. > This is just a first stab. > MsgRouting AwtChoice::WmNotify(UINT notifyCode) > { > if (notifyCode == CBN_SELCHANGE) { > int selectedItem = (int)SendMessage(CB_GETCURSEL); > + // tim_english: not sure if it is legal to call from here > + JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2); > + jobject target = GetTarget(env); > + int javaIndex = JNU_CallMethodByName(env, NULL, target, > "getSelectedIndex", "()I").i; > + env->DeleteLocalRef(target); > > + if (selectedItem != CB_ERR && javaIndex != selectedItem){ > - if (selectedItem != CB_ERR && m_selectedItem != selectedItem){ > - m_selectedItem = selectedItem; > DoCallback("handleAction", "(I)V", selectedItem); > } > } else if (notifyCode == CBN_DROPDOWN) { Reading the field value directly in WM_NOTIFY handler is also possible, but #1 seems more simple to me. > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3a2355dcef13 > > http://hg.openjdk.java.net/jdk7u/jdk7u6/jdk/rev/3a2355dcef13 > > Any advice is appreciated.. > Tim Since you're not OpenJDK Committer, you'll need to find a sponsor to push your fix to the workspace. Oleg or I can do this, if you don't mind. The fix for JDK8 don't require any additional approvals, but 7u8 process is more complex: explicit request to include a fix to 7u must be sent to jdk7u-dev alias [1]. But first of all, the fix should be pushed to JDK8 (see Rule 1 at [2]), so let's start with JDK8 and then proceed to 7u8. [1] http://openjdk.java.net/projects/jdk7u/approval-template.html [2] http://openjdk.java.net/projects/jdk7u/groundrules.html Thanks, Artem From oleg.pekhovskiy at oracle.com Fri Aug 17 05:49:21 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 17 Aug 2012 16:49:21 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue Message-ID: <502E3DD1.9020604@oracle.com> Hi! Please review the fix for CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 Webrev: http://cr.openjdk.java.net/~bagiras/8/7186109.1/ The following changes were made: 1. Removed flushLock from SunToolkit.flushPendingEvent() 2. Returned method PostEventQueue.flush() as 'synchronized' back 3. Added call of SunToolkit.flushPendingEvents() to EventQueue.detachDispatchThread(), right before pushPopLock.lock() 4. Removed !SunToolkit.isPostEventQueueEmpty() check from EventQueue.detachDispatchThread() 5. Removed SunToolkit.isPostEventQueueEmpty() & PostEventQueue.noEvents(); Thanks, Oleg From pavel.porvatov at oracle.com Fri Aug 17 06:07:40 2012 From: pavel.porvatov at oracle.com (pavel.porvatov at oracle.com) Date: Fri, 17 Aug 2012 13:07:40 +0000 Subject: hg: jdk8/awt/jdk: 7190597: Nimbus: regtest for 4235420 fails Message-ID: <20120817130820.CB82F475AC@hg.openjdk.java.net> Changeset: 8d570757fe95 Author: rupashka Date: 2012-08-17 17:04 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8d570757fe95 7190597: Nimbus: regtest for 4235420 fails Reviewed-by: alexsch + test/javax/swing/JTable/4235420/bug4235420.java From leonid.romanov at oracle.com Fri Aug 17 10:59:38 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Fri, 17 Aug 2012 21:59:38 +0400 Subject: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components Message-ID: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> Hi, Please review a fix for CR 7124375: [macosx] Focus isn't transfered as expected between components. The main issue addressed by this fix is that information about current focused window and focus owner isn't shared among LWKeyboardFocusManagerPeer instances. Also, while the current KeyboardFocusManager code makes it look like each KeyboardFocusManager instance needs its own peer instance, the reality is different because both WKeyboardFocusManagerPeer and XKeyboardManagerPeer doesn't have non static fields. In other words, all the WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. Therefore, there is no need in in multiple peer instances, one singleton peer shared among all the KeyboardFocusManager instances is enough. This fix addresses that issue as well by explicitly turning KeyboardManagerPeer implementations into singletons for the sake of cleaner code. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.00/ Thanks, Leonid. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120817/a0504437/attachment.html From luchsh at linux.vnet.ibm.com Sun Aug 19 22:17:24 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Mon, 20 Aug 2012 05:17:24 +0000 Subject: hg: jdk8/awt/jdk: 7188612: JTable's AccessibleJTable throws IllegalComponentStateException instead of null Message-ID: <20120820051809.4457A4763A@hg.openjdk.java.net> Changeset: 2fe9c1f0b16b Author: dingxmin Date: 2012-08-20 13:16 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2fe9c1f0b16b 7188612: JTable's AccessibleJTable throws IllegalComponentStateException instead of null Reviewed-by: rupashka ! src/share/classes/javax/swing/JTable.java + test/javax/swing/JTable/7188612/JTableAccessibleGetLocationOnScreen.java From sergey.malenkov at oracle.com Mon Aug 20 02:43:33 2012 From: sergey.malenkov at oracle.com (sergey.malenkov at oracle.com) Date: Mon, 20 Aug 2012 09:43:33 +0000 Subject: hg: jdk8/awt/jdk: 7189112: java.beans.Introspector misses write methods Message-ID: <20120820094426.B0E974763E@hg.openjdk.java.net> Changeset: fbf21a561c45 Author: malenkov Date: 2012-08-20 13:38 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/fbf21a561c45 7189112: java.beans.Introspector misses write methods Reviewed-by: rupashka ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7189112.java From Sergey.Bylokhov at oracle.com Mon Aug 20 02:55:34 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 20 Aug 2012 13:55:34 +0400 Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: <50291CC3.8010002@oracle.com> References: <5020FE7B.6020402@oracle.com> <001201cd752d$e9476200$bbd62600$@oracle.com> <50291CC3.8010002@oracle.com> Message-ID: <50320996.3010500@oracle.com> Does anybody has a chance to review it? Thanks. 13.08.2012 19:26, Sergey Bylokhov wrote: > Thanks Leonid. > > Does anybody has a chance to review it? > > 08.08.2012 10:20, Leonid Romanov wrote: >> Looks reasonable. >> >> -----Original Message----- >> From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] >> Sent: Tuesday, August 07, 2012 3:40 PM >> To: Leonid Romanov; Mike Swingler; awt-dev at openjdk.java.net; >> macosx-port-dev at openjdk.java.net >> Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts >> not displayed (7u6 regression) >> >> Hi Everyone, >> Please review the fix. >> When we translate calls from our swing menu components to awt peer we >> resets information about shortcut in the setLabel(). >> This happens because of ScreenMenuItem.setAccelerator() method call >> peers setLabel(..,..,..) directly and does not initialize >> ScreenMenuItem.shortcut property. >> But default implementation of ScreenMenuItem.setLabel() assumes that >> this field(shortcut) will be initialized. >> >> This works on jdk6 because it does not reset shortcut if null or empty >> shortcut is provided. >> As a solution we can use peers methods directly in both cases. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7186371/webrev.00 >> > > -- Best regards, Sergey. From artem.ananiev at oracle.com Mon Aug 20 03:13:49 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 20 Aug 2012 14:13:49 +0400 Subject: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components In-Reply-To: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> References: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> Message-ID: <50320DDD.8080906@oracle.com> Hi, Leonid, I don't see anything obviously wrong with the fix, however it must be reviewed by at least one more person. Thanks, Artem On 8/17/2012 9:59 PM, Leonid Romanov wrote: > Hi, > Please review a fix for CR 7124375: [macosx] Focus isn't transfered as > expected between components. > The main issue addressed by this fix is that information about current > focused window and focus owner isn't shared among > LWKeyboardFocusManagerPeer instances. Also, while the current > KeyboardFocusManager code makes it look like each KeyboardFocusManager > instance needs its own peer instance, the reality is different because > both WKeyboardFocusManagerPeer and XKeyboardManagerPeer doesn't have non > static fields. In other words, all the > WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. > Therefore, there is no need in in multiple peer instances, one singleton > peer shared among all the KeyboardFocusManager instances is enough. This > fix addresses that issue as well by explicitly turning > KeyboardManagerPeer implementations into singletons for the sake of > cleaner code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 > Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.00/ > > Thanks, > Leonid. > From Sergey.Bylokhov at oracle.com Mon Aug 20 03:29:17 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 20 Aug 2012 14:29:17 +0400 Subject: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components In-Reply-To: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> References: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> Message-ID: <5032117D.6030005@oracle.com> A few question - Is it ok that previously we have lwkfm per appcontext but not now? - javadoc for KeyboardFocusManagerPeerProvider.getKeyboardFocusManagerPeer() is not accurate - synchronisation model was changed for LW and X kfmp from internal object to synchronisation on this, but on windows there is no synchronisation this is expected? 17.08.2012 21:59, Leonid Romanov wrote: > Hi, > Please review a fix for CR 7124375: [macosx] Focus isn't transfered as expected between components. > The main issue addressed by this fix is that information about current focused window and focus owner isn't shared among LWKeyboardFocusManagerPeer instances. Also, while the current KeyboardFocusManager code makes it look like each KeyboardFocusManager instance needs its own peer instance, the reality is different because both WKeyboardFocusManagerPeer and XKeyboardManagerPeer doesn't have non static fields. In other words, all the WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. Therefore, there is no need in in multiple peer instances, one singleton peer shared among all the KeyboardFocusManager instances is enough. This fix addresses that issue as well by explicitly turning KeyboardManagerPeer implementations into singletons for the sake of cleaner code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 > Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.00/ > > Thanks, > Leonid. > -- Best regards, Sergey. From leonid.romanov at oracle.com Mon Aug 20 04:40:20 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 20 Aug 2012 15:40:20 +0400 Subject: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components In-Reply-To: <5032117D.6030005@oracle.com> References: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> <5032117D.6030005@oracle.com> Message-ID: <000101cd7ec8$9551d6e0$bff584a0$@oracle.com> Hi, - One have lwkfm per appcontex is the cause of this CR. I believe it is not necessary. However, after my fix has been pushed in 8, I'll ask Yuri to run all the focus tests, including deployment tests to make sure that nothing has been broken. - Thanks, I'll change javadoc - On Windows, thread-safety is ensured in the native code (unlike X and OS X, Windows implementation stores current focused window/focus owner in the native) -----Original Message----- From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] Sent: Monday, August 20, 2012 2:29 PM To: Leonid Romanov Cc: awt-dev at openjdk.java.net; macosx-port-dev-request at openjdk.java.net Subject: Re: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components A few question - Is it ok that previously we have lwkfm per appcontext but not now? - javadoc for KeyboardFocusManagerPeerProvider.getKeyboardFocusManagerPeer() is not accurate - synchronisation model was changed for LW and X kfmp from internal object to synchronisation on this, but on windows there is no synchronisation this is expected? 17.08.2012 21:59, Leonid Romanov wrote: > Hi, > Please review a fix for CR 7124375: [macosx] Focus isn't transfered as expected between components. > The main issue addressed by this fix is that information about current focused window and focus owner isn't shared among LWKeyboardFocusManagerPeer instances. Also, while the current KeyboardFocusManager code makes it look like each KeyboardFocusManager instance needs its own peer instance, the reality is different because both WKeyboardFocusManagerPeer and XKeyboardManagerPeer doesn't have non static fields. In other words, all the WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. Therefore, there is no need in in multiple peer instances, one singleton peer shared among all the KeyboardFocusManager instances is enough. This fix addresses that issue as well by explicitly turning KeyboardManagerPeer implementations into singletons for the sake of cleaner code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 > Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.00/ > > Thanks, > Leonid. > -- Best regards, Sergey. From anthony.petrov at oracle.com Mon Aug 20 07:42:59 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 20 Aug 2012 18:42:59 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <502E3DD1.9020604@oracle.com> References: <502E3DD1.9020604@oracle.com> Message-ID: <50324CF3.5070901@oracle.com> Hi Oleg, 1. src/share/classes/java/awt/EventQueue.java The comment block is about the lock()/unlock() synchronized block, so I suggest to move a call to flushPendingEvents() above the comment for clarity. 2. src/share/classes/sun/awt/SunToolkit.java 2a) We must synchronize access to the isFlushingPendingEvents flag. 2b) A comment at line 2110 is no longer relevant/accurate, I guess. BTW, how do we avoid the mentioned deadlock now? -- best regards, Anthony On 08/17/12 16:49, Oleg Pekhovskiy wrote: > Hi! > > Please review the fix for CR: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 > > Webrev: > http://cr.openjdk.java.net/~bagiras/8/7186109.1/ > > The following changes were made: > 1. Removed flushLock from SunToolkit.flushPendingEvent() > 2. Returned method PostEventQueue.flush() as 'synchronized' back > 3. Added call of SunToolkit.flushPendingEvents() to > EventQueue.detachDispatchThread(), > right before pushPopLock.lock() > 4. Removed !SunToolkit.isPostEventQueueEmpty() check from > EventQueue.detachDispatchThread() > 5. Removed SunToolkit.isPostEventQueueEmpty() & PostEventQueue.noEvents(); > > Thanks, > Oleg > From anthony.petrov at oracle.com Mon Aug 20 08:24:34 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 20 Aug 2012 19:24:34 +0400 Subject: [7u8] Review request for 7189350: Fix failed for CR 7162144 Message-ID: <503256B2.5040504@oracle.com> Hello, Please review a fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7189350 at: http://cr.openjdk.java.net/~anthony/7u8-1-missingAWTThread-7189350.0/ With this fix we resolve an issue originally described in 7162144 by properly handling thread interruption requests. We no longer override the Thread.interrupt() for the EDT, and hence don't clash with NetBeans using thread interruption for its own purposes. Note that there's still not a regression test since NetBeans' test is very heavy (over 100MB) and impractical for our purposes. However, the NetBeans team has tested a developer build with this fix and found no regressions. PS. We aren't yet sure if we want the same fix for JDK 8, hence we fix it for 7u8 first. -- best regards, Anthony From Sergey.Bylokhov at oracle.com Mon Aug 20 09:01:57 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 20 Aug 2012 20:01:57 +0400 Subject: [7u8] Review request for 7189350: Fix failed for CR 7162144 In-Reply-To: <503256B2.5040504@oracle.com> References: <503256B2.5040504@oracle.com> Message-ID: <50325F75.8040003@oracle.com> Is it ok that we reset the interrupted status in the 251-253? 20.08.2012 19:24, Anthony Petrov wrote: > Hello, > > Please review a fix for > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7189350 at: > > http://cr.openjdk.java.net/~anthony/7u8-1-missingAWTThread-7189350.0/ > > With this fix we resolve an issue originally described in 7162144 by > properly handling thread interruption requests. We no longer override > the Thread.interrupt() for the EDT, and hence don't clash with > NetBeans using thread interruption for its own purposes. > > Note that there's still not a regression test since NetBeans' test is > very heavy (over 100MB) and impractical for our purposes. However, the > NetBeans team has tested a developer build with this fix and found no > regressions. > > PS. We aren't yet sure if we want the same fix for JDK 8, hence we fix > it for 7u8 first. > > -- > best regards, > Anthony -- Best regards, Sergey. From artem.ananiev at oracle.com Mon Aug 20 09:20:25 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 20 Aug 2012 20:20:25 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <502E3DD1.9020604@oracle.com> References: <502E3DD1.9020604@oracle.com> Message-ID: <503263C9.4080206@oracle.com> Hi, Oleg, here are a few comments: 1. What is the reason of keeping "isFlushingPendingEvents" in SunToolkit, given that PEQ.flush() is synchronized (and therefore serialized) anyway? 2. flushPendingEvents(AppContext) may be moved directly to SunToolkit, so we don't need a separate sun-class for that. 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced by another one. Thanks, Artem On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: > Hi! > > Please review the fix for CR: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 > > Webrev: > http://cr.openjdk.java.net/~bagiras/8/7186109.1/ > > The following changes were made: > 1. Removed flushLock from SunToolkit.flushPendingEvent() > 2. Returned method PostEventQueue.flush() as 'synchronized' back > 3. Added call of SunToolkit.flushPendingEvents() to > EventQueue.detachDispatchThread(), > right before pushPopLock.lock() > 4. Removed !SunToolkit.isPostEventQueueEmpty() check from > EventQueue.detachDispatchThread() > 5. Removed SunToolkit.isPostEventQueueEmpty() & PostEventQueue.noEvents(); > > Thanks, > Oleg > From anthony.petrov at oracle.com Mon Aug 20 11:16:27 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 20 Aug 2012 22:16:27 +0400 Subject: [7u8] Review request for 7189350: Fix failed for CR 7162144 In-Reply-To: <50325F75.8040003@oracle.com> References: <503256B2.5040504@oracle.com> <50325F75.8040003@oracle.com> Message-ID: <50327EFB.5050606@oracle.com> We do not reset the status ourselves. The interrupted status has already been reset by code that invoked interrupted() and thrown the InterruptedException in the first place. There's nothing wrong with that, though, because we reset the doDispatch flag upon processing the exception. We now use this flag to indicate that event processing must be stopped. -- best regards, Anthony On 8/20/2012 8:01 PM, Sergey Bylokhov wrote: > Is it ok that we reset the interrupted status in the 251-253? > > 20.08.2012 19:24, Anthony Petrov wrote: >> Hello, >> >> Please review a fix for >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7189350 at: >> >> http://cr.openjdk.java.net/~anthony/7u8-1-missingAWTThread-7189350.0/ >> >> With this fix we resolve an issue originally described in 7162144 by >> properly handling thread interruption requests. We no longer override >> the Thread.interrupt() for the EDT, and hence don't clash with >> NetBeans using thread interruption for its own purposes. >> >> Note that there's still not a regression test since NetBeans' test is >> very heavy (over 100MB) and impractical for our purposes. However, the >> NetBeans team has tested a developer build with this fix and found no >> regressions. >> >> PS. We aren't yet sure if we want the same fix for JDK 8, hence we fix >> it for 7u8 first. >> >> -- >> best regards, >> Anthony > > From anton.tarasov at oracle.com Tue Aug 21 01:46:30 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 21 Aug 2012 12:46:30 +0400 Subject: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components In-Reply-To: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> References: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> Message-ID: <50334AE6.3030700@oracle.com> The changes look ok to me. Thanks, Anton. On 17.08.2012 21:59, Leonid Romanov wrote: > Hi, > Please review a fix for CR 7124375: [macosx] Focus isn't transfered as expected between components. > The main issue addressed by this fix is that information about current focused window and focus owner isn't shared among LWKeyboardFocusManagerPeer instances. Also, while the current KeyboardFocusManager code makes it look like each KeyboardFocusManager instance needs its own peer instance, the reality is different because both WKeyboardFocusManagerPeer and XKeyboardManagerPeer doesn't have non static fields. In other words, all the WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. Therefore, there is no need in in multiple peer instances, one singleton peer shared among all the KeyboardFocusManager instances is enough. This fix addresses that issue as well by explicitly turning KeyboardManagerPeer implementations into singletons for the sake of cleaner code. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 > Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.00/ > > Thanks, > Leonid. > From Sergey.Bylokhov at oracle.com Tue Aug 21 02:24:19 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 21 Aug 2012 13:24:19 +0400 Subject: [7u8] Review request for 7189350: Fix failed for CR 7162144 In-Reply-To: <50327EFB.5050606@oracle.com> References: <503256B2.5040504@oracle.com> <50325F75.8040003@oracle.com> <50327EFB.5050606@oracle.com> Message-ID: <503353C3.7070909@oracle.com> In this case this fix looks good. 20.08.2012 22:16, Anthony Petrov wrote > We do not reset the status ourselves. The interrupted status has > already been reset by code that invoked interrupted() and thrown the > InterruptedException in the first place. > > There's nothing wrong with that, though, because we reset the > doDispatch flag upon processing the exception. We now use this flag to > indicate that event processing must be stopped. > > -- > best regards, > Anthony > > On 8/20/2012 8:01 PM, Sergey Bylokhov wrote: >> Is it ok that we reset the interrupted status in the 251-253? >> >> 20.08.2012 19:24, Anthony Petrov wrote: >>> Hello, >>> >>> Please review a fix for >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7189350 at: >>> >>> http://cr.openjdk.java.net/~anthony/7u8-1-missingAWTThread-7189350.0/ >>> >>> With this fix we resolve an issue originally described in 7162144 by >>> properly handling thread interruption requests. We no longer >>> override the Thread.interrupt() for the EDT, and hence don't clash >>> with NetBeans using thread interruption for its own purposes. >>> >>> Note that there's still not a regression test since NetBeans' test >>> is very heavy (over 100MB) and impractical for our purposes. >>> However, the NetBeans team has tested a developer build with this >>> fix and found no regressions. >>> >>> PS. We aren't yet sure if we want the same fix for JDK 8, hence we >>> fix it for 7u8 first. >>> >>> -- >>> best regards, >>> Anthony >> >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 21 02:27:39 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 21 Aug 2012 13:27:39 +0400 Subject: [8] Review request for CR 7124375: [macosx] Focus isn't transfered as expected between components In-Reply-To: <000101cd7ec8$9551d6e0$bff584a0$@oracle.com> References: <2F431CF3-83C8-4602-8416-4FBE37716333@oracle.com> <5032117D.6030005@oracle.com> <000101cd7ec8$9551d6e0$bff584a0$@oracle.com> Message-ID: <5033548B.2060001@oracle.com> Thanks. Fix looks good. 20.08.2012 15:40, Leonid Romanov wrote: > Hi, > - One have lwkfm per appcontex is the cause of this CR. I believe it is not > necessary. However, after my fix has been pushed in 8, I'll ask Yuri to run > all the focus tests, including deployment tests to make sure that nothing > has been broken. > - Thanks, I'll change javadoc > - On Windows, thread-safety is ensured in the native code (unlike X and OS > X, Windows implementation stores current focused window/focus owner in the > native) > > -----Original Message----- > From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] > Sent: Monday, August 20, 2012 2:29 PM > To: Leonid Romanov > Cc: awt-dev at openjdk.java.net; macosx-port-dev-request at openjdk.java.net > Subject: Re: [8] Review request for CR 7124375: [macosx] Focus isn't > transfered as expected between components > > A few question > - Is it ok that previously we have lwkfm per appcontext but not now? > - javadoc for > KeyboardFocusManagerPeerProvider.getKeyboardFocusManagerPeer() is not > accurate > - synchronisation model was changed for LW and X kfmp from internal > object to synchronisation on this, but on windows there is no > synchronisation this is expected? > > 17.08.2012 21:59, Leonid Romanov wrote: >> Hi, >> Please review a fix for CR 7124375: [macosx] Focus isn't transfered as > expected between components. >> The main issue addressed by this fix is that information about current > focused window and focus owner isn't shared among LWKeyboardFocusManagerPeer > instances. Also, while the current KeyboardFocusManager code makes it look > like each KeyboardFocusManager instance needs its own peer instance, the > reality is different because both WKeyboardFocusManagerPeer and > XKeyboardManagerPeer doesn't have non static fields. In other words, all the > WKeyboardFocusManagerPeer/XKeyboardManagerPeer fields are static. Therefore, > there is no need in in multiple peer instances, one singleton peer shared > among all the KeyboardFocusManager instances is enough. This fix addresses > that issue as well by explicitly turning KeyboardManagerPeer implementations > into singletons for the sake of cleaner code. >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124375 >> Webrev: http://cr.openjdk.java.net/~leonidr/7124375/webrev.00/ >> >> Thanks, >> Leonid. >> > -- Best regards, Sergey. From zhouyx at linux.vnet.ibm.com Tue Aug 21 02:43:52 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Tue, 21 Aug 2012 17:43:52 +0800 Subject: The code example in Component class is missing 'implements' keywords Message-ID: Hello, I was reading the javadoc comments in Component.java and found this piece of code example: " class MyApp java.io.Serializable { BigObjectThatShouldNotBeSerializedWithAButton bigOne; " It seems the "implements" keyword is missing. Shall I report a bug for that ? -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120821/03ffd0ee/attachment.html From anthony.petrov at oracle.com Tue Aug 21 03:39:59 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 21 Aug 2012 14:39:59 +0400 Subject: The code example in Component class is missing 'implements' keywords In-Reply-To: References: Message-ID: <5033657F.6080101@oracle.com> Sure! Thanks. -- best regards, Anthony On 8/21/2012 1:43 PM, Sean Chou wrote: > Hello, > > I was reading the javadoc comments in Component.java and found this > piece of code example: > " > class MyApp java.io.Serializable > { > BigObjectThatShouldNotBeSerializedWithAButton bigOne; > " > > It seems the "implements" keyword is missing. Shall I report a bug > for that ? > > > -- > Best Regards, > Sean Chou > From pavel.porvatov at oracle.com Tue Aug 21 03:42:48 2012 From: pavel.porvatov at oracle.com (pavel.porvatov at oracle.com) Date: Tue, 21 Aug 2012 10:42:48 +0000 Subject: hg: jdk8/awt/jdk: 6866747: J2SE_Swing_Reg:can not see any HSB tab Message-ID: <20120821104318.51F744765A@hg.openjdk.java.net> Changeset: 8a2bc6e82d81 Author: rupashka Date: 2012-08-21 14:37 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8a2bc6e82d81 6866747: J2SE_Swing_Reg:can not see any HSB tab Reviewed-by: alexsch - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java From artem.ananiev at oracle.com Tue Aug 21 03:54:10 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 21 Aug 2012 14:54:10 +0400 Subject: [7u8] Review request for 7189350: Fix failed for CR 7162144 In-Reply-To: <503256B2.5040504@oracle.com> References: <503256B2.5040504@oracle.com> Message-ID: <503368D2.9070107@oracle.com> Hi, Anthony, since we discussed this fix offline last week, it obviously looks fine for me. Thanks, Artem On 8/20/2012 7:24 PM, Anthony Petrov wrote: > Hello, > > Please review a fix for > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7189350 at: > > http://cr.openjdk.java.net/~anthony/7u8-1-missingAWTThread-7189350.0/ > > With this fix we resolve an issue originally described in 7162144 by > properly handling thread interruption requests. We no longer override > the Thread.interrupt() for the EDT, and hence don't clash with NetBeans > using thread interruption for its own purposes. > > Note that there's still not a regression test since NetBeans' test is > very heavy (over 100MB) and impractical for our purposes. However, the > NetBeans team has tested a developer build with this fix and found no > regressions. > > PS. We aren't yet sure if we want the same fix for JDK 8, hence we fix > it for 7u8 first. > > -- > best regards, > Anthony From anthony.petrov at oracle.com Tue Aug 21 07:35:23 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 21 Aug 2012 18:35:23 +0400 Subject: [8] Review request for 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941) Message-ID: <50339CAB.30004@oracle.com> Hi Artem and Sergey, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7160609 at: http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.0/ Since OpenGL fails to create a square texture of size GL_MAX_TEXTURE_SIZE, we use the total screen bounds to limit possible window sizes on the Mac. Note that this behavior is consistent with the constraints imposed by the native OS on MS Windows, so this mustn't look like a Mac-only JDK limitation. -- best regards, Anthony From oleg.pekhovskiy at oracle.com Tue Aug 21 08:13:31 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Tue, 21 Aug 2012 19:13:31 +0400 Subject: [7u8] Review request for 7189350: Fix failed for CR 7162144 In-Reply-To: <503256B2.5040504@oracle.com> References: <503256B2.5040504@oracle.com> Message-ID: <5033A59B.7090108@oracle.com> Looks fine to me. Thanks, Oleg 20.08.2012 19:24, Anthony Petrov wrote: > Hello, > > Please review a fix for > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7189350 at: > > http://cr.openjdk.java.net/~anthony/7u8-1-missingAWTThread-7189350.0/ > > With this fix we resolve an issue originally described in 7162144 by > properly handling thread interruption requests. We no longer override > the Thread.interrupt() for the EDT, and hence don't clash with > NetBeans using thread interruption for its own purposes. > > Note that there's still not a regression test since NetBeans' test is > very heavy (over 100MB) and impractical for our purposes. However, the > NetBeans team has tested a developer build with this fix and found no > regressions. > > PS. We aren't yet sure if we want the same fix for JDK 8, hence we fix > it for 7u8 first. > > -- > best regards, > Anthony From anthony.petrov at oracle.com Tue Aug 21 08:21:55 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 21 Aug 2012 19:21:55 +0400 Subject: [7u8] Request for approval for CR 7189350: Fix failed for CR 7162144 Message-ID: <5033A793.5000801@oracle.com> Bug: http://bugs.sun.com/view_bug.do?bug_id=7189350 Webrev: http://cr.openjdk.java.net/~anthony/7u8-1-missingAWTThread-7189350.0/ Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2012-August/003309.html Reviewers: Sergey Bylokhov, Oleg Pekhovskiy, Artem Ananiev Note: we may consider a different fix for JDK 8. A SubCR for that release has already been filed. For now we want to push this fix to 7u8. -- best regards, Anthony From Sergey.Bylokhov at oracle.com Tue Aug 21 09:01:43 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 21 Aug 2012 20:01:43 +0400 Subject: [8] Review request for 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941) In-Reply-To: <50339CAB.30004@oracle.com> References: <50339CAB.30004@oracle.com> Message-ID: <5033B0E7.9020403@oracle.com> Hi,Anthony. I guess that getMinimumSize() in the setSizeConstraints should be wrapped with isMinimumSizeSet like it was in LWWindowsPeer, same for getMaximumSize() 21.08.2012 18:35, Anthony Petrov wrote: > Hi Artem and Sergey, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7160609 > at: > > http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.0/ > > Since OpenGL fails to create a square texture of size > GL_MAX_TEXTURE_SIZE, we use the total screen bounds to limit possible > window sizes on the Mac. Note that this behavior is consistent with > the constraints imposed by the native OS on MS Windows, so this > mustn't look like a Mac-only JDK limitation. > > -- > best regards, > Anthony -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 21 09:03:59 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 21 Aug 2012 20:03:59 +0400 Subject: [8] Review request for 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941) In-Reply-To: <5033B0E7.9020403@oracle.com> References: <50339CAB.30004@oracle.com> <5033B0E7.9020403@oracle.com> Message-ID: <5033B16F.1070309@oracle.com> Looks like this code is not necessary in jdk8 any more: 673 // Re-apply the size constraints and the size to ensure the space 674 // occupied by the grow box is counted properly 675 peer.updateMinimumSize(); 21.08.2012 20:01, Sergey Bylokhov ?????: > Hi,Anthony. > I guess that getMinimumSize() in the setSizeConstraints should be > wrapped with isMinimumSizeSet like it was in LWWindowsPeer, same for > getMaximumSize() > > 21.08.2012 18:35, Anthony Petrov wrote: >> Hi Artem and Sergey, >> >> Please review a fix for >> http://bugs.sun.com/view_bug.do?bug_id=7160609 at: >> >> http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.0/ >> >> Since OpenGL fails to create a square texture of size >> GL_MAX_TEXTURE_SIZE, we use the total screen bounds to limit possible >> window sizes on the Mac. Note that this behavior is consistent with >> the constraints imposed by the native OS on MS Windows, so this >> mustn't look like a Mac-only JDK limitation. >> >> -- >> best regards, >> Anthony > > -- Best regards, Sergey. From edvard.wendelin at oracle.com Wed Aug 22 01:35:46 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 22 Aug 2012 10:35:46 +0200 Subject: [7u8] Request for approval for CR 7189350: Fix failed for CR 7162144 In-Reply-To: <5033A793.5000801@oracle.com> References: <5033A793.5000801@oracle.com> Message-ID: <503499E2.4060708@oracle.com> Approved. On 08/21/2012 05:21 PM, Anthony Petrov wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7189350 > > Webrev: > http://cr.openjdk.java.net/~anthony/7u8-1-missingAWTThread-7189350.0/ > > Review thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2012-August/003309.html > > Reviewers: Sergey Bylokhov, Oleg Pekhovskiy, Artem Ananiev > > Note: we may consider a different fix for JDK 8. A SubCR for that > release has already been filed. For now we want to push this fix to 7u8. > > -- > best regards, > Anthony From zhouyx at linux.vnet.ibm.com Wed Aug 22 02:28:32 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Wed, 22 Aug 2012 17:28:32 +0800 Subject: [8] Review request for 7193169 : The code example in javadoc of Component class is missing 'implements' keywords Message-ID: Hello, One of the code example in javadoc of Component class misses 'implements' keyword, this is to add the word. Bug is at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193169 Webrev is at: http://cr.openjdk.java.net/~zhouyx/7193169/webrev.00/ Please take a look, thanks. On Tue, Aug 21, 2012 at 6:39 PM, Anthony Petrov wrote: > Sure! Thanks. > > -- > best regards, > Anthony > > > On 8/21/2012 1:43 PM, Sean Chou wrote: > >> Hello, >> >> I was reading the javadoc comments in Component.java and found this >> piece of code example: >> " >> class MyApp java.io.Serializable >> { >> BigObjectThatShouldNotBeSerial**izedWithAButton bigOne; >> " >> >> It seems the "implements" keyword is missing. Shall I report a bug >> for that ? >> >> >> -- >> Best Regards, >> Sean Chou >> >> -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120822/33533c71/attachment.html From anthony.petrov at oracle.com Wed Aug 22 04:58:51 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 22 Aug 2012 15:58:51 +0400 Subject: [8] Review request for 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941) In-Reply-To: <5033B16F.1070309@oracle.com> References: <50339CAB.30004@oracle.com> <5033B0E7.9020403@oracle.com> <5033B16F.1070309@oracle.com> Message-ID: <5034C97B.5000908@oracle.com> Hi Sergey, Thanks for the review. Please find my comments and a new version of the fix inline. On 8/21/2012 8:03 PM, Sergey Bylokhov wrote: > Looks like this code is not necessary in jdk8 any more: > > 673 // Re-apply the size constraints and the size to ensure the > space > 674 // occupied by the grow box is counted properly > 675 peer.updateMinimumSize(); There are two reasons I don't want to remove this code now: 1. This same fix needs to be back-ported to 7u8 where this code is required. 2. After changing the resizable style, native OS may or may not reset or somehow affect the maximum/minimum sizes of a window, and/or its real current size. This had best be investigated under a separate CR for JDK 8. > 21.08.2012 20:01, Sergey Bylokhov ?????: >> Hi,Anthony. >> I guess that getMinimumSize() in the setSizeConstraints should be >> wrapped with isMinimumSizeSet like it was in LWWindowsPeer, same for >> getMaximumSize() This makes sense even though the old code didn't do that in CPW.setMinimumSize(). Here's an updated webrev: http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.1/ -- best regards, Anthony >> >> 21.08.2012 18:35, Anthony Petrov wrote: >>> Hi Artem and Sergey, >>> >>> Please review a fix for >>> http://bugs.sun.com/view_bug.do?bug_id=7160609 at: >>> >>> http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.0/ >>> >>> Since OpenGL fails to create a square texture of size >>> GL_MAX_TEXTURE_SIZE, we use the total screen bounds to limit possible >>> window sizes on the Mac. Note that this behavior is consistent with >>> the constraints imposed by the native OS on MS Windows, so this >>> mustn't look like a Mac-only JDK limitation. >>> >>> -- >>> best regards, >>> Anthony >> >> > > From Sergey.Bylokhov at oracle.com Wed Aug 22 05:38:20 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Aug 2012 16:38:20 +0400 Subject: [8] Review request for 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941) In-Reply-To: <5034C97B.5000908@oracle.com> References: <50339CAB.30004@oracle.com> <5033B0E7.9020403@oracle.com> <5033B16F.1070309@oracle.com> <5034C97B.5000908@oracle.com> Message-ID: <5034D2BC.6010606@oracle.com> 22.08.2012 15:58, Anthony Petrov wrote: > Hi Sergey, > > Thanks for the review. Please find my comments and a new version of > the fix inline. Yep it would be good to have a CR that we should refactor CPF.setResizable(). Second version looks good, but I cannot be sure about changes in CGLGraphicsConfig.m. How this stuff defend as from the incorrect volatile image creation, does it crash too or it fails with "OGLSD_InitTextureObject: texture dimensions too large"? Also probably getMaxTextureWidth could be renamed to getMaxSurfaceWidth... etc? > > On 8/21/2012 8:03 PM, Sergey Bylokhov wrote: >> Looks like this code is not necessary in jdk8 any more: >> >> 673 // Re-apply the size constraints and the size to ensure >> the space >> 674 // occupied by the grow box is counted properly >> 675 peer.updateMinimumSize(); > > There are two reasons I don't want to remove this code now: > 1. This same fix needs to be back-ported to 7u8 where this code is > required. > 2. After changing the resizable style, native OS may or may not reset > or somehow affect the maximum/minimum sizes of a window, and/or its > real current size. This had best be investigated under a separate CR > for JDK 8. > > >> 21.08.2012 20:01, Sergey Bylokhov ?????: >>> Hi,Anthony. >>> I guess that getMinimumSize() in the setSizeConstraints should be >>> wrapped with isMinimumSizeSet like it was in LWWindowsPeer, same for >>> getMaximumSize() > > This makes sense even though the old code didn't do that in > CPW.setMinimumSize(). Here's an updated webrev: > > http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.1/ > > -- > best regards, > Anthony > >>> >>> 21.08.2012 18:35, Anthony Petrov wrote: >>>> Hi Artem and Sergey, >>>> >>>> Please review a fix for >>>> http://bugs.sun.com/view_bug.do?bug_id=7160609 at: >>>> >>>> http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.0/ >>>> >>>> Since OpenGL fails to create a square texture of size >>>> GL_MAX_TEXTURE_SIZE, we use the total screen bounds to limit >>>> possible window sizes on the Mac. Note that this behavior is >>>> consistent with the constraints imposed by the native OS on MS >>>> Windows, so this mustn't look like a Mac-only JDK limitation. >>>> >>>> -- >>>> best regards, >>>> Anthony >>> >>> >> >> -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Aug 22 06:07:29 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 22 Aug 2012 17:07:29 +0400 Subject: [8] Review request for 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941) In-Reply-To: <5034D2BC.6010606@oracle.com> References: <50339CAB.30004@oracle.com> <5033B0E7.9020403@oracle.com> <5033B16F.1070309@oracle.com> <5034C97B.5000908@oracle.com> <5034D2BC.6010606@oracle.com> Message-ID: <5034D991.4010805@oracle.com> Hi Sergey, On 8/22/2012 4:38 PM, Sergey Bylokhov wrote: > 22.08.2012 15:58, Anthony Petrov wrote: >> Hi Sergey, >> >> Thanks for the review. Please find my comments and a new version of >> the fix inline. > Yep it would be good to have a CR that we should refactor > CPF.setResizable(). I just filed 7193214. > Second version looks good, but I cannot be sure about changes in > CGLGraphicsConfig.m. Me neither. I'm not an expert in OpenGL. But this fix works for me. > How this stuff defend as from the incorrect volatile image creation, > does it crash too or it fails with "OGLSD_InitTextureObject: texture > dimensions too large"? It will throw an OOM. The same behavior is observed with Apple JDK. > Also probably getMaxTextureWidth could be renamed to > getMaxSurfaceWidth... etc? The GL_MAX_TEXTURE_SIZE is about "textures", so I'd like to preserve the current name. -- best regards, Anthony >> >> On 8/21/2012 8:03 PM, Sergey Bylokhov wrote: >>> Looks like this code is not necessary in jdk8 any more: >>> >>> 673 // Re-apply the size constraints and the size to ensure >>> the space >>> 674 // occupied by the grow box is counted properly >>> 675 peer.updateMinimumSize(); >> >> There are two reasons I don't want to remove this code now: >> 1. This same fix needs to be back-ported to 7u8 where this code is >> required. >> 2. After changing the resizable style, native OS may or may not reset >> or somehow affect the maximum/minimum sizes of a window, and/or its >> real current size. This had best be investigated under a separate CR >> for JDK 8. >> >> >>> 21.08.2012 20:01, Sergey Bylokhov ?????: >>>> Hi,Anthony. >>>> I guess that getMinimumSize() in the setSizeConstraints should be >>>> wrapped with isMinimumSizeSet like it was in LWWindowsPeer, same for >>>> getMaximumSize() >> >> This makes sense even though the old code didn't do that in >> CPW.setMinimumSize(). Here's an updated webrev: >> >> http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.1/ >> >> -- >> best regards, >> Anthony >> >>>> >>>> 21.08.2012 18:35, Anthony Petrov wrote: >>>>> Hi Artem and Sergey, >>>>> >>>>> Please review a fix for >>>>> http://bugs.sun.com/view_bug.do?bug_id=7160609 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.0/ >>>>> >>>>> Since OpenGL fails to create a square texture of size >>>>> GL_MAX_TEXTURE_SIZE, we use the total screen bounds to limit >>>>> possible window sizes on the Mac. Note that this behavior is >>>>> consistent with the constraints imposed by the native OS on MS >>>>> Windows, so this mustn't look like a Mac-only JDK limitation. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>> >>>> >>> >>> > > From Sergey.Bylokhov at oracle.com Thu Aug 23 02:56:33 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 23 Aug 2012 13:56:33 +0400 Subject: [8] Review request for 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) In-Reply-To: <50320996.3010500@oracle.com> References: <5020FE7B.6020402@oracle.com> <001201cd752d$e9476200$bbd62600$@oracle.com> <50291CC3.8010002@oracle.com> <50320996.3010500@oracle.com> Message-ID: <5035FE51.5050103@oracle.com> There are no volunteers? 20.08.2012 13:55, Sergey Bylokhov wrote: > Does anybody has a chance to review it? > Thanks. > > 13.08.2012 19:26, Sergey Bylokhov wrote: >> Thanks Leonid. >> >> Does anybody has a chance to review it? >> >> 08.08.2012 10:20, Leonid Romanov wrote: >>> Looks reasonable. >>> >>> -----Original Message----- >>> From: Sergey Bylokhov [mailto:Sergey.Bylokhov at oracle.com] >>> Sent: Tuesday, August 07, 2012 3:40 PM >>> To: Leonid Romanov; Mike Swingler; awt-dev at openjdk.java.net; >>> macosx-port-dev at openjdk.java.net >>> Subject: [8] Review request for 7186371: [macosx] Main menu >>> shortcuts not displayed (7u6 regression) >>> >>> Hi Everyone, >>> Please review the fix. >>> When we translate calls from our swing menu components to awt peer we >>> resets information about shortcut in the setLabel(). >>> This happens because of ScreenMenuItem.setAccelerator() method call >>> peers setLabel(..,..,..) directly and does not initialize >>> ScreenMenuItem.shortcut property. >>> But default implementation of ScreenMenuItem.setLabel() assumes that >>> this field(shortcut) will be initialized. >>> >>> This works on jdk6 because it does not reset shortcut if null or empty >>> shortcut is provided. >>> As a solution we can use peers methods directly in both cases. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186371 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7186371/webrev.00 >>> >> >> > > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Aug 23 04:40:42 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 23 Aug 2012 15:40:42 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <50251406.6060708@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> Message-ID: <503616BA.6050007@oracle.com> Could someone review the fix? Thanks, Alexandr. On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ > > The comments are below: > > On 8/7/2012 6:47 PM, Mike Swingler wrote: >> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >> simple 32 bit int is probably not what you intended to do. > fixed. >> Also, have you considered simply calling -[NSWindow >> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then >> removing the calls that flip it on and off in -[AWTView >> mouseEntered:] and -[AWTView mouseExited"]? This would also require a >> change in >> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >> which has a comment that states it only turns on mouse moved events >> if the window is currently under the mouse. > I tried it. The result that I got is that a dragging mouse from > one window to another does not generate mouse enter/exit events on the > second window in case when tracking rect is used and the > acceptsMouseMovedEvents flag is always set to YES. > >> I would think that AppKit should be more than happy to send you >> mouse-over/enter/exited events as long as you say you want them. Was >> this approach tried and didn't work for some reason? >>> Hi, Alexander. >>> Probably all this stuff can be simplified? Can you try to change >>> TrackingRect to TrackingArea with appropriate flags like >>> NSTrackingEnabledDuringMouseDrag etc. > I changed the TrackingRect to TrackingArea in the updated fix. It > now generates the mouse enter/exit events on the second window during > drag. > So it is not necessary to generates such events from our side. > > The getTopmostWindowUnderMouse is necessary to handle mouse > enter/exit events for component in case when a mouse is dragged from > one window to another. > Where the second window contains it's own components and the only > way to know about tracking over them are drag events which receives > the first window. > > I think that the LWWindowPeer class code can be simplified if we > assume that window mouse enter/exit events are always come to the > current window. > So the component mouse enter/exit events can be tracked only in the > current or topmost window. > For this case I separated the global lastCommonMouseEventPeer which > is necessary for the cursor manager and the local lastMouseEventPeer. > > According to the specification: The proper order of mouse-entered > and mouse-exited events received by tracking-area objects in an > application cannot be guaranteed. > > https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html > So it seems it is not possible to have one lastMouseEventPeer > instead of two: lastCommonMouseEventPeer and lastMouseEventPeer. > > And there are possible situations that we can receive mouse drag > event between enter and exit. > To handle this the isMouseOver flag is added to the LWWindowPeer > class. So the component mouse enter/exit events are not generated if > the window mouse exited event is received and window mouse entered is > not. > > There is the test: > test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java > It shows that even using the TrackingArea some mouse enter/exit > events are not generateed in the following cases: > - window is created under the mouse > - window changes it's bounds so it becomes under the mouse > > For this cases it still necessary to generate mouse enter/exit > events from our side. > I just moved the related code to one method > synthesizeMouseEnteredExitedEventsForAllWindows. > > Thanks, > Alexandr. > >>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>> >>>> This is a regression after the fix 7154048 [macosx] At least drag >>>> twice, the toolbar can be dragged to the left side. >>>> >>>> In the case where a toolbar is created under a mouse and it is >>>> dragged over the initial window the mouse enter/exit events should >>>> not be generated for the components which are under the toolbar. >>>> >>>> The current fix is supposed to solve this regression and also to >>>> fix generation of mouse enter/exit events for all cases where a >>>> mouse is dragged from one window to another or a new window is >>>> created under a mouse (like it is implemented for toolbar). >>>> >>>> Let's see the following cases >>>> 1) Mouse is dragged from a window and back to the same window. >>>> The Mac OS X system generates a mouse exit event only the first >>>> time when a mouse is dragged from a window and does not generate >>>> mouse enter/exit events next times during one drag trace. >>>> >>>> 2) Mouse is dragged from one window to another. >>>> The Mac OS X system does not generate mouse enter/exit events for >>>> the second window. >>>> >>>> 3) Mouse is dragged from one window to another and released. >>>> In this case the Mac OS X system generates mouse enter event for >>>> the second window only after releasing the mouse. >>>> >>>> 4) Clicking on window creates a new window after that the new >>>> window is dragged (toolbar dragging). >>>> >>>> However the Java system generates mouse enter/exit events each time >>>> when a mouse is dragged over any window. >>>> >>>> To fix this the following methods are introduced: >>>> - Get topmost window under mouse >>>> - Synthesize mouse enter/exit events for all windows >>>> >>>> >>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>> handled previous and next components and is able to generate mouse >>>> enter/exit events for them. >>>> However the the AWTView native class contains isMouseOver flag >>>> which value becomes inconsistent if we do not updated it. Because >>>> of this the fix generates the mouse enter/exit window events on the >>>> native side. >>>> >>>> Generating mouse enter/exit events always should be in order where >>>> mouse exit events are generated before the mouse enter events. >>>> >>>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to >>>> generate mouse enter/exit events for all windows during mouse drag >>>> or window creation/window bounds changing. >>>> However only those windows which isMouseOver flag is differ from >>>> the isTopMostWindowUnderMouse state are affected. >>>> This method also tries to generate both mouse enter and exit event >>>> for the same window but only one of them can be applicable because >>>> the isTopMostWindowUnderMouse state is not changed for these calls. >>>> >>>> So the window enter/exit events now are always generated from the >>>> native system and component enter/exit events are generated in the >>>> LWWindowPeer class. >>>> >>>> LWWindowPeer class now uses three links to components: current, >>>> last and topmostUnderMouse. All of them are necessary because in >>>> case when a mouse is dragged from one window to another the current >>>> component receives drag events and last and topmostUnderMouse links >>>> handle components mouse exit/enter events on the second window. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>> >>> -- >>> Best regards, Sergey. >>> > From anthony.petrov at oracle.com Thu Aug 23 05:51:00 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 23 Aug 2012 16:51:00 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503616BA.6050007@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> Message-ID: <50362734.5060600@oracle.com> Hi Alexandr, 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate through app's windows only once and send both Exited and Entered events where needed? 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no longer requires a window pointer as an argument. 3. Here's a major concern: the LWWindowPeer (and other LW* classes) should never import C* classes. Instead you should've added a new method to the PlatformWindow interface, and used it from LWWindowPeer. The CPlatformWindow should've implemented this method, and called an appropriate native method from there. In this case, however, you actually need a static method, so it'd better be part of the LWToolkit interface, and implemented in the LWCToolkit class instead. -- best regards, Anthony On 08/23/12 15:40, Alexander Scherbatiy wrote: > > Could someone review the fix? > > Thanks, > Alexandr. > > On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >> >> The comments are below: >> >> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>> simple 32 bit int is probably not what you intended to do. >> fixed. >>> Also, have you considered simply calling -[NSWindow >>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then >>> removing the calls that flip it on and off in -[AWTView >>> mouseEntered:] and -[AWTView mouseExited"]? This would also require a >>> change in >>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>> which has a comment that states it only turns on mouse moved events >>> if the window is currently under the mouse. >> I tried it. The result that I got is that a dragging mouse from one >> window to another does not generate mouse enter/exit events on the >> second window in case when tracking rect is used and the >> acceptsMouseMovedEvents flag is always set to YES. >> >>> I would think that AppKit should be more than happy to send you >>> mouse-over/enter/exited events as long as you say you want them. Was >>> this approach tried and didn't work for some reason? >>>> Hi, Alexander. >>>> Probably all this stuff can be simplified? Can you try to change >>>> TrackingRect to TrackingArea with appropriate flags like >>>> NSTrackingEnabledDuringMouseDrag etc. >> I changed the TrackingRect to TrackingArea in the updated fix. It now >> generates the mouse enter/exit events on the second window during drag. >> So it is not necessary to generates such events from our side. >> >> The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit >> events for component in case when a mouse is dragged from one window >> to another. >> Where the second window contains it's own components and the only way >> to know about tracking over them are drag events which receives the >> first window. >> >> I think that the LWWindowPeer class code can be simplified if we >> assume that window mouse enter/exit events are always come to the >> current window. >> So the component mouse enter/exit events can be tracked only in the >> current or topmost window. >> For this case I separated the global lastCommonMouseEventPeer which is >> necessary for the cursor manager and the local lastMouseEventPeer. >> >> According to the specification: The proper order of mouse-entered and >> mouse-exited events received by tracking-area objects in an >> application cannot be guaranteed. >> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >> >> So it seems it is not possible to have one lastMouseEventPeer instead >> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >> >> And there are possible situations that we can receive mouse drag event >> between enter and exit. >> To handle this the isMouseOver flag is added to the LWWindowPeer >> class. So the component mouse enter/exit events are not generated if >> the window mouse exited event is received and window mouse entered is >> not. >> >> There is the test: >> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >> It shows that even using the TrackingArea some mouse enter/exit events >> are not generateed in the following cases: >> - window is created under the mouse >> - window changes it's bounds so it becomes under the mouse >> >> For this cases it still necessary to generate mouse enter/exit events >> from our side. >> I just moved the related code to one method >> synthesizeMouseEnteredExitedEventsForAllWindows. >> >> Thanks, >> Alexandr. >> >>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>> >>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>> twice, the toolbar can be dragged to the left side. >>>>> >>>>> In the case where a toolbar is created under a mouse and it is >>>>> dragged over the initial window the mouse enter/exit events should >>>>> not be generated for the components which are under the toolbar. >>>>> >>>>> The current fix is supposed to solve this regression and also to >>>>> fix generation of mouse enter/exit events for all cases where a >>>>> mouse is dragged from one window to another or a new window is >>>>> created under a mouse (like it is implemented for toolbar). >>>>> >>>>> Let's see the following cases >>>>> 1) Mouse is dragged from a window and back to the same window. >>>>> The Mac OS X system generates a mouse exit event only the first >>>>> time when a mouse is dragged from a window and does not generate >>>>> mouse enter/exit events next times during one drag trace. >>>>> >>>>> 2) Mouse is dragged from one window to another. >>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>> the second window. >>>>> >>>>> 3) Mouse is dragged from one window to another and released. >>>>> In this case the Mac OS X system generates mouse enter event for >>>>> the second window only after releasing the mouse. >>>>> >>>>> 4) Clicking on window creates a new window after that the new >>>>> window is dragged (toolbar dragging). >>>>> >>>>> However the Java system generates mouse enter/exit events each time >>>>> when a mouse is dragged over any window. >>>>> >>>>> To fix this the following methods are introduced: >>>>> - Get topmost window under mouse >>>>> - Synthesize mouse enter/exit events for all windows >>>>> >>>>> >>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>> handled previous and next components and is able to generate mouse >>>>> enter/exit events for them. >>>>> However the the AWTView native class contains isMouseOver flag >>>>> which value becomes inconsistent if we do not updated it. Because >>>>> of this the fix generates the mouse enter/exit window events on the >>>>> native side. >>>>> >>>>> Generating mouse enter/exit events always should be in order where >>>>> mouse exit events are generated before the mouse enter events. >>>>> >>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to >>>>> generate mouse enter/exit events for all windows during mouse drag >>>>> or window creation/window bounds changing. >>>>> However only those windows which isMouseOver flag is differ from >>>>> the isTopMostWindowUnderMouse state are affected. >>>>> This method also tries to generate both mouse enter and exit event >>>>> for the same window but only one of them can be applicable because >>>>> the isTopMostWindowUnderMouse state is not changed for these calls. >>>>> >>>>> So the window enter/exit events now are always generated from the >>>>> native system and component enter/exit events are generated in the >>>>> LWWindowPeer class. >>>>> >>>>> LWWindowPeer class now uses three links to components: current, >>>>> last and topmostUnderMouse. All of them are necessary because in >>>>> case when a mouse is dragged from one window to another the current >>>>> component receives drag events and last and topmostUnderMouse links >>>>> handle components mouse exit/enter events on the second window. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>> >>>> -- >>>> Best regards, Sergey. >>>> >> > From anthony.petrov at oracle.com Thu Aug 23 06:30:23 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 23 Aug 2012 17:30:23 +0400 Subject: [8] Review request for 7193169 : The code example in javadoc of Component class is missing 'implements' keywords In-Reply-To: References: Message-ID: <5036306F.201@oracle.com> Hi Sean, Thank you for the fix, it looks fine. Please hold on with the push, however, since there's some additional process for making changes to javadocs. I'll notify you when it's OK to push this fix. -- best regards, Anthony On 08/22/12 13:28, Sean Chou wrote: > Hello, > > One of the code example in javadoc of Component class misses > 'implements' keyword, this is to add the word. > > Bug is at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193169 > Webrev is at: http://cr.openjdk.java.net/~zhouyx/7193169/webrev.00/ > > Please take a look, thanks. > > On Tue, Aug 21, 2012 at 6:39 PM, Anthony Petrov > > wrote: > > Sure! Thanks. > > -- > best regards, > Anthony > > > On 8/21/2012 1:43 PM, Sean Chou wrote: > > Hello, > > I was reading the javadoc comments in Component.java and > found this piece of code example: > " > class MyApp java.io.Serializable > { > BigObjectThatShouldNotBeSerial__izedWithAButton bigOne; > " > > It seems the "implements" keyword is missing. Shall I > report a bug for that ? > > > -- > Best Regards, > Sean Chou > > > > > -- > Best Regards, > Sean Chou > From anthony.petrov at oracle.com Thu Aug 23 06:39:51 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 23 Aug 2012 17:39:51 +0400 Subject: [8] Review request for 7193169 : The code example in javadoc of Component class is missing 'implements' keywords In-Reply-To: <5036306F.201@oracle.com> References: <5036306F.201@oracle.com> Message-ID: <503632A7.1010800@oracle.com> Sean, I've just checked and it appears that fixing typos is OK w/o any additional processes, and this is obviously a typo that you're fixing. So please feel free to push your fix to the JDK 8 AWT repository. Thanks again! -- best regards, Anthony On 08/23/12 17:30, Anthony Petrov wrote: > Hi Sean, > > Thank you for the fix, it looks fine. Please hold on with the push, > however, since there's some additional process for making changes to > javadocs. I'll notify you when it's OK to push this fix. > > -- > best regards, > Anthony > > On 08/22/12 13:28, Sean Chou wrote: >> Hello, >> >> One of the code example in javadoc of Component class misses >> 'implements' keyword, this is to add the word. >> >> Bug is at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193169 >> Webrev is at: http://cr.openjdk.java.net/~zhouyx/7193169/webrev.00/ >> >> Please take a look, thanks. >> >> On Tue, Aug 21, 2012 at 6:39 PM, Anthony Petrov >> > wrote: >> >> Sure! Thanks. >> >> -- >> best regards, >> Anthony >> >> >> On 8/21/2012 1:43 PM, Sean Chou wrote: >> >> Hello, >> >> I was reading the javadoc comments in Component.java and >> found this piece of code example: >> " >> class MyApp java.io.Serializable >> { >> BigObjectThatShouldNotBeSerial__izedWithAButton bigOne; >> " >> >> It seems the "implements" keyword is missing. Shall I >> report a bug for that ? >> >> >> -- >> Best Regards, >> Sean Chou >> >> >> >> >> -- >> Best Regards, >> Sean Chou >> From artem.ananiev at oracle.com Thu Aug 23 07:05:42 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 23 Aug 2012 18:05:42 +0400 Subject: [8] Review request for 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941) In-Reply-To: <5034C97B.5000908@oracle.com> References: <50339CAB.30004@oracle.com> <5033B0E7.9020403@oracle.com> <5033B16F.1070309@oracle.com> <5034C97B.5000908@oracle.com> Message-ID: <503638B6.2020004@oracle.com> Hi, Anthony, I've got one minor comment about the second version of the fix. The code in LWWindowPeer and CPlatformWindow looks pretty strange now: we always pass (1, 1) as (minWidth, minHeight) and then query target component for real minimum size. I would suggest to call target.isMinSizeSet() and target.getMinSize() in LWWindowPeer, and make CPlatformWindow.setSizeConstraints() as straightforward as possible. Thanks, Artem On 8/22/2012 3:58 PM, Anthony Petrov wrote: > Hi Sergey, > > Thanks for the review. Please find my comments and a new version of the > fix inline. > > On 8/21/2012 8:03 PM, Sergey Bylokhov wrote: >> Looks like this code is not necessary in jdk8 any more: >> >> 673 // Re-apply the size constraints and the size to ensure the space >> 674 // occupied by the grow box is counted properly >> 675 peer.updateMinimumSize(); > > There are two reasons I don't want to remove this code now: > 1. This same fix needs to be back-ported to 7u8 where this code is > required. > 2. After changing the resizable style, native OS may or may not reset or > somehow affect the maximum/minimum sizes of a window, and/or its real > current size. This had best be investigated under a separate CR for JDK 8. > > >> 21.08.2012 20:01, Sergey Bylokhov ?????: >>> Hi,Anthony. >>> I guess that getMinimumSize() in the setSizeConstraints should be >>> wrapped with isMinimumSizeSet like it was in LWWindowsPeer, same for >>> getMaximumSize() > > This makes sense even though the old code didn't do that in > CPW.setMinimumSize(). Here's an updated webrev: > > http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.1/ > > -- > best regards, > Anthony > >>> >>> 21.08.2012 18:35, Anthony Petrov wrote: >>>> Hi Artem and Sergey, >>>> >>>> Please review a fix for >>>> http://bugs.sun.com/view_bug.do?bug_id=7160609 at: >>>> >>>> http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.0/ >>>> >>>> Since OpenGL fails to create a square texture of size >>>> GL_MAX_TEXTURE_SIZE, we use the total screen bounds to limit >>>> possible window sizes on the Mac. Note that this behavior is >>>> consistent with the constraints imposed by the native OS on MS >>>> Windows, so this mustn't look like a Mac-only JDK limitation. >>>> >>>> -- >>>> best regards, >>>> Anthony >>> >>> >> >> From anthony.petrov at oracle.com Thu Aug 23 07:32:15 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 23 Aug 2012 18:32:15 +0400 Subject: [8] Review request for 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941) In-Reply-To: <503638B6.2020004@oracle.com> References: <50339CAB.30004@oracle.com> <5033B0E7.9020403@oracle.com> <5033B16F.1070309@oracle.com> <5034C97B.5000908@oracle.com> <503638B6.2020004@oracle.com> Message-ID: <50363EEF.3070805@oracle.com> Hi Artem, Thanks for the review. Your suggestion makes sense. Here's a new webrev: http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.2/ -- best regards, Anthony On 08/23/12 18:05, Artem Ananiev wrote: > Hi, Anthony, > > I've got one minor comment about the second version of the fix. The code > in LWWindowPeer and CPlatformWindow looks pretty strange now: we always > pass (1, 1) as (minWidth, minHeight) and then query target component for > real minimum size. I would suggest to call target.isMinSizeSet() and > target.getMinSize() in LWWindowPeer, and make > CPlatformWindow.setSizeConstraints() as straightforward as possible. > > Thanks, > > Artem > > On 8/22/2012 3:58 PM, Anthony Petrov wrote: >> Hi Sergey, >> >> Thanks for the review. Please find my comments and a new version of the >> fix inline. >> >> On 8/21/2012 8:03 PM, Sergey Bylokhov wrote: >>> Looks like this code is not necessary in jdk8 any more: >>> >>> 673 // Re-apply the size constraints and the size to ensure the space >>> 674 // occupied by the grow box is counted properly >>> 675 peer.updateMinimumSize(); >> >> There are two reasons I don't want to remove this code now: >> 1. This same fix needs to be back-ported to 7u8 where this code is >> required. >> 2. After changing the resizable style, native OS may or may not reset or >> somehow affect the maximum/minimum sizes of a window, and/or its real >> current size. This had best be investigated under a separate CR for >> JDK 8. >> >> >>> 21.08.2012 20:01, Sergey Bylokhov ?????: >>>> Hi,Anthony. >>>> I guess that getMinimumSize() in the setSizeConstraints should be >>>> wrapped with isMinimumSizeSet like it was in LWWindowsPeer, same for >>>> getMaximumSize() >> >> This makes sense even though the old code didn't do that in >> CPW.setMinimumSize(). Here's an updated webrev: >> >> http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.1/ >> >> -- >> best regards, >> Anthony >> >>>> >>>> 21.08.2012 18:35, Anthony Petrov wrote: >>>>> Hi Artem and Sergey, >>>>> >>>>> Please review a fix for >>>>> http://bugs.sun.com/view_bug.do?bug_id=7160609 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.0/ >>>>> >>>>> Since OpenGL fails to create a square texture of size >>>>> GL_MAX_TEXTURE_SIZE, we use the total screen bounds to limit >>>>> possible window sizes on the Mac. Note that this behavior is >>>>> consistent with the constraints imposed by the native OS on MS >>>>> Windows, so this mustn't look like a Mac-only JDK limitation. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>> >>>> >>> >>> From artem.ananiev at oracle.com Thu Aug 23 11:56:32 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 23 Aug 2012 22:56:32 +0400 Subject: [8] Review request for 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941) In-Reply-To: <50363EEF.3070805@oracle.com> References: <50339CAB.30004@oracle.com> <5033B0E7.9020403@oracle.com> <5033B16F.1070309@oracle.com> <5034C97B.5000908@oracle.com> <503638B6.2020004@oracle.com> <50363EEF.3070805@oracle.com> Message-ID: <50367CE0.8020803@oracle.com> Hi, Anthony, it looks much clearer now. Thanks! Approved. Artem On 8/23/2012 6:32 PM, Anthony Petrov wrote: > Hi Artem, > > Thanks for the review. Your suggestion makes sense. Here's a new webrev: > > http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.2/ > > -- > best regards, > Anthony > > On 08/23/12 18:05, Artem Ananiev wrote: >> Hi, Anthony, >> >> I've got one minor comment about the second version of the fix. The code >> in LWWindowPeer and CPlatformWindow looks pretty strange now: we always >> pass (1, 1) as (minWidth, minHeight) and then query target component for >> real minimum size. I would suggest to call target.isMinSizeSet() and >> target.getMinSize() in LWWindowPeer, and make >> CPlatformWindow.setSizeConstraints() as straightforward as possible. >> >> Thanks, >> >> Artem >> >> On 8/22/2012 3:58 PM, Anthony Petrov wrote: >>> Hi Sergey, >>> >>> Thanks for the review. Please find my comments and a new version of the >>> fix inline. >>> >>> On 8/21/2012 8:03 PM, Sergey Bylokhov wrote: >>>> Looks like this code is not necessary in jdk8 any more: >>>> >>>> 673 // Re-apply the size constraints and the size to ensure the space >>>> 674 // occupied by the grow box is counted properly >>>> 675 peer.updateMinimumSize(); >>> >>> There are two reasons I don't want to remove this code now: >>> 1. This same fix needs to be back-ported to 7u8 where this code is >>> required. >>> 2. After changing the resizable style, native OS may or may not reset or >>> somehow affect the maximum/minimum sizes of a window, and/or its real >>> current size. This had best be investigated under a separate CR for >>> JDK 8. >>> >>> >>>> 21.08.2012 20:01, Sergey Bylokhov ?????: >>>>> Hi,Anthony. >>>>> I guess that getMinimumSize() in the setSizeConstraints should be >>>>> wrapped with isMinimumSizeSet like it was in LWWindowsPeer, same for >>>>> getMaximumSize() >>> >>> This makes sense even though the old code didn't do that in >>> CPW.setMinimumSize(). Here's an updated webrev: >>> >>> http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.1/ >>> >>> -- >>> best regards, >>> Anthony >>> >>>>> >>>>> 21.08.2012 18:35, Anthony Petrov wrote: >>>>>> Hi Artem and Sergey, >>>>>> >>>>>> Please review a fix for >>>>>> http://bugs.sun.com/view_bug.do?bug_id=7160609 at: >>>>>> >>>>>> http://cr.openjdk.java.net/~anthony/8-40-hugeWindowCrash-7160609.0/ >>>>>> >>>>>> Since OpenGL fails to create a square texture of size >>>>>> GL_MAX_TEXTURE_SIZE, we use the total screen bounds to limit >>>>>> possible window sizes on the Mac. Note that this behavior is >>>>>> consistent with the constraints imposed by the native OS on MS >>>>>> Windows, so this mustn't look like a Mac-only JDK limitation. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>> >>>>> >>>> >>>> From oleg.pekhovskiy at oracle.com Thu Aug 23 16:37:38 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 24 Aug 2012 03:37:38 +0400 Subject: [8] Review request for 7153339: InternalError when drawLine with Xor and Antialiasing In-Reply-To: <50259500.3050203@oracle.com> References: <50257C8F.1010201@oracle.com> <50259500.3050203@oracle.com> Message-ID: <5036BEC2.8090608@oracle.com> Hi Phil, Jim, thank you for pointing out the testing work that should be performed. I tested my fix with the following regression tests: test/java/awt/Graphics test/java/awt/Graphics2D test/java/awt/GraphicsDevice test/java/awt/GraphicsEnvironment test/sun/java2d Plus I tested performance differences on: demo/jfc/Java2D/Java2Demo.jar Testing was done on Windows 7 & Ubuntu 12.04 LTS. No differences were found. I also asked Yuri Nesterenko to test all that stuff on Mac. Thanks, Oleg 11.08.2012 3:10, Phil Race wrote: > Oleg, > This looks OK to me but since this is a shared code change I have > to ask what testing you've done ? > > Also why not provide a regression test ? The provided test was > interactive but I think it can be automated. > > You need another review and I'd like Jim to take a look. > > -phil. > > On 8/10/2012 2:26 PM, Oleg Pekhovskiy wrote: >> Hi, >> >> Please review the fix for CR: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153339 >> >> Webrev: >> http://cr.openjdk.java.net/~bagiras/8/7153339.1/ >> >> Comments: >> XOR is not supported for D3D (see comments inside >> D3DSurfaceData.validatePipe()) and >> software rendering is used invalidating current D3DSurfaceData. >> So we have situation when component's peer has invalid SurfaceData >> and it's retrieved in >> SunGraphics2D.revalidateAll() through SurfaceData.getReplacement() >> without any check. >> That's why I added validity check there. >> >> Thanks, >> Oleg >> >> > From james.graham at oracle.com Thu Aug 23 17:04:12 2012 From: james.graham at oracle.com (Jim Graham) Date: Thu, 23 Aug 2012 17:04:12 -0700 Subject: [8] Review request for 7153339: InternalError when drawLine with Xor and Antialiasing In-Reply-To: <5036BEC2.8090608@oracle.com> References: <50257C8F.1010201@oracle.com> <50259500.3050203@oracle.com> <5036BEC2.8090608@oracle.com> Message-ID: <5036C4FC.9010101@oracle.com> Hi Oleg, getReplacement should not be returning an invalid surface. If the current D3DSD is invalid, then it should return a valid replacement. The only time it should return null is when the window is gone. It sounds like the window isn't gone here, it has just switched over to a non-D3D type of SurfaceData and return that... ...jim On 8/23/2012 4:37 PM, Oleg Pekhovskiy wrote: > Hi Phil, Jim, > > thank you for pointing out the testing work that should be performed. > I tested my fix with the following regression tests: > test/java/awt/Graphics > test/java/awt/Graphics2D > test/java/awt/GraphicsDevice > test/java/awt/GraphicsEnvironment > test/sun/java2d > > Plus I tested performance differences on: > demo/jfc/Java2D/Java2Demo.jar > > Testing was done on Windows 7 & Ubuntu 12.04 LTS. > No differences were found. > > I also asked Yuri Nesterenko to test all that stuff on Mac. > > Thanks, > Oleg > > > 11.08.2012 3:10, Phil Race wrote: >> Oleg, >> This looks OK to me but since this is a shared code change I have >> to ask what testing you've done ? >> >> Also why not provide a regression test ? The provided test was >> interactive but I think it can be automated. >> >> You need another review and I'd like Jim to take a look. >> >> -phil. >> >> On 8/10/2012 2:26 PM, Oleg Pekhovskiy wrote: >>> Hi, >>> >>> Please review the fix for CR: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153339 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~bagiras/8/7153339.1/ >>> >>> Comments: >>> XOR is not supported for D3D (see comments inside >>> D3DSurfaceData.validatePipe()) and >>> software rendering is used invalidating current D3DSurfaceData. >>> So we have situation when component's peer has invalid SurfaceData >>> and it's retrieved in >>> SunGraphics2D.revalidateAll() through SurfaceData.getReplacement() >>> without any check. >>> That's why I added validity check there. >>> >>> Thanks, >>> Oleg >>> >>> >> > > From luchsh at linux.vnet.ibm.com Thu Aug 23 22:03:38 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Fri, 24 Aug 2012 05:03:38 +0000 Subject: hg: jdk8/awt/jdk: 7193169: The code example in javadoc of Component.java misses 'implements' keyword Message-ID: <20120824050418.B986B476DA@hg.openjdk.java.net> Changeset: d769dbb87c49 Author: zhouyx Date: 2012-08-24 11:35 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d769dbb87c49 7193169: The code example in javadoc of Component.java misses 'implements' keyword Reviewed-by: anthony ! src/share/classes/java/awt/Component.java From luchsh at linux.vnet.ibm.com Thu Aug 23 22:24:34 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Fri, 24 Aug 2012 13:24:34 +0800 Subject: [8] Review request for 7193169 : The code example in javadoc of Component class is missing 'implements' keywords In-Reply-To: References: Message-ID: <50371012.9040104@linux.vnet.ibm.com> Hi Sean, The change has been pushed to http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d769dbb87c49. Pls verify Thanks & regards Jonathan On 08/22/2012 05:28 PM, Sean Chou wrote: > Hello, > > One of the code example in javadoc of Component class misses > 'implements' keyword, this is to add the word. > > Bug is at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193169 > Webrev is at: http://cr.openjdk.java.net/~zhouyx/7193169/webrev.00/ > > > Please take a look, thanks. > > On Tue, Aug 21, 2012 at 6:39 PM, Anthony Petrov > > wrote: > > Sure! Thanks. > > -- > best regards, > Anthony > > > On 8/21/2012 1:43 PM, Sean Chou wrote: > > Hello, > > I was reading the javadoc comments in Component.java and > found this piece of code example: > " > class MyApp java.io.Serializable > { > BigObjectThatShouldNotBeSerializedWithAButton bigOne; > " > > It seems the "implements" keyword is missing. Shall I > report a bug for that ? > > > -- > Best Regards, > Sean Chou > > > > > -- > Best Regards, > Sean Chou > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120824/323821b0/attachment.html From zhouyx at linux.vnet.ibm.com Thu Aug 23 22:27:02 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Fri, 24 Aug 2012 13:27:02 +0800 Subject: [8] Review request for 7193169 : The code example in javadoc of Component class is missing 'implements' keywords In-Reply-To: <50371012.9040104@linux.vnet.ibm.com> References: <50371012.9040104@linux.vnet.ibm.com> Message-ID: Verified, thanks Jonathan and Anthony. On Fri, Aug 24, 2012 at 1:24 PM, Jonathan Lu wrote: > Hi Sean, > > The change has been pushed to > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d769dbb87c49. > Pls verify > > Thanks & regards > Jonathan > > > On 08/22/2012 05:28 PM, Sean Chou wrote: > > Hello, > > One of the code example in javadoc of Component class misses > 'implements' keyword, this is to add the word. > > Bug is at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193169 > Webrev is at: http://cr.openjdk.java.net/~zhouyx/7193169/webrev.00/ > > Please take a look, thanks. > > On Tue, Aug 21, 2012 at 6:39 PM, Anthony Petrov < > anthony.petrov at oracle.com> wrote: > >> Sure! Thanks. >> >> -- >> best regards, >> Anthony >> >> >> On 8/21/2012 1:43 PM, Sean Chou wrote: >> >>> Hello, >>> >>> I was reading the javadoc comments in Component.java and found this >>> piece of code example: >>> " >>> class MyApp java.io.Serializable >>> { >>> BigObjectThatShouldNotBeSerializedWithAButton bigOne; >>> " >>> >>> It seems the "implements" keyword is missing. Shall I report a bug >>> for that ? >>> >>> >>> -- >>> Best Regards, >>> Sean Chou >>> >>> > > > -- > Best Regards, > Sean Chou > > > -- Best Regards, Sean Chou -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120824/e58b6d35/attachment.html From konstantin.shefov at oracle.com Fri Aug 24 02:29:45 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Fri, 24 Aug 2012 13:29:45 +0400 Subject: [8] Review request for 7184326 TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo Message-ID: <50374989.9030402@oracle.com> Hello, Please review a fix for the issue: 7184326 TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo Test should be modified in jdk8 to be run via jtreg The webrev is http://cr.openjdk.java.net/~kshefov/7184326/webrev.00/ Thanks, Konstantin From oleg.pekhovskiy at oracle.com Fri Aug 24 03:01:24 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 24 Aug 2012 14:01:24 +0400 Subject: [8] Review request for 7153339: InternalError when drawLine with Xor and Antialiasing In-Reply-To: <5036C4FC.9010101@oracle.com> References: <50257C8F.1010201@oracle.com> <50259500.3050203@oracle.com> <5036BEC2.8090608@oracle.com> <5036C4FC.9010101@oracle.com> Message-ID: <503750F4.2010208@oracle.com> Hi Jim, first of all I should say, that I prepared that fix for 7u as the most safe, with minimum changes. I agree that getReplacement() should return a valid sufrace or null, but it doesn't happen during that switch. That CR was assigned to me because my previous changes for: 7112642 Incorrect checking for graphics rendering object 7121482 some sun/java2d and sun/awt tests failed with InvalidPipeException discovered the problem with getReplacement() and were somehow related. But maybe it would be better to create a separate CR for getReplacement() issue and assign it to Java2d Team? I also could add a comment for "!surfaceData.isValid()" reffering to CR7153339. What do you think? Thanks, Oleg 24.08.2012 4:04, Jim Graham wrote: > Hi Oleg, > > getReplacement should not be returning an invalid surface. If the > current D3DSD is invalid, then it should return a valid replacement. > The only time it should return null is when the window is gone. It > sounds like the window isn't gone here, it has just switched over to a > non-D3D type of SurfaceData and return that... > > ...jim > > On 8/23/2012 4:37 PM, Oleg Pekhovskiy wrote: >> Hi Phil, Jim, >> >> thank you for pointing out the testing work that should be performed. >> I tested my fix with the following regression tests: >> test/java/awt/Graphics >> test/java/awt/Graphics2D >> test/java/awt/GraphicsDevice >> test/java/awt/GraphicsEnvironment >> test/sun/java2d >> >> Plus I tested performance differences on: >> demo/jfc/Java2D/Java2Demo.jar >> >> Testing was done on Windows 7 & Ubuntu 12.04 LTS. >> No differences were found. >> >> I also asked Yuri Nesterenko to test all that stuff on Mac. >> >> Thanks, >> Oleg >> >> >> 11.08.2012 3:10, Phil Race wrote: >>> Oleg, >>> This looks OK to me but since this is a shared code change I have >>> to ask what testing you've done ? >>> >>> Also why not provide a regression test ? The provided test was >>> interactive but I think it can be automated. >>> >>> You need another review and I'd like Jim to take a look. >>> >>> -phil. >>> >>> On 8/10/2012 2:26 PM, Oleg Pekhovskiy wrote: >>>> Hi, >>>> >>>> Please review the fix for CR: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153339 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~bagiras/8/7153339.1/ >>>> >>>> Comments: >>>> XOR is not supported for D3D (see comments inside >>>> D3DSurfaceData.validatePipe()) and >>>> software rendering is used invalidating current D3DSurfaceData. >>>> So we have situation when component's peer has invalid SurfaceData >>>> and it's retrieved in >>>> SunGraphics2D.revalidateAll() through SurfaceData.getReplacement() >>>> without any check. >>>> That's why I added validity check there. >>>> >>>> Thanks, >>>> Oleg >>>> >>>> >>> >> >> From anthony.petrov at oracle.com Fri Aug 24 03:44:14 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 24 Aug 2012 14:44:14 +0400 Subject: [8] Review request for 7184326 TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo In-Reply-To: <50374989.9030402@oracle.com> References: <50374989.9030402@oracle.com> Message-ID: <50375AFE.7050606@oracle.com> Looks fine. -- best regards, Anthony On 8/24/2012 1:29 PM, Konstantin Shefov wrote: > Hello, > > Please review a fix for the issue: > > 7184326 TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo > > Test should be modified in jdk8 to be run via jtreg > > The webrev is http://cr.openjdk.java.net/~kshefov/7184326/webrev.00/ > > > Thanks, > Konstantin > From anthony.petrov at oracle.com Fri Aug 24 03:58:34 2012 From: anthony.petrov at oracle.com (anthony.petrov at oracle.com) Date: Fri, 24 Aug 2012 10:58:34 +0000 Subject: hg: jdk8/awt/jdk: 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941) Message-ID: <20120824105914.6AA7A476E0@hg.openjdk.java.net> Changeset: e3122759abe3 Author: anthony Date: 2012-08-24 14:58 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e3122759abe3 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941) Summary: Constrain window dimensions with screen bounds and GL_MAX_TEXTURE_SIZE Reviewed-by: art, serb ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m + src/share/classes/sun/awt/TextureSizeConstraining.java + test/java/awt/Frame/HugeFrame/HugeFrame.java From alexandr.scherbatiy at oracle.com Fri Aug 24 06:53:39 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 24 Aug 2012 17:53:39 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <50362734.5060600@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> Message-ID: <50378763.60508@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ The comments are below: On 8/23/2012 4:51 PM, Anthony Petrov wrote: > Hi Alexandr, > > 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate > through app's windows only once and send both Exited and Entered > events where needed? Now, when we do not care about the order of the mouse enter/exit events generation it is possible to do. I have updated the code. > > 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no > longer requires a window pointer as an argument. Fixed. > > 3. Here's a major concern: the LWWindowPeer (and other LW* classes) > should never import C* classes. Instead you should've added a new > method to the PlatformWindow interface, and used it from LWWindowPeer. > The CPlatformWindow should've implemented this method, and called an > appropriate native method from there. In this case, however, you > actually need a static method, so it'd better be part of the LWToolkit > interface, and implemented in the LWCToolkit class instead. I see. It seems that the getTopmostWindowUnderMouse method implementation is different for the CPlatformWindow and for the CPlatformEmbeddedFrame. So I added the getTopmostPlatformWindowUnderMouse method to the PlatformWindow interface. Thanks, Alexandr. > > -- > best regards, > Anthony > > On 08/23/12 15:40, Alexander Scherbatiy wrote: >> >> Could someone review the fix? >> >> Thanks, >> Alexandr. >> >> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>> >>> The comments are below: >>> >>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>> simple 32 bit int is probably not what you intended to do. >>> fixed. >>>> Also, have you considered simply calling -[NSWindow >>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then >>>> removing the calls that flip it on and off in -[AWTView >>>> mouseEntered:] and -[AWTView mouseExited"]? This would also require a >>>> change in >>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>> which has a comment that states it only turns on mouse moved events >>>> if the window is currently under the mouse. >>> I tried it. The result that I got is that a dragging mouse from one >>> window to another does not generate mouse enter/exit events on the >>> second window in case when tracking rect is used and the >>> acceptsMouseMovedEvents flag is always set to YES. >>> >>>> I would think that AppKit should be more than happy to send you >>>> mouse-over/enter/exited events as long as you say you want them. Was >>>> this approach tried and didn't work for some reason? >>>>> Hi, Alexander. >>>>> Probably all this stuff can be simplified? Can you try to change >>>>> TrackingRect to TrackingArea with appropriate flags like >>>>> NSTrackingEnabledDuringMouseDrag etc. >>> I changed the TrackingRect to TrackingArea in the updated fix. It now >>> generates the mouse enter/exit events on the second window during drag. >>> So it is not necessary to generates such events from our side. >>> >>> The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit >>> events for component in case when a mouse is dragged from one window >>> to another. >>> Where the second window contains it's own components and the only way >>> to know about tracking over them are drag events which receives the >>> first window. >>> >>> I think that the LWWindowPeer class code can be simplified if we >>> assume that window mouse enter/exit events are always come to the >>> current window. >>> So the component mouse enter/exit events can be tracked only in the >>> current or topmost window. >>> For this case I separated the global lastCommonMouseEventPeer which is >>> necessary for the cursor manager and the local lastMouseEventPeer. >>> >>> According to the specification: The proper order of mouse-entered and >>> mouse-exited events received by tracking-area objects in an >>> application cannot be guaranteed. >>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>> >>> >>> So it seems it is not possible to have one lastMouseEventPeer instead >>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>> >>> And there are possible situations that we can receive mouse drag event >>> between enter and exit. >>> To handle this the isMouseOver flag is added to the LWWindowPeer >>> class. So the component mouse enter/exit events are not generated if >>> the window mouse exited event is received and window mouse entered is >>> not. >>> >>> There is the test: >>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>> It shows that even using the TrackingArea some mouse enter/exit events >>> are not generateed in the following cases: >>> - window is created under the mouse >>> - window changes it's bounds so it becomes under the mouse >>> >>> For this cases it still necessary to generate mouse enter/exit events >>> from our side. >>> I just moved the related code to one method >>> synthesizeMouseEnteredExitedEventsForAllWindows. >>> >>> Thanks, >>> Alexandr. >>> >>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>> >>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>> twice, the toolbar can be dragged to the left side. >>>>>> >>>>>> In the case where a toolbar is created under a mouse and it is >>>>>> dragged over the initial window the mouse enter/exit events should >>>>>> not be generated for the components which are under the toolbar. >>>>>> >>>>>> The current fix is supposed to solve this regression and also to >>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>> mouse is dragged from one window to another or a new window is >>>>>> created under a mouse (like it is implemented for toolbar). >>>>>> >>>>>> Let's see the following cases >>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>> time when a mouse is dragged from a window and does not generate >>>>>> mouse enter/exit events next times during one drag trace. >>>>>> >>>>>> 2) Mouse is dragged from one window to another. >>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>> the second window. >>>>>> >>>>>> 3) Mouse is dragged from one window to another and released. >>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>> the second window only after releasing the mouse. >>>>>> >>>>>> 4) Clicking on window creates a new window after that the new >>>>>> window is dragged (toolbar dragging). >>>>>> >>>>>> However the Java system generates mouse enter/exit events each time >>>>>> when a mouse is dragged over any window. >>>>>> >>>>>> To fix this the following methods are introduced: >>>>>> - Get topmost window under mouse >>>>>> - Synthesize mouse enter/exit events for all windows >>>>>> >>>>>> >>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>> handled previous and next components and is able to generate mouse >>>>>> enter/exit events for them. >>>>>> However the the AWTView native class contains isMouseOver flag >>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>> of this the fix generates the mouse enter/exit window events on the >>>>>> native side. >>>>>> >>>>>> Generating mouse enter/exit events always should be in order where >>>>>> mouse exit events are generated before the mouse enter events. >>>>>> >>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to >>>>>> generate mouse enter/exit events for all windows during mouse drag >>>>>> or window creation/window bounds changing. >>>>>> However only those windows which isMouseOver flag is differ from >>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>> This method also tries to generate both mouse enter and exit event >>>>>> for the same window but only one of them can be applicable because >>>>>> the isTopMostWindowUnderMouse state is not changed for these calls. >>>>>> >>>>>> So the window enter/exit events now are always generated from the >>>>>> native system and component enter/exit events are generated in the >>>>>> LWWindowPeer class. >>>>>> >>>>>> LWWindowPeer class now uses three links to components: current, >>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>> case when a mouse is dragged from one window to another the current >>>>>> component receives drag events and last and topmostUnderMouse links >>>>>> handle components mouse exit/enter events on the second window. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>> >> From oleg.pekhovskiy at oracle.com Fri Aug 24 07:18:46 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 24 Aug 2012 18:18:46 +0400 Subject: [8] Review request for 7153339: InternalError when drawLine with Xor and Antialiasing In-Reply-To: <5036BEC2.8090608@oracle.com> References: <50257C8F.1010201@oracle.com> <50259500.3050203@oracle.com> <5036BEC2.8090608@oracle.com> Message-ID: <50378D46.7070809@oracle.com> Hi Phil, I forgot to mention the test creation problem. The manual test proposed in CR's description just relies on specific call sequence after getReplacement() returns invalid surfaceData. So the test doesn't catch InvalidPipeException when invalid surfaceData found, because this exception is cought in sun.java2d.SunGraphics2D.drawLine(). But it just catches java.lang.InternalError that is thrown on catch of Throwable exception (indeed InvalidPipeException) that is thrown from: sun.java2d.SunGraphics2D.validatePipe(SunGraphics2D.java:380) with the stack: sun.java2d.SunGraphics2D.revalidateAll(SunGraphics2D.java:2363) sun.java2d.SunGraphics2D.getCompClip(SunGraphics2D.java:496) sun.java2d.pipe.LoopPipe.getStrokeSpans(LoopPipe.java:270) sun.java2d.pipe.LoopPipe.draw(LoopPipe.java:201) sun.java2d.pipe.PixelToShapeConverter.drawLine(PixelToShapeConverter.java:52) sun.java2d.pipe.ValidatePipe.drawLine(ValidatePipe.java:62) sun.java2d.SunGraphics2D.drawLine(SunGraphics2D.java:2137) Could we rely on such indirect error in our case? As I remember you had plans to refactor Graphics related stuff, so the sequence could change making test's expectations odd. Thanks, Oleg 24.08.2012 3:37, Oleg Pekhovskiy wrote: > Hi Phil, Jim, > > thank you for pointing out the testing work that should be performed. > I tested my fix with the following regression tests: > test/java/awt/Graphics > test/java/awt/Graphics2D > test/java/awt/GraphicsDevice > test/java/awt/GraphicsEnvironment > test/sun/java2d > > Plus I tested performance differences on: > demo/jfc/Java2D/Java2Demo.jar > > Testing was done on Windows 7 & Ubuntu 12.04 LTS. > No differences were found. > > I also asked Yuri Nesterenko to test all that stuff on Mac. > > Thanks, > Oleg > > > 11.08.2012 3:10, Phil Race wrote: >> Oleg, >> This looks OK to me but since this is a shared code change I have >> to ask what testing you've done ? >> >> Also why not provide a regression test ? The provided test was >> interactive but I think it can be automated. >> >> You need another review and I'd like Jim to take a look. >> >> -phil. >> >> On 8/10/2012 2:26 PM, Oleg Pekhovskiy wrote: >>> Hi, >>> >>> Please review the fix for CR: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153339 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~bagiras/8/7153339.1/ >>> >>> Comments: >>> XOR is not supported for D3D (see comments inside >>> D3DSurfaceData.validatePipe()) and >>> software rendering is used invalidating current D3DSurfaceData. >>> So we have situation when component's peer has invalid SurfaceData >>> and it's retrieved in >>> SunGraphics2D.revalidateAll() through SurfaceData.getReplacement() >>> without any check. >>> That's why I added validity check there. >>> >>> Thanks, >>> Oleg >>> >>> >> > > From anthony.petrov at oracle.com Fri Aug 24 08:00:22 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 24 Aug 2012 19:00:22 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <50378763.60508@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> Message-ID: <50379706.1000106@oracle.com> Hi Alexandr, src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java > 66 public static native CPlatformWindow nativeGetTopmostPlatformWindowUnderMouse(); This method must probably be private. Still, I don't see why getTopmostPlatformWindowUnderMouse() must return null when it's invoked on an embedded frame, and why the implementation should even be different at all. The mouse is a global system entity. There's either some window under the mouse, or there's not. I would still think of LWToolkit.getPlatformWindowUnderMouse(), and its implementation in LWCToolkit. Also, the logic in LWWindowPeer lines 722-743 seems to be overly complicated (as well as the whole dispatchMouseEvent() method). E.g., if the LWWindowPeer manages an embedded frame, we get topmostWindowPeer == this at line 730, and thus always go through the 'true' branch of if() at line 733, even though actually the mouse pointer can be located over some other window at the moment (e.g. over a popup window opened by an applet). Overall, it's really difficult to understand what is going on there. I've spent half an hour reading the code and am still not sure if I get it right. Why does LWWindowPeer even care about the EXITED/ENTERED events for components? Shouldn't this code belong to LWComponentPeer? Or even the shared code? How do Swing components in regular Swing apps get the ENTERED/EXITED events then? Why can't we use the same approach for LWAWT? -- best regards, Anthony On 8/24/2012 5:53 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ > The comments are below: > > On 8/23/2012 4:51 PM, Anthony Petrov wrote: >> Hi Alexandr, >> >> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate >> through app's windows only once and send both Exited and Entered >> events where needed? > Now, when we do not care about the order of the mouse enter/exit > events generation it is possible to do. I have updated the code. >> >> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >> longer requires a window pointer as an argument. > Fixed. >> >> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >> should never import C* classes. Instead you should've added a new >> method to the PlatformWindow interface, and used it from LWWindowPeer. >> The CPlatformWindow should've implemented this method, and called an >> appropriate native method from there. In this case, however, you >> actually need a static method, so it'd better be part of the LWToolkit >> interface, and implemented in the LWCToolkit class instead. > I see. It seems that the getTopmostWindowUnderMouse method > implementation is different for the CPlatformWindow and for the > CPlatformEmbeddedFrame. > So I added the getTopmostPlatformWindowUnderMouse method to the > PlatformWindow interface. > > Thanks, > Alexandr. > >> >> -- >> best regards, >> Anthony >> >> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>> >>> Could someone review the fix? >>> >>> Thanks, >>> Alexandr. >>> >>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>> >>>> The comments are below: >>>> >>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>> simple 32 bit int is probably not what you intended to do. >>>> fixed. >>>>> Also, have you considered simply calling -[NSWindow >>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then >>>>> removing the calls that flip it on and off in -[AWTView >>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also require a >>>>> change in >>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>> which has a comment that states it only turns on mouse moved events >>>>> if the window is currently under the mouse. >>>> I tried it. The result that I got is that a dragging mouse from one >>>> window to another does not generate mouse enter/exit events on the >>>> second window in case when tracking rect is used and the >>>> acceptsMouseMovedEvents flag is always set to YES. >>>> >>>>> I would think that AppKit should be more than happy to send you >>>>> mouse-over/enter/exited events as long as you say you want them. Was >>>>> this approach tried and didn't work for some reason? >>>>>> Hi, Alexander. >>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>> I changed the TrackingRect to TrackingArea in the updated fix. It now >>>> generates the mouse enter/exit events on the second window during drag. >>>> So it is not necessary to generates such events from our side. >>>> >>>> The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit >>>> events for component in case when a mouse is dragged from one window >>>> to another. >>>> Where the second window contains it's own components and the only way >>>> to know about tracking over them are drag events which receives the >>>> first window. >>>> >>>> I think that the LWWindowPeer class code can be simplified if we >>>> assume that window mouse enter/exit events are always come to the >>>> current window. >>>> So the component mouse enter/exit events can be tracked only in the >>>> current or topmost window. >>>> For this case I separated the global lastCommonMouseEventPeer which is >>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>> >>>> According to the specification: The proper order of mouse-entered and >>>> mouse-exited events received by tracking-area objects in an >>>> application cannot be guaranteed. >>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>> >>>> >>>> So it seems it is not possible to have one lastMouseEventPeer instead >>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>> >>>> And there are possible situations that we can receive mouse drag event >>>> between enter and exit. >>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>> class. So the component mouse enter/exit events are not generated if >>>> the window mouse exited event is received and window mouse entered is >>>> not. >>>> >>>> There is the test: >>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>> It shows that even using the TrackingArea some mouse enter/exit events >>>> are not generateed in the following cases: >>>> - window is created under the mouse >>>> - window changes it's bounds so it becomes under the mouse >>>> >>>> For this cases it still necessary to generate mouse enter/exit events >>>> from our side. >>>> I just moved the related code to one method >>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>> >>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>> >>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>> dragged over the initial window the mouse enter/exit events should >>>>>>> not be generated for the components which are under the toolbar. >>>>>>> >>>>>>> The current fix is supposed to solve this regression and also to >>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>> mouse is dragged from one window to another or a new window is >>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>> >>>>>>> Let's see the following cases >>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>> >>>>>>> 2) Mouse is dragged from one window to another. >>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>> the second window. >>>>>>> >>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>> the second window only after releasing the mouse. >>>>>>> >>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>> window is dragged (toolbar dragging). >>>>>>> >>>>>>> However the Java system generates mouse enter/exit events each time >>>>>>> when a mouse is dragged over any window. >>>>>>> >>>>>>> To fix this the following methods are introduced: >>>>>>> - Get topmost window under mouse >>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>> >>>>>>> >>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>> handled previous and next components and is able to generate mouse >>>>>>> enter/exit events for them. >>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>> of this the fix generates the mouse enter/exit window events on the >>>>>>> native side. >>>>>>> >>>>>>> Generating mouse enter/exit events always should be in order where >>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>> >>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to >>>>>>> generate mouse enter/exit events for all windows during mouse drag >>>>>>> or window creation/window bounds changing. >>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>> This method also tries to generate both mouse enter and exit event >>>>>>> for the same window but only one of them can be applicable because >>>>>>> the isTopMostWindowUnderMouse state is not changed for these calls. >>>>>>> >>>>>>> So the window enter/exit events now are always generated from the >>>>>>> native system and component enter/exit events are generated in the >>>>>>> LWWindowPeer class. >>>>>>> >>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>> case when a mouse is dragged from one window to another the current >>>>>>> component receives drag events and last and topmostUnderMouse links >>>>>>> handle components mouse exit/enter events on the second window. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>> >>> > From anton.litvinov at oracle.com Fri Aug 24 10:36:26 2012 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Fri, 24 Aug 2012 21:36:26 +0400 Subject: [7u8] Review request for 7193219: JComboBox serialization fails in JDK 1.7 Message-ID: <5037BB9A.4010905@oracle.com> Hello, Please review the following fix for a bug. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219 Webrev: http://cr.openjdk.java.net/~alexp/7193219/webrev.00 For details on this bug please look at "Evaluation" field on a web page of this bug. The provided webrev contains both a fix and a corresponding unit-test. Also before publishing this webrev all unit-test from the "java.awt" and "javax.swing" swing related to serialization and usage of "GraphicsConfiguration" class were run and no negative changes were observed comparing the results of tests' runs on JDK with and without patch represented by this webrev. Thank you, Anton From Sergey.Bylokhov at oracle.com Fri Aug 24 13:49:24 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 25 Aug 2012 00:49:24 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <50378763.60508@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> Message-ID: <5037E8D4.1000901@oracle.com> Hi Alexander. In the fix NSTrackingArea has NSTrackingCursorUpdate option but i did not see cursorUpdate: method. Probably we can get some useful information from it? 24.08.2012 17:53, Alexander Scherbatiy ?????: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ > The comments are below: > > On 8/23/2012 4:51 PM, Anthony Petrov wrote: >> Hi Alexandr, >> >> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate >> through app's windows only once and send both Exited and Entered >> events where needed? > Now, when we do not care about the order of the mouse enter/exit > events generation it is possible to do. I have updated the code. >> >> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >> longer requires a window pointer as an argument. > Fixed. >> >> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >> should never import C* classes. Instead you should've added a new >> method to the PlatformWindow interface, and used it from >> LWWindowPeer. The CPlatformWindow should've implemented this method, >> and called an appropriate native method from there. In this case, >> however, you actually need a static method, so it'd better be part of >> the LWToolkit interface, and implemented in the LWCToolkit class >> instead. > I see. It seems that the getTopmostWindowUnderMouse method > implementation is different for the CPlatformWindow and for the > CPlatformEmbeddedFrame. > So I added the getTopmostPlatformWindowUnderMouse method to the > PlatformWindow interface. > > Thanks, > Alexandr. > >> >> -- >> best regards, >> Anthony >> >> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>> >>> Could someone review the fix? >>> >>> Thanks, >>> Alexandr. >>> >>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>> >>>> The comments are below: >>>> >>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>> simple 32 bit int is probably not what you intended to do. >>>> fixed. >>>>> Also, have you considered simply calling -[NSWindow >>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then >>>>> removing the calls that flip it on and off in -[AWTView >>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also require a >>>>> change in >>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>> which has a comment that states it only turns on mouse moved events >>>>> if the window is currently under the mouse. >>>> I tried it. The result that I got is that a dragging mouse from one >>>> window to another does not generate mouse enter/exit events on the >>>> second window in case when tracking rect is used and the >>>> acceptsMouseMovedEvents flag is always set to YES. >>>> >>>>> I would think that AppKit should be more than happy to send you >>>>> mouse-over/enter/exited events as long as you say you want them. Was >>>>> this approach tried and didn't work for some reason? >>>>>> Hi, Alexander. >>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>> I changed the TrackingRect to TrackingArea in the updated fix. It now >>>> generates the mouse enter/exit events on the second window during >>>> drag. >>>> So it is not necessary to generates such events from our side. >>>> >>>> The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit >>>> events for component in case when a mouse is dragged from one window >>>> to another. >>>> Where the second window contains it's own components and the only way >>>> to know about tracking over them are drag events which receives the >>>> first window. >>>> >>>> I think that the LWWindowPeer class code can be simplified if we >>>> assume that window mouse enter/exit events are always come to the >>>> current window. >>>> So the component mouse enter/exit events can be tracked only in the >>>> current or topmost window. >>>> For this case I separated the global lastCommonMouseEventPeer which is >>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>> >>>> According to the specification: The proper order of mouse-entered and >>>> mouse-exited events received by tracking-area objects in an >>>> application cannot be guaranteed. >>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>> >>>> >>>> So it seems it is not possible to have one lastMouseEventPeer instead >>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>> >>>> And there are possible situations that we can receive mouse drag event >>>> between enter and exit. >>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>> class. So the component mouse enter/exit events are not generated if >>>> the window mouse exited event is received and window mouse entered is >>>> not. >>>> >>>> There is the test: >>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>> It shows that even using the TrackingArea some mouse enter/exit events >>>> are not generateed in the following cases: >>>> - window is created under the mouse >>>> - window changes it's bounds so it becomes under the mouse >>>> >>>> For this cases it still necessary to generate mouse enter/exit events >>>> from our side. >>>> I just moved the related code to one method >>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>> >>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>> >>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>> dragged over the initial window the mouse enter/exit events should >>>>>>> not be generated for the components which are under the toolbar. >>>>>>> >>>>>>> The current fix is supposed to solve this regression and also to >>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>> mouse is dragged from one window to another or a new window is >>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>> >>>>>>> Let's see the following cases >>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>> >>>>>>> 2) Mouse is dragged from one window to another. >>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>> the second window. >>>>>>> >>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>> the second window only after releasing the mouse. >>>>>>> >>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>> window is dragged (toolbar dragging). >>>>>>> >>>>>>> However the Java system generates mouse enter/exit events each time >>>>>>> when a mouse is dragged over any window. >>>>>>> >>>>>>> To fix this the following methods are introduced: >>>>>>> - Get topmost window under mouse >>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>> >>>>>>> >>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>> handled previous and next components and is able to generate mouse >>>>>>> enter/exit events for them. >>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>> of this the fix generates the mouse enter/exit window events on the >>>>>>> native side. >>>>>>> >>>>>>> Generating mouse enter/exit events always should be in order where >>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>> >>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to >>>>>>> generate mouse enter/exit events for all windows during mouse drag >>>>>>> or window creation/window bounds changing. >>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>> This method also tries to generate both mouse enter and exit event >>>>>>> for the same window but only one of them can be applicable because >>>>>>> the isTopMostWindowUnderMouse state is not changed for these calls. >>>>>>> >>>>>>> So the window enter/exit events now are always generated from the >>>>>>> native system and component enter/exit events are generated in the >>>>>>> LWWindowPeer class. >>>>>>> >>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>> case when a mouse is dragged from one window to another the current >>>>>>> component receives drag events and last and topmostUnderMouse links >>>>>>> handle components mouse exit/enter events on the second window. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>>>> >>>> >>> > -- Best regards, Sergey. From james.graham at oracle.com Fri Aug 24 16:07:18 2012 From: james.graham at oracle.com (Jim Graham) Date: Fri, 24 Aug 2012 16:07:18 -0700 Subject: [8] Review request for 7153339: InternalError when drawLine with Xor and Antialiasing In-Reply-To: <503750F4.2010208@oracle.com> References: <50257C8F.1010201@oracle.com> <50259500.3050203@oracle.com> <5036BEC2.8090608@oracle.com> <5036C4FC.9010101@oracle.com> <503750F4.2010208@oracle.com> Message-ID: <50380926.20307@oracle.com> Hi Oleg, Let me clarify, I'm not referring to a "better way" to fix this. Actually, the fix you have prepared has a problem. Once the SD is "invalid due to switching to software" and the SG2D decides to install a null SD instead, then it will never recover. But, no change to a drawable should happen (other than it going away) to cause that state. The SG2D's were designed to survive changes in state to the underlying drawable, as long as it remains viable as a drawing destination, but here you are giving up on it when that (externally not really very obvious) state change occurs. Thread A could be happily rendering to the surface on the screen, thread B decides to use XOR thereby changing the state, but thread A's G2D now stops working? Thread A would be very very confused. So, while there may be a fix we could add to SG2D to work around the problem, your fix isn't the right solution. I believe that the right solution is to have the D3DSurface return the correct new surface, but it being "what I think is the right solution" is just part of the issue with your currently proposed fix - the proposed fix violates a long-standing behavior of G2D objects to remain viable until the surface is gone... ...jim On 8/24/2012 3:01 AM, Oleg Pekhovskiy wrote: > Hi Jim, > > first of all I should say, that I prepared that fix for 7u as the most > safe, with minimum changes. > I agree that getReplacement() should return a valid sufrace or null, but > it doesn't happen during that switch. > > That CR was assigned to me because my previous changes for: > 7112642 Incorrect checking for graphics rendering object > 7121482 some sun/java2d and sun/awt tests failed with InvalidPipeException > discovered the problem with getReplacement() and were somehow related. > > But maybe it would be better to create a separate CR for > getReplacement() issue and assign it to Java2d Team? > I also could add a comment for "!surfaceData.isValid()" reffering to > CR7153339. > > What do you think? > > Thanks, > Oleg > > 24.08.2012 4:04, Jim Graham wrote: >> Hi Oleg, >> >> getReplacement should not be returning an invalid surface. If the >> current D3DSD is invalid, then it should return a valid replacement. >> The only time it should return null is when the window is gone. It >> sounds like the window isn't gone here, it has just switched over to a >> non-D3D type of SurfaceData and return that... >> >> ...jim >> >> On 8/23/2012 4:37 PM, Oleg Pekhovskiy wrote: >>> Hi Phil, Jim, >>> >>> thank you for pointing out the testing work that should be performed. >>> I tested my fix with the following regression tests: >>> test/java/awt/Graphics >>> test/java/awt/Graphics2D >>> test/java/awt/GraphicsDevice >>> test/java/awt/GraphicsEnvironment >>> test/sun/java2d >>> >>> Plus I tested performance differences on: >>> demo/jfc/Java2D/Java2Demo.jar >>> >>> Testing was done on Windows 7 & Ubuntu 12.04 LTS. >>> No differences were found. >>> >>> I also asked Yuri Nesterenko to test all that stuff on Mac. >>> >>> Thanks, >>> Oleg >>> >>> >>> 11.08.2012 3:10, Phil Race wrote: >>>> Oleg, >>>> This looks OK to me but since this is a shared code change I have >>>> to ask what testing you've done ? >>>> >>>> Also why not provide a regression test ? The provided test was >>>> interactive but I think it can be automated. >>>> >>>> You need another review and I'd like Jim to take a look. >>>> >>>> -phil. >>>> >>>> On 8/10/2012 2:26 PM, Oleg Pekhovskiy wrote: >>>>> Hi, >>>>> >>>>> Please review the fix for CR: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153339 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~bagiras/8/7153339.1/ >>>>> >>>>> Comments: >>>>> XOR is not supported for D3D (see comments inside >>>>> D3DSurfaceData.validatePipe()) and >>>>> software rendering is used invalidating current D3DSurfaceData. >>>>> So we have situation when component's peer has invalid SurfaceData >>>>> and it's retrieved in >>>>> SunGraphics2D.revalidateAll() through SurfaceData.getReplacement() >>>>> without any check. >>>>> That's why I added validity check there. >>>>> >>>>> Thanks, >>>>> Oleg >>>>> >>>>> >>>> >>> >>> > From alexandr.scherbatiy at oracle.com Mon Aug 27 04:29:36 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 27 Aug 2012 15:29:36 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <5037E8D4.1000901@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> <5037E8D4.1000901@oracle.com> Message-ID: <503B5A20.9010604@oracle.com> On 8/25/2012 12:49 AM, Sergey Bylokhov wrote: > Hi Alexander. > In the fix NSTrackingArea has NSTrackingCursorUpdate option but i did > not see cursorUpdate: method. Probably we can get some useful > information from it? Now all necessary information about the cursor updating is tracked in the resetCursorRects method according to the "Mouse-Tracking and Cursor-Update Events" doc: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/MouseTrackingEvents/MouseTrackingEvents.html I tried to add the cursorUpdate method and in the case when a Frame is pro-grammatically moved out of the mouse cursor this method is not invoked (probably as expected). It means that the cursorUpdate method can't be used for the mouse exit event generation in this case. Such behavior is checked by the test: test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java Thanks, Alexandr. > > 24.08.2012 17:53, Alexander Scherbatiy ?????: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ >> The comments are below: >> >> On 8/23/2012 4:51 PM, Anthony Petrov wrote: >>> Hi Alexandr, >>> >>> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we >>> iterate through app's windows only once and send both Exited and >>> Entered events where needed? >> Now, when we do not care about the order of the mouse enter/exit >> events generation it is possible to do. I have updated the code. >>> >>> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >>> longer requires a window pointer as an argument. >> Fixed. >>> >>> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >>> should never import C* classes. Instead you should've added a new >>> method to the PlatformWindow interface, and used it from >>> LWWindowPeer. The CPlatformWindow should've implemented this method, >>> and called an appropriate native method from there. In this case, >>> however, you actually need a static method, so it'd better be part >>> of the LWToolkit interface, and implemented in the LWCToolkit class >>> instead. >> I see. It seems that the getTopmostWindowUnderMouse method >> implementation is different for the CPlatformWindow and for the >> CPlatformEmbeddedFrame. >> So I added the getTopmostPlatformWindowUnderMouse method to the >> PlatformWindow interface. >> >> Thanks, >> Alexandr. >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>>> >>>> Could someone review the fix? >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>>> >>>>> The comments are below: >>>>> >>>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>>> simple 32 bit int is probably not what you intended to do. >>>>> fixed. >>>>>> Also, have you considered simply calling -[NSWindow >>>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and >>>>>> then >>>>>> removing the calls that flip it on and off in -[AWTView >>>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also >>>>>> require a >>>>>> change in >>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>>> which has a comment that states it only turns on mouse moved events >>>>>> if the window is currently under the mouse. >>>>> I tried it. The result that I got is that a dragging mouse from one >>>>> window to another does not generate mouse enter/exit events on the >>>>> second window in case when tracking rect is used and the >>>>> acceptsMouseMovedEvents flag is always set to YES. >>>>> >>>>>> I would think that AppKit should be more than happy to send you >>>>>> mouse-over/enter/exited events as long as you say you want them. Was >>>>>> this approach tried and didn't work for some reason? >>>>>>> Hi, Alexander. >>>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>>> I changed the TrackingRect to TrackingArea in the updated fix. It now >>>>> generates the mouse enter/exit events on the second window during >>>>> drag. >>>>> So it is not necessary to generates such events from our side. >>>>> >>>>> The getTopmostWindowUnderMouse is necessary to handle mouse >>>>> enter/exit >>>>> events for component in case when a mouse is dragged from one window >>>>> to another. >>>>> Where the second window contains it's own components and the only way >>>>> to know about tracking over them are drag events which receives the >>>>> first window. >>>>> >>>>> I think that the LWWindowPeer class code can be simplified if we >>>>> assume that window mouse enter/exit events are always come to the >>>>> current window. >>>>> So the component mouse enter/exit events can be tracked only in the >>>>> current or topmost window. >>>>> For this case I separated the global lastCommonMouseEventPeer >>>>> which is >>>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>>> >>>>> According to the specification: The proper order of mouse-entered and >>>>> mouse-exited events received by tracking-area objects in an >>>>> application cannot be guaranteed. >>>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>>> >>>>> >>>>> So it seems it is not possible to have one lastMouseEventPeer instead >>>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>>> >>>>> And there are possible situations that we can receive mouse drag >>>>> event >>>>> between enter and exit. >>>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>>> class. So the component mouse enter/exit events are not generated if >>>>> the window mouse exited event is received and window mouse entered is >>>>> not. >>>>> >>>>> There is the test: >>>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>>> It shows that even using the TrackingArea some mouse enter/exit >>>>> events >>>>> are not generateed in the following cases: >>>>> - window is created under the mouse >>>>> - window changes it's bounds so it becomes under the mouse >>>>> >>>>> For this cases it still necessary to generate mouse enter/exit events >>>>> from our side. >>>>> I just moved the related code to one method >>>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>>> >>>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>>> >>>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>>> dragged over the initial window the mouse enter/exit events should >>>>>>>> not be generated for the components which are under the toolbar. >>>>>>>> >>>>>>>> The current fix is supposed to solve this regression and also to >>>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>>> mouse is dragged from one window to another or a new window is >>>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>>> >>>>>>>> Let's see the following cases >>>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>>> >>>>>>>> 2) Mouse is dragged from one window to another. >>>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>>> the second window. >>>>>>>> >>>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>>> the second window only after releasing the mouse. >>>>>>>> >>>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>>> window is dragged (toolbar dragging). >>>>>>>> >>>>>>>> However the Java system generates mouse enter/exit events each >>>>>>>> time >>>>>>>> when a mouse is dragged over any window. >>>>>>>> >>>>>>>> To fix this the following methods are introduced: >>>>>>>> - Get topmost window under mouse >>>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>>> >>>>>>>> >>>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>>> handled previous and next components and is able to generate mouse >>>>>>>> enter/exit events for them. >>>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>>> of this the fix generates the mouse enter/exit window events on >>>>>>>> the >>>>>>>> native side. >>>>>>>> >>>>>>>> Generating mouse enter/exit events always should be in order where >>>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>>> >>>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method >>>>>>>> tries to >>>>>>>> generate mouse enter/exit events for all windows during mouse drag >>>>>>>> or window creation/window bounds changing. >>>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>>> This method also tries to generate both mouse enter and exit event >>>>>>>> for the same window but only one of them can be applicable because >>>>>>>> the isTopMostWindowUnderMouse state is not changed for these >>>>>>>> calls. >>>>>>>> >>>>>>>> So the window enter/exit events now are always generated from the >>>>>>>> native system and component enter/exit events are generated in the >>>>>>>> LWWindowPeer class. >>>>>>>> >>>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>>> case when a mouse is dragged from one window to another the >>>>>>>> current >>>>>>>> component receives drag events and last and topmostUnderMouse >>>>>>>> links >>>>>>>> handle components mouse exit/enter events on the second window. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>> >>>> >> > > From Sergey.Bylokhov at oracle.com Mon Aug 27 05:43:24 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 27 Aug 2012 16:43:24 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503B5A20.9010604@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> <5037E8D4.1000901@oracle.com> <503B5A20.9010604@oracle.com> Message-ID: <503B6B6C.6050605@oracle.com> Hi, Alexander. So NSTrackingCursorUpdate option is not necessary? 27.08.2012 15:29, Alexander Scherbatiy wrote: > On 8/25/2012 12:49 AM, Sergey Bylokhov wrote: >> Hi Alexander. >> In the fix NSTrackingArea has NSTrackingCursorUpdate option but i did >> not see cursorUpdate: method. Probably we can get some useful >> information from it? > Now all necessary information about the cursor updating is > tracked in the resetCursorRects method according to the > "Mouse-Tracking and Cursor-Update Events" doc: > https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/MouseTrackingEvents/MouseTrackingEvents.html > > I tried to add the cursorUpdate method and in the case when a Frame > is pro-grammatically moved out of the mouse cursor this method is not > invoked (probably as expected). > It means that the cursorUpdate method can't be used for the mouse > exit event generation in this case. > Such behavior is checked by the test: > test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java > > Thanks, > Alexandr. > >> >> 24.08.2012 17:53, Alexander Scherbatiy ?????: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ >>> The comments are below: >>> >>> On 8/23/2012 4:51 PM, Anthony Petrov wrote: >>>> Hi Alexandr, >>>> >>>> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we >>>> iterate through app's windows only once and send both Exited and >>>> Entered events where needed? >>> Now, when we do not care about the order of the mouse enter/exit >>> events generation it is possible to do. I have updated the code. >>>> >>>> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >>>> longer requires a window pointer as an argument. >>> Fixed. >>>> >>>> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >>>> should never import C* classes. Instead you should've added a new >>>> method to the PlatformWindow interface, and used it from >>>> LWWindowPeer. The CPlatformWindow should've implemented this >>>> method, and called an appropriate native method from there. In this >>>> case, however, you actually need a static method, so it'd better be >>>> part of the LWToolkit interface, and implemented in the LWCToolkit >>>> class instead. >>> I see. It seems that the getTopmostWindowUnderMouse method >>> implementation is different for the CPlatformWindow and for the >>> CPlatformEmbeddedFrame. >>> So I added the getTopmostPlatformWindowUnderMouse method to the >>> PlatformWindow interface. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>>>> >>>>> Could someone review the fix? >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>>>> >>>>>> The comments are below: >>>>>> >>>>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>>>> simple 32 bit int is probably not what you intended to do. >>>>>> fixed. >>>>>>> Also, have you considered simply calling -[NSWindow >>>>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and >>>>>>> then >>>>>>> removing the calls that flip it on and off in -[AWTView >>>>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also >>>>>>> require a >>>>>>> change in >>>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>>>> which has a comment that states it only turns on mouse moved events >>>>>>> if the window is currently under the mouse. >>>>>> I tried it. The result that I got is that a dragging mouse from one >>>>>> window to another does not generate mouse enter/exit events on the >>>>>> second window in case when tracking rect is used and the >>>>>> acceptsMouseMovedEvents flag is always set to YES. >>>>>> >>>>>>> I would think that AppKit should be more than happy to send you >>>>>>> mouse-over/enter/exited events as long as you say you want them. >>>>>>> Was >>>>>>> this approach tried and didn't work for some reason? >>>>>>>> Hi, Alexander. >>>>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>>>> I changed the TrackingRect to TrackingArea in the updated fix. It >>>>>> now >>>>>> generates the mouse enter/exit events on the second window during >>>>>> drag. >>>>>> So it is not necessary to generates such events from our side. >>>>>> >>>>>> The getTopmostWindowUnderMouse is necessary to handle mouse >>>>>> enter/exit >>>>>> events for component in case when a mouse is dragged from one window >>>>>> to another. >>>>>> Where the second window contains it's own components and the only >>>>>> way >>>>>> to know about tracking over them are drag events which receives the >>>>>> first window. >>>>>> >>>>>> I think that the LWWindowPeer class code can be simplified if we >>>>>> assume that window mouse enter/exit events are always come to the >>>>>> current window. >>>>>> So the component mouse enter/exit events can be tracked only in the >>>>>> current or topmost window. >>>>>> For this case I separated the global lastCommonMouseEventPeer >>>>>> which is >>>>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>>>> >>>>>> According to the specification: The proper order of mouse-entered >>>>>> and >>>>>> mouse-exited events received by tracking-area objects in an >>>>>> application cannot be guaranteed. >>>>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>>>> >>>>>> >>>>>> So it seems it is not possible to have one lastMouseEventPeer >>>>>> instead >>>>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>>>> >>>>>> And there are possible situations that we can receive mouse drag >>>>>> event >>>>>> between enter and exit. >>>>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>>>> class. So the component mouse enter/exit events are not generated if >>>>>> the window mouse exited event is received and window mouse >>>>>> entered is >>>>>> not. >>>>>> >>>>>> There is the test: >>>>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>>>> It shows that even using the TrackingArea some mouse enter/exit >>>>>> events >>>>>> are not generateed in the following cases: >>>>>> - window is created under the mouse >>>>>> - window changes it's bounds so it becomes under the mouse >>>>>> >>>>>> For this cases it still necessary to generate mouse enter/exit >>>>>> events >>>>>> from our side. >>>>>> I just moved the related code to one method >>>>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>>>> >>>>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>>>> >>>>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>>>> dragged over the initial window the mouse enter/exit events >>>>>>>>> should >>>>>>>>> not be generated for the components which are under the toolbar. >>>>>>>>> >>>>>>>>> The current fix is supposed to solve this regression and also to >>>>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>>>> mouse is dragged from one window to another or a new window is >>>>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>>>> >>>>>>>>> Let's see the following cases >>>>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>>>> >>>>>>>>> 2) Mouse is dragged from one window to another. >>>>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>>>> the second window. >>>>>>>>> >>>>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>>>> the second window only after releasing the mouse. >>>>>>>>> >>>>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>>>> window is dragged (toolbar dragging). >>>>>>>>> >>>>>>>>> However the Java system generates mouse enter/exit events each >>>>>>>>> time >>>>>>>>> when a mouse is dragged over any window. >>>>>>>>> >>>>>>>>> To fix this the following methods are introduced: >>>>>>>>> - Get topmost window under mouse >>>>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>>>> >>>>>>>>> >>>>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>>>> handled previous and next components and is able to generate >>>>>>>>> mouse >>>>>>>>> enter/exit events for them. >>>>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>>>> of this the fix generates the mouse enter/exit window events >>>>>>>>> on the >>>>>>>>> native side. >>>>>>>>> >>>>>>>>> Generating mouse enter/exit events always should be in order >>>>>>>>> where >>>>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>>>> >>>>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method >>>>>>>>> tries to >>>>>>>>> generate mouse enter/exit events for all windows during mouse >>>>>>>>> drag >>>>>>>>> or window creation/window bounds changing. >>>>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>>>> This method also tries to generate both mouse enter and exit >>>>>>>>> event >>>>>>>>> for the same window but only one of them can be applicable >>>>>>>>> because >>>>>>>>> the isTopMostWindowUnderMouse state is not changed for these >>>>>>>>> calls. >>>>>>>>> >>>>>>>>> So the window enter/exit events now are always generated from the >>>>>>>>> native system and component enter/exit events are generated in >>>>>>>>> the >>>>>>>>> LWWindowPeer class. >>>>>>>>> >>>>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>>>> case when a mouse is dragged from one window to another the >>>>>>>>> current >>>>>>>>> component receives drag events and last and topmostUnderMouse >>>>>>>>> links >>>>>>>>> handle components mouse exit/enter events on the second window. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>> >>>>> >>> >> >> > -- Best regards, Sergey. From anthony.petrov at oracle.com Mon Aug 27 05:49:01 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 27 Aug 2012 16:49:01 +0400 Subject: [7u8] Review request for 7193219: JComboBox serialization fails in JDK 1.7 In-Reply-To: <5037BB9A.4010905@oracle.com> References: <5037BB9A.4010905@oracle.com> Message-ID: <503B6CBD.7020109@oracle.com> Hi Anton, After deserialization completes, the components in the 'component' collection must all share the same graphics configuration as its parent container (which is being deserialized). While your fix resolves the NPE, it doesn't yet sets up the child components with the correct graphics configuration after the 'component' collection has been populated which children during deserialization. I think we should probably add a deferred call to updateGraphicsData() somewhere at the readObject() method. Also, should this issue be fixed for JDK 8 first, and then ported back to JDK 7u? -- best regards, Anthony On 08/24/12 21:36, Anton Litvinov wrote: > Hello, > > Please review the following fix for a bug. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219 > Webrev: http://cr.openjdk.java.net/~alexp/7193219/webrev.00 > > For details on this bug please look at "Evaluation" field on a web page > of this bug. The provided webrev contains both a fix and a corresponding > unit-test. Also before publishing this webrev all unit-test from the > "java.awt" and > "javax.swing" swing related to serialization and usage of > "GraphicsConfiguration" class were run and no negative changes were > observed comparing the results of tests' runs on JDK with and without > patch represented by this webrev. > > Thank you, > Anton From anthony.petrov at oracle.com Mon Aug 27 05:56:21 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 27 Aug 2012 16:56:21 +0400 Subject: [7u8] Review request for 7193219: JComboBox serialization fails in JDK 1.7 In-Reply-To: <503B6CBD.7020109@oracle.com> References: <5037BB9A.4010905@oracle.com> <503B6CBD.7020109@oracle.com> Message-ID: <503B6E75.8050800@oracle.com> Also, I suggest to name the test directory/filename with a human-readable name (just like all the other tests in AWT area do). BTW, since this is an AWT test, do we actually have to use Swing there? Can we make it an AWT-only test? -- best regards, Anthony On 08/27/12 16:49, Anthony Petrov wrote: > Hi Anton, > > After deserialization completes, the components in the 'component' > collection must all share the same graphics configuration as its parent > container (which is being deserialized). While your fix resolves the > NPE, it doesn't yet sets up the child components with the correct > graphics configuration after the 'component' collection has been > populated which children during deserialization. I think we should > probably add a deferred call to updateGraphicsData() somewhere at the > readObject() method. > > Also, should this issue be fixed for JDK 8 first, and then ported back > to JDK 7u? > > -- > best regards, > Anthony > > On 08/24/12 21:36, Anton Litvinov wrote: >> Hello, >> >> Please review the following fix for a bug. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219 >> Webrev: http://cr.openjdk.java.net/~alexp/7193219/webrev.00 >> >> For details on this bug please look at "Evaluation" field on a web page >> of this bug. The provided webrev contains both a fix and a corresponding >> unit-test. Also before publishing this webrev all unit-test from the >> "java.awt" and >> "javax.swing" swing related to serialization and usage of >> "GraphicsConfiguration" class were run and no negative changes were >> observed comparing the results of tests' runs on JDK with and without >> patch represented by this webrev. >> >> Thank you, >> Anton From anton.litvinov at oracle.com Mon Aug 27 07:53:33 2012 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Mon, 27 Aug 2012 18:53:33 +0400 Subject: [7u8] Review request for 7193219: JComboBox serialization fails in JDK 1.7 In-Reply-To: <503B6E75.8050800@oracle.com> References: <5037BB9A.4010905@oracle.com> <503B6CBD.7020109@oracle.com> <503B6E75.8050800@oracle.com> Message-ID: <503B89ED.1020008@oracle.com> Hello Anthony, Thank you for the review. I would like to clarify that this issue is an escalation. After working on this bug I came to a conclusion that a reason of this bug is the fact that updateGraphicsData() method of not completely deserialized container is called during deserialization process. In this case the situation is the following: 1. readObject() method of JPanel is called. 1.1. readObject() method of JFrame is called during deserialization of JPanel's subcomponents, since they depend on JFrame through PropertyChangeSupport field. 1.2. initDeserializedWindow of JFrame as java.awt.Window is called and leads to subsequent calls to updateGraphicsData() of all subcomponents including that JPanel in step 1, which was not executed completely yet. Deferring of updateGraphicsData() method could be a solution, but how can this be done technically? Also is there a guarantee that no logic, which executes after updateGraphicsData() and before the end of deserialization, relies on the results of updateGraphicsData() method? This issue is reproducible on JDK 8 too, but since it was originally escalated on JDK 7 it should be fixed on JDK 7 first and then fixed in JDK 8. Concerning a name of a directory containing the test, I am a new employee and I do not know the exact naming conventions. But before doing this I searched for existing tests and found many directories created in 2012 whose names contain bug numbers. I am ready to apply what ever name is better. I do not think that the test case can be written without Swing package, because it is related to certain escalation and I do not have right to change the original test case provided with escalation significantly. Thank you, Anton On 27.08.2012 16:56, Anthony Petrov wrote: > Also, I suggest to name the test directory/filename with a > human-readable name (just like all the other tests in AWT area do). > BTW, since this is an AWT test, do we actually have to use Swing > there? Can we make it an AWT-only test? > > -- > best regards, > Anthony > > On 08/27/12 16:49, Anthony Petrov wrote: >> Hi Anton, >> >> After deserialization completes, the components in the 'component' >> collection must all share the same graphics configuration as its parent >> container (which is being deserialized). While your fix resolves the >> NPE, it doesn't yet sets up the child components with the correct >> graphics configuration after the 'component' collection has been >> populated which children during deserialization. I think we should >> probably add a deferred call to updateGraphicsData() somewhere at the >> readObject() method. >> >> Also, should this issue be fixed for JDK 8 first, and then ported back >> to JDK 7u? >> >> -- >> best regards, >> Anthony >> >> On 08/24/12 21:36, Anton Litvinov wrote: >>> Hello, >>> >>> Please review the following fix for a bug. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219 >>> Webrev: http://cr.openjdk.java.net/~alexp/7193219/webrev.00 >>> >>> For details on this bug please look at "Evaluation" field on a web page >>> of this bug. The provided webrev contains both a fix and a >>> corresponding >>> unit-test. Also before publishing this webrev all unit-test from the >>> "java.awt" and >>> "javax.swing" swing related to serialization and usage of >>> "GraphicsConfiguration" class were run and no negative changes were >>> observed comparing the results of tests' runs on JDK with and without >>> patch represented by this webrev. >>> >>> Thank you, >>> Anton From denis.fokin at oracle.com Mon Aug 27 08:22:04 2012 From: denis.fokin at oracle.com (Denis S. Fokin) Date: Mon, 27 Aug 2012 19:22:04 +0400 Subject: [8] Review request for 7192887 java/awt/Window/Grab/GrabTest.java still failed (fix failed for CR 7149068) Message-ID: <503B909C.70400@oracle.com> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7192887 webrev: http://http://cr.openjdk.java.net/~denis/7192887/webrev UngrabEvent is not sent on some platforms (XToolkit) on window disposal. I have added the code in XWindowPeer.dispose() method. We do the similar posts on EDT in XWindowPeer but I do not think that extraction the code in a method is needed here. Thank you, Denis. From konstantin.shefov at oracle.com Mon Aug 27 09:24:17 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 27 Aug 2012 20:24:17 +0400 Subject: [8] Review request for 7184326 TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo Message-ID: <503B9F31.4010706@oracle.com> Hello, Please review a fix for the issue: 7190587 Open source and jtreg'ify JAWT regression test Test was modified in to be run with jtreg. The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/ Thanks, Konstantin From konstantin.shefov at oracle.com Mon Aug 27 09:29:02 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Mon, 27 Aug 2012 20:29:02 +0400 Subject: [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test Message-ID: <503BA04E.6000801@oracle.com> Hello, Please review a fix for the issue: 7190587 Open source and jtreg'ify JAWT regression test Test was modified in to be run with jtreg. The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/ Thanks, Konstantin From leonid.romanov at oracle.com Mon Aug 27 11:01:13 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 27 Aug 2012 22:01:13 +0400 Subject: [8] Review request for CR 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper Message-ID: <73053285-D004-4A94-9BF4-8DD188EA31C5@oracle.com> Hi, This is a forward port of the same fix from 7u6. Bug: http://bugs.sun.com/view_bug.do?bug_id=7124239 Webrev: http://cr.openjdk.java.net/~leonidr/7124239/webrev.03/ Thanks, Leonid. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120827/0e66ec00/attachment.html From lana.steuck at oracle.com Mon Aug 27 13:28:09 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 20:28:09 +0000 Subject: hg: jdk8/awt: 2 new changesets Message-ID: <20120827202809.5F38E47755@hg.openjdk.java.net> Changeset: febd7ff52800 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/febd7ff52800 Added tag jdk8-b52 for changeset 8d24def5ceb3 ! .hgtags Changeset: c1a277c6022a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/c1a277c6022a Added tag jdk8-b53 for changeset febd7ff52800 ! .hgtags From lana.steuck at oracle.com Mon Aug 27 13:28:09 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 20:28:09 +0000 Subject: hg: jdk8/awt/corba: 2 new changesets Message-ID: <20120827202813.26FD447756@hg.openjdk.java.net> Changeset: 63aeb7a2472f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/63aeb7a2472f Added tag jdk8-b52 for changeset 80689ff9cb49 ! .hgtags Changeset: 16c82fc74695 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/16c82fc74695 Added tag jdk8-b53 for changeset 63aeb7a2472f ! .hgtags From lana.steuck at oracle.com Mon Aug 27 13:28:14 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 20:28:14 +0000 Subject: hg: jdk8/awt/langtools: 2 new changesets Message-ID: <20120827202824.6DC1B47758@hg.openjdk.java.net> Changeset: d3d0b9cd76e0 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/d3d0b9cd76e0 Added tag jdk8-b52 for changeset 1d2db0e5eabc ! .hgtags Changeset: 9cf72631baf5 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/9cf72631baf5 Added tag jdk8-b53 for changeset d3d0b9cd76e0 ! .hgtags From lana.steuck at oracle.com Mon Aug 27 13:28:15 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 20:28:15 +0000 Subject: hg: jdk8/awt/jaxws: 2 new changesets Message-ID: <20120827202824.808C447759@hg.openjdk.java.net> Changeset: 8a35fd644d3c Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/8a35fd644d3c Added tag jdk8-b52 for changeset f62bc618122e ! .hgtags Changeset: 91970935926a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/91970935926a Added tag jdk8-b53 for changeset 8a35fd644d3c ! .hgtags From lana.steuck at oracle.com Mon Aug 27 13:28:12 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 20:28:12 +0000 Subject: hg: jdk8/awt/jaxp: 2 new changesets Message-ID: <20120827202824.9A2E74775A@hg.openjdk.java.net> Changeset: 2c566f25c39f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/2c566f25c39f Added tag jdk8-b52 for changeset bd3c00d57614 ! .hgtags Changeset: 7dd81ccb7c11 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/7dd81ccb7c11 Added tag jdk8-b53 for changeset 2c566f25c39f ! .hgtags From lana.steuck at oracle.com Mon Aug 27 13:28:25 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 20:28:25 +0000 Subject: hg: jdk8/awt/hotspot: 12 new changesets Message-ID: <20120827202926.3F2224775B@hg.openjdk.java.net> Changeset: ef437ea56651 Author: amurillo Date: 2012-08-03 13:24 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ef437ea56651 7189086: new hotspot build - hs24-b20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1d7922586cf6 Author: twisti Date: 2012-07-24 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/1d7922586cf6 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, kvn, mhaupt Contributed-by: John Rose , Christian Thalinger , Michael Haupt ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/c1/c1_ValueType.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp + src/share/vm/ci/ciMemberName.cpp + src/share/vm/ci/ciMemberName.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/prims/jvmtiTagMap.cpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/exceptions.hpp Changeset: 977007096840 Author: twisti Date: 2012-07-27 16:14 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/977007096840 7187290: nightly failures after JSR 292 lazy method handle update Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/doCall.cpp Changeset: 6c5b7a6becc8 Author: kvn Date: 2012-07-30 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6c5b7a6becc8 7187454: stack overflow in C2 compiler thread on Solaris x86 Summary: Added new FormatBufferResource class to use thread's resource area for error message buffer. Reviewed-by: twisti ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp Changeset: 8cb110fd7627 Author: kvn Date: 2012-08-01 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8cb110fd7627 7188227: VM should recognize M-series SPARC Summary: Check kstat data for SPARC-M. Reviewed-by: roland ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: b72784e722ff Author: twisti Date: 2012-08-01 14:44 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b72784e722ff 7188276: JSR 292: assert(ct == T_OBJECT) failed: rt=T_OBJECT, ct=13 Reviewed-by: kvn, jrose ! src/share/vm/opto/doCall.cpp Changeset: 93c71eb28866 Author: twisti Date: 2012-08-07 14:32 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/93c71eb28866 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: ee7edf31f688 Author: twisti Date: 2012-08-10 15:50 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ee7edf31f688 Merge - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/phaseX.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp Changeset: 4c8f2a12e757 Author: twisti Date: 2012-08-10 17:50 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/4c8f2a12e757 Merge Changeset: 6d0436885201 Author: amurillo Date: 2012-08-10 23:07 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6d0436885201 Added tag hs24-b20 for changeset 4c8f2a12e757 ! .hgtags Changeset: 54240c1b8e87 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/54240c1b8e87 Added tag jdk8-b52 for changeset 6d0436885201 ! .hgtags Changeset: de2aa86e037d Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/de2aa86e037d Added tag jdk8-b53 for changeset 54240c1b8e87 ! .hgtags From lana.steuck at oracle.com Mon Aug 27 13:28:31 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 20:28:31 +0000 Subject: hg: jdk8/awt/jdk: 14 new changesets Message-ID: <20120827203141.EBFBE4775C@hg.openjdk.java.net> Changeset: 05e5ce861a58 Author: jrose Date: 2012-07-12 00:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/05e5ce861a58 7153157: ClassValue.get does not return if computeValue calls remove Summary: Track intermediate states more precisely, according to spec. Reviewed-by: twisti, forax ! src/share/classes/java/lang/ClassValue.java Changeset: beeb1d5ecd9e Author: jrose Date: 2012-07-12 00:11 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/beeb1d5ecd9e 7129034: VM crash with a field setter method with a filterArguments Summary: add null checks before unsafe calls that take a variable base reference; update unit tests Reviewed-by: kvn, twisti ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 556141c6326c Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/556141c6326c 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited Reviewed-by: twisti ! src/share/classes/java/lang/invoke/MemberName.java Changeset: 78f1f4e4e9c7 Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/78f1f4e4e9c7 7127687: MethodType leaks memory due to interning Summary: Replace internTable with a weak-reference version. Reviewed-by: sundar, forax, brutisso Contributed-by: james.laskey at oracle.com ! src/share/classes/java/lang/invoke/MethodType.java Changeset: 050116960e99 Author: twisti Date: 2012-07-24 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/050116960e99 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, mhaupt, forax Contributed-by: John Rose , Christian Thalinger , Michael Haupt - src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java + src/share/classes/java/lang/invoke/DontInline.java + src/share/classes/java/lang/invoke/ForceInline.java + src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/Invokers.java + src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java + src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java + src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! src/share/classes/sun/invoke/util/Wrapper.java ! src/share/classes/sun/misc/Unsafe.java + test/java/lang/invoke/7157574/Test7157574.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java + test/java/lang/invoke/MaxTest.java ! test/java/lang/invoke/MethodHandlesTest.java + test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java + test/java/lang/invoke/remote/RemoteExample.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 64e24cc8e009 Author: twisti Date: 2012-08-07 14:31 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/64e24cc8e009 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java Changeset: e1d063685dc8 Author: twisti Date: 2012-08-09 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e1d063685dc8 7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: 865c411ebcae Author: twisti Date: 2012-08-10 16:03 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/865c411ebcae Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java Changeset: 93ddd9560751 Author: youdwei Date: 2012-08-13 10:45 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/93ddd9560751 7189611: Venezuela current Currency should be Bs.F. Reviewed-by: okutsu ! src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 90a9acfde9e6 Author: mfang Date: 2012-08-13 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/90a9acfde9e6 Merge Changeset: e8569a473cee Author: katleman Date: 2012-08-15 18:04 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e8569a473cee Merge Changeset: 2c6933c5106b Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2c6933c5106b Added tag jdk8-b52 for changeset e8569a473cee ! .hgtags Changeset: 156ab3c38556 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/156ab3c38556 Added tag jdk8-b53 for changeset 2c6933c5106b ! .hgtags Changeset: eaec23aae76a Author: lana Date: 2012-08-27 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/eaec23aae76a Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java From anton.tarasov at oracle.com Tue Aug 28 03:39:02 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 28 Aug 2012 14:39:02 +0400 Subject: [8] Review request for 7192887 java/awt/Window/Grab/GrabTest.java still failed (fix failed for CR 7149068) In-Reply-To: <503B909C.70400@oracle.com> References: <503B909C.70400@oracle.com> Message-ID: <503C9FC6.3070209@oracle.com> Looks fine to me. Thanks, Anton. On 8/27/12 7:22 PM, Denis S. Fokin wrote: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7192887 > webrev: http://http://cr.openjdk.java.net/~denis/7192887/webrev > > UngrabEvent is not sent on some platforms (XToolkit) on window > disposal. I have added the code in XWindowPeer.dispose() method. > > We do the similar posts on EDT in XWindowPeer but I do not think that > extraction the code in a method is needed here. > > Thank you, > Denis. From Sergey.Bylokhov at oracle.com Tue Aug 28 03:57:42 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 28 Aug 2012 14:57:42 +0400 Subject: [8] Review request for 7192887 java/awt/Window/Grab/GrabTest.java still failed (fix failed for CR 7149068) In-Reply-To: <503B909C.70400@oracle.com> References: <503B909C.70400@oracle.com> Message-ID: <503CA426.70804@oracle.com> Hi, Denis. Fix looks good. 27.08.2012 19:22, Denis S. Fokin wrote: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7192887 > webrev: http://http://cr.openjdk.java.net/~denis/7192887/webrev > > UngrabEvent is not sent on some platforms (XToolkit) on window > disposal. I have added the code in XWindowPeer.dispose() method. > > We do the similar posts on EDT in XWindowPeer but I do not think that > extraction the code in a method is needed here. > > Thank you, > Denis. -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Tue Aug 28 04:17:43 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 28 Aug 2012 15:17:43 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <50379706.1000106@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> <50379706.1000106@oracle.com> Message-ID: <503CA8D7.90506@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/7171045/webrev.05/ The comments are below: - NSTrackingCursorUpdate option is removed from the rolloverTrackingArea On 8/24/2012 7:00 PM, Anthony Petrov wrote: > src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java >> 66 public static native CPlatformWindow >> nativeGetTopmostPlatformWindowUnderMouse(); > > This method must probably be private. Fixed. > > Still, I don't see why getTopmostPlatformWindowUnderMouse() must > return null when it's invoked on an embedded frame, and why the > implementation should even be different at all. The mouse is a global > system entity. There's either some window under the mouse, or there's > not. I would still think of LWToolkit.getPlatformWindowUnderMouse(), > and its implementation in LWCToolkit. Dmitry, who is a responsible person for the CPlatformEmbeddedFrame, said that the implementation of the getPlatformWindowUnderMouse() method could be different for applets. So the getPlatformWindowUnderMouse() method implementation will be filled as a separated issue and fixed by Dmitry. > > Also, the logic in LWWindowPeer lines 722-743 seems to be overly > complicated (as well as the whole dispatchMouseEvent() method). E.g., > if the LWWindowPeer manages an embedded frame, we get > topmostWindowPeer == this at line 730, and thus always go through the > 'true' branch of if() at line 733, even though actually the mouse > pointer can be located over some other window at the moment (e.g. over > a popup window opened by an applet). I updated the topmostWindowPeer variable creation so it now can have only the topmost window under mouse value or null and added a comment that the (topmostWindowPeer == null ) condition should be removed after the getPlatformWindowUnderMouse() method implementation in the CPlatformEmbeddedFrame class. For now the (topmostWindowPeer == null ) condition allows to track the mouse enter/exit components events as it was before the fix. > > Overall, it's really difficult to understand what is going on there. > I've spent half an hour reading the code and am still not sure if I > get it right. Why does LWWindowPeer even care about the EXITED/ENTERED > events for components? Shouldn't this code belong to LWComponentPeer? > Or even the shared code? How do Swing components in regular Swing apps > get the ENTERED/EXITED events then? Why can't we use the same approach > for LWAWT? Swing controls have Container in a parent class hierarchy. The Container class has the LightweightDispatcher dispatcher which allows to track mouse moving from one component to another and generate necessary mouse enter/exit events. AWT controls have Component class as a parent and do not have the dispatcher. So moving/dragging a mouse from one AWT control to another does not generate necessary mouse events. The aim of the fix is not redesigning current architecture. It just adds checking a case where a mouse is dragged from one window to another and so the first window which gets the mouse drag events is not the real window for which component enter/exit events should be generated. Thanks, Alexandr. > > -- > best regards, > Anthony > > On 8/24/2012 5:53 PM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ >> The comments are below: >> >> On 8/23/2012 4:51 PM, Anthony Petrov wrote: >>> Hi Alexandr, >>> >>> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we >>> iterate through app's windows only once and send both Exited and >>> Entered events where needed? >> Now, when we do not care about the order of the mouse enter/exit >> events generation it is possible to do. I have updated the code. >>> >>> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >>> longer requires a window pointer as an argument. >> Fixed. >>> >>> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >>> should never import C* classes. Instead you should've added a new >>> method to the PlatformWindow interface, and used it from >>> LWWindowPeer. The CPlatformWindow should've implemented this method, >>> and called an appropriate native method from there. In this case, >>> however, you actually need a static method, so it'd better be part >>> of the LWToolkit interface, and implemented in the LWCToolkit class >>> instead. >> I see. It seems that the getTopmostWindowUnderMouse method >> implementation is different for the CPlatformWindow and for the >> CPlatformEmbeddedFrame. >> So I added the getTopmostPlatformWindowUnderMouse method to the >> PlatformWindow interface. >> >> Thanks, >> Alexandr. >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>>> >>>> Could someone review the fix? >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>>> >>>>> The comments are below: >>>>> >>>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>>> simple 32 bit int is probably not what you intended to do. >>>>> fixed. >>>>>> Also, have you considered simply calling -[NSWindow >>>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and >>>>>> then >>>>>> removing the calls that flip it on and off in -[AWTView >>>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also >>>>>> require a >>>>>> change in >>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>>> which has a comment that states it only turns on mouse moved events >>>>>> if the window is currently under the mouse. >>>>> I tried it. The result that I got is that a dragging mouse from one >>>>> window to another does not generate mouse enter/exit events on the >>>>> second window in case when tracking rect is used and the >>>>> acceptsMouseMovedEvents flag is always set to YES. >>>>> >>>>>> I would think that AppKit should be more than happy to send you >>>>>> mouse-over/enter/exited events as long as you say you want them. Was >>>>>> this approach tried and didn't work for some reason? >>>>>>> Hi, Alexander. >>>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>>> I changed the TrackingRect to TrackingArea in the updated fix. It now >>>>> generates the mouse enter/exit events on the second window during >>>>> drag. >>>>> So it is not necessary to generates such events from our side. >>>>> >>>>> The getTopmostWindowUnderMouse is necessary to handle mouse >>>>> enter/exit >>>>> events for component in case when a mouse is dragged from one window >>>>> to another. >>>>> Where the second window contains it's own components and the only way >>>>> to know about tracking over them are drag events which receives the >>>>> first window. >>>>> >>>>> I think that the LWWindowPeer class code can be simplified if we >>>>> assume that window mouse enter/exit events are always come to the >>>>> current window. >>>>> So the component mouse enter/exit events can be tracked only in the >>>>> current or topmost window. >>>>> For this case I separated the global lastCommonMouseEventPeer >>>>> which is >>>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>>> >>>>> According to the specification: The proper order of mouse-entered and >>>>> mouse-exited events received by tracking-area objects in an >>>>> application cannot be guaranteed. >>>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>>> >>>>> >>>>> So it seems it is not possible to have one lastMouseEventPeer instead >>>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>>> >>>>> And there are possible situations that we can receive mouse drag >>>>> event >>>>> between enter and exit. >>>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>>> class. So the component mouse enter/exit events are not generated if >>>>> the window mouse exited event is received and window mouse entered is >>>>> not. >>>>> >>>>> There is the test: >>>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>>> It shows that even using the TrackingArea some mouse enter/exit >>>>> events >>>>> are not generateed in the following cases: >>>>> - window is created under the mouse >>>>> - window changes it's bounds so it becomes under the mouse >>>>> >>>>> For this cases it still necessary to generate mouse enter/exit events >>>>> from our side. >>>>> I just moved the related code to one method >>>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>>> >>>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>>> >>>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>>> dragged over the initial window the mouse enter/exit events should >>>>>>>> not be generated for the components which are under the toolbar. >>>>>>>> >>>>>>>> The current fix is supposed to solve this regression and also to >>>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>>> mouse is dragged from one window to another or a new window is >>>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>>> >>>>>>>> Let's see the following cases >>>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>>> >>>>>>>> 2) Mouse is dragged from one window to another. >>>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>>> the second window. >>>>>>>> >>>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>>> the second window only after releasing the mouse. >>>>>>>> >>>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>>> window is dragged (toolbar dragging). >>>>>>>> >>>>>>>> However the Java system generates mouse enter/exit events each >>>>>>>> time >>>>>>>> when a mouse is dragged over any window. >>>>>>>> >>>>>>>> To fix this the following methods are introduced: >>>>>>>> - Get topmost window under mouse >>>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>>> >>>>>>>> >>>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>>> handled previous and next components and is able to generate mouse >>>>>>>> enter/exit events for them. >>>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>>> of this the fix generates the mouse enter/exit window events on >>>>>>>> the >>>>>>>> native side. >>>>>>>> >>>>>>>> Generating mouse enter/exit events always should be in order where >>>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>>> >>>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method >>>>>>>> tries to >>>>>>>> generate mouse enter/exit events for all windows during mouse drag >>>>>>>> or window creation/window bounds changing. >>>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>>> This method also tries to generate both mouse enter and exit event >>>>>>>> for the same window but only one of them can be applicable because >>>>>>>> the isTopMostWindowUnderMouse state is not changed for these >>>>>>>> calls. >>>>>>>> >>>>>>>> So the window enter/exit events now are always generated from the >>>>>>>> native system and component enter/exit events are generated in the >>>>>>>> LWWindowPeer class. >>>>>>>> >>>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>>> case when a mouse is dragged from one window to another the >>>>>>>> current >>>>>>>> component receives drag events and last and topmostUnderMouse >>>>>>>> links >>>>>>>> handle components mouse exit/enter events on the second window. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, Sergey. >>>>>>> >>>>> >>>> >> From Sergey.Bylokhov at oracle.com Tue Aug 28 04:22:46 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 28 Aug 2012 15:22:46 +0400 Subject: Objective-C and jcheck In-Reply-To: <20120502135351.B9985470E9@hg.openjdk.java.net> References: <20120502135351.B9985470E9@hg.openjdk.java.net> Message-ID: <503CAA06.6040007@oracle.com> Hi Everybody. Looks like on the server we still use jcheck without fix for Objective-C files? Does anybody know how to apply the fix to jdk8? (see attachment) [jdk] pulling from http://hg.openjdk.java.net/jdk8/awt/jdk searching for changes adding changesets adding manifests adding file changes added 1 changesets with 10 changes to 10 files [jcheck 25e85a608db1 2011-07-08 09:19 -0700] > Changeset: 5305:0fad89bd606b > Author: alexsch > Date: 2012-05-02 17:54 > > 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left side > Reviewed-by: anthony, leonidr src/macosx/native/sun/awt/AWTView.m:84: Trailing whitespace src/macosx/native/sun/awt/AWTWindow.m:173: Trailing whitespace transaction abort! rollback completed skipped: pretxnchangegroup.jcheck hook failed 02.05.2012 17:53, alexandr.scherbatiy at oracle.com wrote > Changeset: 0fad89bd606b > Author: alexsch > Date: 2012-05-02 17:54 +0400 > URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0fad89bd606b > > 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left side > Reviewed-by: anthony, leonidr > > ! src/macosx/classes/sun/lwawt/LWWindowPeer.java > ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java > ! src/macosx/native/sun/awt/AWTView.h > ! src/macosx/native/sun/awt/AWTView.m > ! src/macosx/native/sun/awt/AWTWindow.h > ! src/macosx/native/sun/awt/AWTWindow.m > + test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java > + test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java > + test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java > ! test/java/awt/regtesthelpers/Util.java > -------------- next part -------------- An embedded message was scrubbed... From: Scott Kovatch Subject: Objective-C files not being checked with jcheck Date: Thu, 29 Dec 2011 09:50:08 -0800 Size: 4143 Url: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120828/0359ca0d/.nws From anthony.petrov at oracle.com Tue Aug 28 05:06:49 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 28 Aug 2012 16:06:49 +0400 Subject: [8] Review request for CR 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper In-Reply-To: <73053285-D004-4A94-9BF4-8DD188EA31C5@oracle.com> References: <73053285-D004-4A94-9BF4-8DD188EA31C5@oracle.com> Message-ID: <503CB459.7080608@oracle.com> Looks fine. -- best regards, Anthony On 8/27/2012 10:01 PM, Leonid Romanov wrote: > Hi, > This is a forward port of the same fix from 7u6. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=7124239 > Webrev: http://cr.openjdk.java.net/~leonidr/7124239/webrev.03/ > > Thanks, > Leonid. > From sergey.bylokhov at oracle.com Tue Aug 28 05:09:45 2012 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Tue, 28 Aug 2012 12:09:45 +0000 Subject: hg: jdk8/awt/jdk: 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) Message-ID: <20120828121005.9CF1347770@hg.openjdk.java.net> Changeset: f54660c18774 Author: serb Date: 2012-08-28 16:04 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f54660c18774 7186371: [macosx] Main menu shortcuts not displayed (7u6 regression) Reviewed-by: leonidr ! src/macosx/classes/com/apple/laf/ScreenMenuItem.java ! src/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java From anthony.petrov at oracle.com Tue Aug 28 05:42:49 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 28 Aug 2012 16:42:49 +0400 Subject: [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test In-Reply-To: <503BA04E.6000801@oracle.com> References: <503BA04E.6000801@oracle.com> Message-ID: <503CBCC9.1040107@oracle.com> Hi Konstantin, I think you should modify the copyright headers in each file. The files are no longer proprietary/confidential. .sh and makefiles should also include a copyright header. Please use existing source files in the open repository as a template for the header. test/java/awt/JAWT/MyCanvas.java > 52 f.show(); Please replace this with f.setVisible(true); > 53 robot.delay(10000); I think 10 seconds is kind of too long. It might have been relevant for Java 1.4, but now I think 5 seconds should be pretty much enough for every modern system. test/java/awt/JAWT/JAWT.sh > 137 case "$OS" in > 138 Windows* | CYGWIN* ) > 139 cp ${TESTJAVA}${FS}jre${FS}bin${FS}jawt.dll . > 140 ;; > 141 esac Why is this necessary? This must be a bug in JDK if the library still needs to be copied to the current directory on Windows. Could you verify if the test still works w/o copying the dll? It must, actually. -- best regards, Anthony On 8/27/2012 8:29 PM, Konstantin Shefov wrote: > Hello, > > Please review a fix for the issue: > > 7190587 Open source and jtreg'ify JAWT regression test > > Test was modified in to be run with jtreg. > > The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/ > > > Thanks, > Konstantin > From alexandr.scherbatiy at oracle.com Tue Aug 28 05:57:13 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 28 Aug 2012 16:57:13 +0400 Subject: [7u8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. Message-ID: <503CC029.20302@oracle.com> Hello, Please review the fix for the JDK 7u8: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev7.00/ This is a regression after the fix 7154048 [macosx] At least drag twice, the toolbar can be dragged to the left side. In the case where a toolbar is created under a mouse and it is dragged over the initial window the mouse enter/exit events should not be generated for the components which are under the toolbar. The disabling component mouse enter/exit events generation during drag leads that it does not work in the case where a mouse is dragged over the current window. The full fix that checks that a current window is a topmost window under mouse requires some changes (using tracking area instead of tracking rectangle and so on) is a quite complicated and it seems that it is risky to include it to the JDK 7u8. Current fix just changes the condition for the component mouse enter/exit events generation to the initial state how it was before the 7154048 fix. This allows to generate components mouse enter/exit events, but the following test will fail: java/awt/Mouse/EnterExitEvents/DragWindowTest.java However this test did not work before the 7154048 fix so it is not a regression. Thanks, Alexandr. From anthony.petrov at oracle.com Tue Aug 28 06:06:43 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 28 Aug 2012 17:06:43 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503CA8D7.90506@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> <50379706.1000106@oracle.com> <503CA8D7.90506@oracle.com> Message-ID: <503CC263.9020103@oracle.com> Hi Alexander, Thanks for the clarifications. The code now looks clearer. I'm fine with the fix. -- best regards, Anthony On 8/28/2012 3:17 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/7171045/webrev.05/ > The comments are below: > - NSTrackingCursorUpdate option is removed from the rolloverTrackingArea > > On 8/24/2012 7:00 PM, Anthony Petrov wrote: >> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java >>> 66 public static native CPlatformWindow >>> nativeGetTopmostPlatformWindowUnderMouse(); >> >> This method must probably be private. > Fixed. > >> >> Still, I don't see why getTopmostPlatformWindowUnderMouse() must >> return null when it's invoked on an embedded frame, and why the >> implementation should even be different at all. The mouse is a global >> system entity. There's either some window under the mouse, or there's >> not. I would still think of LWToolkit.getPlatformWindowUnderMouse(), >> and its implementation in LWCToolkit. > > Dmitry, who is a responsible person for the CPlatformEmbeddedFrame, > said that the implementation of the getPlatformWindowUnderMouse() method > could be different for applets. > So the getPlatformWindowUnderMouse() method implementation will be > filled as a separated issue and fixed by Dmitry. > >> >> Also, the logic in LWWindowPeer lines 722-743 seems to be overly >> complicated (as well as the whole dispatchMouseEvent() method). E.g., >> if the LWWindowPeer manages an embedded frame, we get >> topmostWindowPeer == this at line 730, and thus always go through the >> 'true' branch of if() at line 733, even though actually the mouse >> pointer can be located over some other window at the moment (e.g. over >> a popup window opened by an applet). > I updated the topmostWindowPeer variable creation so it now can have > only the topmost window under mouse value or null and added a comment > that the (topmostWindowPeer == null ) > condition should be removed after the getPlatformWindowUnderMouse() > method implementation in the CPlatformEmbeddedFrame class. > For now the (topmostWindowPeer == null ) condition allows to track > the mouse enter/exit components events as it was before the fix. >> >> Overall, it's really difficult to understand what is going on there. >> I've spent half an hour reading the code and am still not sure if I >> get it right. Why does LWWindowPeer even care about the EXITED/ENTERED >> events for components? Shouldn't this code belong to LWComponentPeer? >> Or even the shared code? How do Swing components in regular Swing apps >> get the ENTERED/EXITED events then? Why can't we use the same approach >> for LWAWT? > Swing controls have Container in a parent class hierarchy. The > Container class has the LightweightDispatcher dispatcher which allows to > track mouse moving from one component to another and generate necessary > mouse enter/exit events. > AWT controls have Component class as a parent and do not have the > dispatcher. So moving/dragging a mouse from one AWT control to another > does not generate necessary mouse events. > > The aim of the fix is not redesigning current architecture. It just > adds checking a case where a mouse is dragged from one window to another > and so the first window which gets the mouse drag events is not the real > window for which component enter/exit events should be generated. > > Thanks, > Alexandr. > >> >> -- >> best regards, >> Anthony >> >> On 8/24/2012 5:53 PM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ >>> The comments are below: >>> >>> On 8/23/2012 4:51 PM, Anthony Petrov wrote: >>>> Hi Alexandr, >>>> >>>> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we >>>> iterate through app's windows only once and send both Exited and >>>> Entered events where needed? >>> Now, when we do not care about the order of the mouse enter/exit >>> events generation it is possible to do. I have updated the code. >>>> >>>> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >>>> longer requires a window pointer as an argument. >>> Fixed. >>>> >>>> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >>>> should never import C* classes. Instead you should've added a new >>>> method to the PlatformWindow interface, and used it from >>>> LWWindowPeer. The CPlatformWindow should've implemented this method, >>>> and called an appropriate native method from there. In this case, >>>> however, you actually need a static method, so it'd better be part >>>> of the LWToolkit interface, and implemented in the LWCToolkit class >>>> instead. >>> I see. It seems that the getTopmostWindowUnderMouse method >>> implementation is different for the CPlatformWindow and for the >>> CPlatformEmbeddedFrame. >>> So I added the getTopmostPlatformWindowUnderMouse method to the >>> PlatformWindow interface. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>>>> >>>>> Could someone review the fix? >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>>>> >>>>>> The comments are below: >>>>>> >>>>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>>>> simple 32 bit int is probably not what you intended to do. >>>>>> fixed. >>>>>>> Also, have you considered simply calling -[NSWindow >>>>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and >>>>>>> then >>>>>>> removing the calls that flip it on and off in -[AWTView >>>>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also >>>>>>> require a >>>>>>> change in >>>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>>>> which has a comment that states it only turns on mouse moved events >>>>>>> if the window is currently under the mouse. >>>>>> I tried it. The result that I got is that a dragging mouse from one >>>>>> window to another does not generate mouse enter/exit events on the >>>>>> second window in case when tracking rect is used and the >>>>>> acceptsMouseMovedEvents flag is always set to YES. >>>>>> >>>>>>> I would think that AppKit should be more than happy to send you >>>>>>> mouse-over/enter/exited events as long as you say you want them. Was >>>>>>> this approach tried and didn't work for some reason? >>>>>>>> Hi, Alexander. >>>>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>>>> I changed the TrackingRect to TrackingArea in the updated fix. It now >>>>>> generates the mouse enter/exit events on the second window during >>>>>> drag. >>>>>> So it is not necessary to generates such events from our side. >>>>>> >>>>>> The getTopmostWindowUnderMouse is necessary to handle mouse >>>>>> enter/exit >>>>>> events for component in case when a mouse is dragged from one window >>>>>> to another. >>>>>> Where the second window contains it's own components and the only way >>>>>> to know about tracking over them are drag events which receives the >>>>>> first window. >>>>>> >>>>>> I think that the LWWindowPeer class code can be simplified if we >>>>>> assume that window mouse enter/exit events are always come to the >>>>>> current window. >>>>>> So the component mouse enter/exit events can be tracked only in the >>>>>> current or topmost window. >>>>>> For this case I separated the global lastCommonMouseEventPeer >>>>>> which is >>>>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>>>> >>>>>> According to the specification: The proper order of mouse-entered and >>>>>> mouse-exited events received by tracking-area objects in an >>>>>> application cannot be guaranteed. >>>>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>>>> >>>>>> >>>>>> So it seems it is not possible to have one lastMouseEventPeer instead >>>>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>>>> >>>>>> And there are possible situations that we can receive mouse drag >>>>>> event >>>>>> between enter and exit. >>>>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>>>> class. So the component mouse enter/exit events are not generated if >>>>>> the window mouse exited event is received and window mouse entered is >>>>>> not. >>>>>> >>>>>> There is the test: >>>>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>>>> It shows that even using the TrackingArea some mouse enter/exit >>>>>> events >>>>>> are not generateed in the following cases: >>>>>> - window is created under the mouse >>>>>> - window changes it's bounds so it becomes under the mouse >>>>>> >>>>>> For this cases it still necessary to generate mouse enter/exit events >>>>>> from our side. >>>>>> I just moved the related code to one method >>>>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>>>> >>>>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>>>> >>>>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>>>> dragged over the initial window the mouse enter/exit events should >>>>>>>>> not be generated for the components which are under the toolbar. >>>>>>>>> >>>>>>>>> The current fix is supposed to solve this regression and also to >>>>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>>>> mouse is dragged from one window to another or a new window is >>>>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>>>> >>>>>>>>> Let's see the following cases >>>>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>>>> >>>>>>>>> 2) Mouse is dragged from one window to another. >>>>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>>>> the second window. >>>>>>>>> >>>>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>>>> the second window only after releasing the mouse. >>>>>>>>> >>>>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>>>> window is dragged (toolbar dragging). >>>>>>>>> >>>>>>>>> However the Java system generates mouse enter/exit events each >>>>>>>>> time >>>>>>>>> when a mouse is dragged over any window. >>>>>>>>> >>>>>>>>> To fix this the following methods are introduced: >>>>>>>>> - Get topmost window under mouse >>>>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>>>> >>>>>>>>> >>>>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>>>> handled previous and next components and is able to generate mouse >>>>>>>>> enter/exit events for them. >>>>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>>>> of this the fix generates the mouse enter/exit window events on >>>>>>>>> the >>>>>>>>> native side. >>>>>>>>> >>>>>>>>> Generating mouse enter/exit events always should be in order where >>>>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>>>> >>>>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method >>>>>>>>> tries to >>>>>>>>> generate mouse enter/exit events for all windows during mouse drag >>>>>>>>> or window creation/window bounds changing. >>>>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>>>> This method also tries to generate both mouse enter and exit event >>>>>>>>> for the same window but only one of them can be applicable because >>>>>>>>> the isTopMostWindowUnderMouse state is not changed for these >>>>>>>>> calls. >>>>>>>>> >>>>>>>>> So the window enter/exit events now are always generated from the >>>>>>>>> native system and component enter/exit events are generated in the >>>>>>>>> LWWindowPeer class. >>>>>>>>> >>>>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>>>> case when a mouse is dragged from one window to another the >>>>>>>>> current >>>>>>>>> component receives drag events and last and topmostUnderMouse >>>>>>>>> links >>>>>>>>> handle components mouse exit/enter events on the second window. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>> >>>>> >>> > From konstantin.shefov at oracle.com Tue Aug 28 06:13:08 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Tue, 28 Aug 2012 17:13:08 +0400 Subject: [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test In-Reply-To: <503CBCC9.1040107@oracle.com> References: <503BA04E.6000801@oracle.com> <503CBCC9.1040107@oracle.com> Message-ID: <503CC3E4.7000907@oracle.com> Hi, Anthony See my comments inline On 28.08.2012 16:42, Anthony Petrov wrote: > Hi Konstantin, > > I think you should modify the copyright headers in each file. The > files are no longer proprietary/confidential. .sh and makefiles should > also include a copyright header. Please use existing source files in > the open repository as a template for the header. > > test/java/awt/JAWT/MyCanvas.java >> 52 f.show(); > > Please replace this with f.setVisible(true); > >> 53 robot.delay(10000); > > I think 10 seconds is kind of too long. It might have been relevant > for Java 1.4, but now I think 5 seconds should be pretty much enough > for every modern system. > > test/java/awt/JAWT/JAWT.sh >> 137 case "$OS" in >> 138 Windows* | CYGWIN* ) >> 139 cp ${TESTJAVA}${FS}jre${FS}bin${FS}jawt.dll . >> 140 ;; >> 141 esac > > Why is this necessary? This must be a bug in JDK if the library still > needs to be copied to the current directory on Windows. Could you > verify if the test still works w/o copying the dll? It must, actually. I cannot verify it on JDK 8 (Windows only issue, Solaris and Linux work fine) because on Windows this test compiles only with JDK 1.4.2 fcs b28! Even if I use JDK 1.4.2 u39 b02, I have the following compiler error: link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib Creating library mylib.lib and object mylib.exp myfile.obj : error LNK2019: unresolved external symbol __imp__JAWT_GetAWT at 8 referenced in function _Java_MyCanvas_paint at 12 mylib.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: '"C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\VC\\BIN\\link.EXE"' : return code '0x460' It seems there is no "__imp__JAWT_GetAWT at 8" in jawt.lib since 1.4.2 fcs... > > -- > best regards, > Anthony > > On 8/27/2012 8:29 PM, Konstantin Shefov wrote: >> Hello, >> >> Please review a fix for the issue: >> >> 7190587 Open source and jtreg'ify JAWT regression test >> >> Test was modified in to be run with jtreg. >> >> The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/ >> >> >> Thanks, >> Konstantin >> From anthony.petrov at oracle.com Tue Aug 28 06:46:48 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 28 Aug 2012 17:46:48 +0400 Subject: [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test In-Reply-To: <503CC3E4.7000907@oracle.com> References: <503BA04E.6000801@oracle.com> <503CBCC9.1040107@oracle.com> <503CC3E4.7000907@oracle.com> Message-ID: <503CCBC8.5070907@oracle.com> On 8/28/2012 5:13 PM, Konstantin Shefov wrote: >> Why is this necessary? This must be a bug in JDK if the library still >> needs to be copied to the current directory on Windows. Could you >> verify if the test still works w/o copying the dll? It must, actually. > > I cannot verify it on JDK 8 (Windows only issue, Solaris and Linux work > fine) because on Windows this test compiles only with JDK 1.4.2 fcs b28! > Even if I use JDK 1.4.2 u39 b02, I have the following compiler error: > > link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib > C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib I believe this line causes the error. The linker simply doesn't see the jawt.lib module. Please try using the following name for the module: "C:\jdk\j2sdk1.4.2_39b02\lib\jawt.lib" instead of the current one: "C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib" (note the changes in slashes). I think make and/or cygwin/MKS can mangle the file name. There must be a way to make them return a proper full path name for the file so that the linker could see the module. Actually, I suggest to pass the following option to the linker: -LC:\jdk\j2sdk1.4.2_39b02\lib and list the jawt.lib simply by name together with other .lib's you're linking against. Please try this and see if it works for you. -- best regards, Anthony > Creating library mylib.lib and object mylib.exp > myfile.obj : error LNK2019: unresolved external symbol > __imp__JAWT_GetAWT at 8 referenced in function _Java_MyCanvas_paint at 12 > mylib.dll : fatal error LNK1120: 1 unresolved externals > NMAKE : fatal error U1077: '"C:\\Program Files (x86)\\Microsoft Visual > Studio 11.0\\VC\\BIN\\link.EXE"' : return code '0x460' > > It seems there is no "__imp__JAWT_GetAWT at 8" in jawt.lib since 1.4.2 fcs... > >> >> -- >> best regards, >> Anthony >> >> On 8/27/2012 8:29 PM, Konstantin Shefov wrote: >>> Hello, >>> >>> Please review a fix for the issue: >>> >>> 7190587 Open source and jtreg'ify JAWT regression test >>> >>> Test was modified in to be run with jtreg. >>> >>> The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/ >>> >>> >>> Thanks, >>> Konstantin >>> From Sergey.Bylokhov at oracle.com Tue Aug 28 06:57:46 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 28 Aug 2012 17:57:46 +0400 Subject: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503CA8D7.90506@oracle.com> References: <5020F954.4090203@oracle.com> <5020FD25.7090702@oracle.com> <50251406.6060708@oracle.com> <503616BA.6050007@oracle.com> <50362734.5060600@oracle.com> <50378763.60508@oracle.com> <50379706.1000106@oracle.com> <503CA8D7.90506@oracle.com> Message-ID: <503CCE5A.5080204@oracle.com> Hi Alexander. Fix looks good. 28.08.2012 15:17, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/7171045/webrev.05/ > The comments are below: > - NSTrackingCursorUpdate option is removed from the > rolloverTrackingArea > > On 8/24/2012 7:00 PM, Anthony Petrov wrote: >> src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java >>> 66 public static native CPlatformWindow >>> nativeGetTopmostPlatformWindowUnderMouse(); >> >> This method must probably be private. > Fixed. > >> >> Still, I don't see why getTopmostPlatformWindowUnderMouse() must >> return null when it's invoked on an embedded frame, and why the >> implementation should even be different at all. The mouse is a global >> system entity. There's either some window under the mouse, or there's >> not. I would still think of LWToolkit.getPlatformWindowUnderMouse(), >> and its implementation in LWCToolkit. > > Dmitry, who is a responsible person for the > CPlatformEmbeddedFrame, said that the implementation of the > getPlatformWindowUnderMouse() method could be different for applets. > So the getPlatformWindowUnderMouse() method implementation will > be filled as a separated issue and fixed by Dmitry. > >> >> Also, the logic in LWWindowPeer lines 722-743 seems to be overly >> complicated (as well as the whole dispatchMouseEvent() method). E.g., >> if the LWWindowPeer manages an embedded frame, we get >> topmostWindowPeer == this at line 730, and thus always go through the >> 'true' branch of if() at line 733, even though actually the mouse >> pointer can be located over some other window at the moment (e.g. >> over a popup window opened by an applet). > I updated the topmostWindowPeer variable creation so it now can > have only the topmost window under mouse value or null and added a > comment that the (topmostWindowPeer == null ) > condition should be removed after the > getPlatformWindowUnderMouse() method implementation in the > CPlatformEmbeddedFrame class. > For now the (topmostWindowPeer == null ) condition allows to track > the mouse enter/exit components events as it was before the fix. >> >> Overall, it's really difficult to understand what is going on there. >> I've spent half an hour reading the code and am still not sure if I >> get it right. Why does LWWindowPeer even care about the >> EXITED/ENTERED events for components? Shouldn't this code belong to >> LWComponentPeer? Or even the shared code? How do Swing components in >> regular Swing apps get the ENTERED/EXITED events then? Why can't we >> use the same approach for LWAWT? > Swing controls have Container in a parent class hierarchy. The > Container class has the LightweightDispatcher dispatcher which allows > to track mouse moving from one component to another and generate > necessary mouse enter/exit events. > AWT controls have Component class as a parent and do not have the > dispatcher. So moving/dragging a mouse from one AWT control to another > does not generate necessary mouse events. > > The aim of the fix is not redesigning current architecture. It just > adds checking a case where a mouse is dragged from one window to > another and so the first window which gets the mouse drag events is > not the real window for which component enter/exit events should be > generated. > > Thanks, > Alexandr. > >> >> -- >> best regards, >> Anthony >> >> On 8/24/2012 5:53 PM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/ >>> The comments are below: >>> >>> On 8/23/2012 4:51 PM, Anthony Petrov wrote: >>>> Hi Alexandr, >>>> >>>> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we >>>> iterate through app's windows only once and send both Exited and >>>> Entered events where needed? >>> Now, when we do not care about the order of the mouse enter/exit >>> events generation it is possible to do. I have updated the code. >>>> >>>> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no >>>> longer requires a window pointer as an argument. >>> Fixed. >>>> >>>> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) >>>> should never import C* classes. Instead you should've added a new >>>> method to the PlatformWindow interface, and used it from >>>> LWWindowPeer. The CPlatformWindow should've implemented this >>>> method, and called an appropriate native method from there. In this >>>> case, however, you actually need a static method, so it'd better be >>>> part of the LWToolkit interface, and implemented in the LWCToolkit >>>> class instead. >>> I see. It seems that the getTopmostWindowUnderMouse method >>> implementation is different for the CPlatformWindow and for the >>> CPlatformEmbeddedFrame. >>> So I added the getTopmostPlatformWindowUnderMouse method to the >>> PlatformWindow interface. >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 08/23/12 15:40, Alexander Scherbatiy wrote: >>>>> >>>>> Could someone review the fix? >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/ >>>>>> >>>>>> The comments are below: >>>>>> >>>>>> On 8/7/2012 6:47 PM, Mike Swingler wrote: >>>>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 >>>>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a >>>>>>> simple 32 bit int is probably not what you intended to do. >>>>>> fixed. >>>>>>> Also, have you considered simply calling -[NSWindow >>>>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and >>>>>>> then >>>>>>> removing the calls that flip it on and off in -[AWTView >>>>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also >>>>>>> require a >>>>>>> change in >>>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), >>>>>>> which has a comment that states it only turns on mouse moved events >>>>>>> if the window is currently under the mouse. >>>>>> I tried it. The result that I got is that a dragging mouse from one >>>>>> window to another does not generate mouse enter/exit events on the >>>>>> second window in case when tracking rect is used and the >>>>>> acceptsMouseMovedEvents flag is always set to YES. >>>>>> >>>>>>> I would think that AppKit should be more than happy to send you >>>>>>> mouse-over/enter/exited events as long as you say you want them. >>>>>>> Was >>>>>>> this approach tried and didn't work for some reason? >>>>>>>> Hi, Alexander. >>>>>>>> Probably all this stuff can be simplified? Can you try to change >>>>>>>> TrackingRect to TrackingArea with appropriate flags like >>>>>>>> NSTrackingEnabledDuringMouseDrag etc. >>>>>> I changed the TrackingRect to TrackingArea in the updated fix. It >>>>>> now >>>>>> generates the mouse enter/exit events on the second window during >>>>>> drag. >>>>>> So it is not necessary to generates such events from our side. >>>>>> >>>>>> The getTopmostWindowUnderMouse is necessary to handle mouse >>>>>> enter/exit >>>>>> events for component in case when a mouse is dragged from one window >>>>>> to another. >>>>>> Where the second window contains it's own components and the only >>>>>> way >>>>>> to know about tracking over them are drag events which receives the >>>>>> first window. >>>>>> >>>>>> I think that the LWWindowPeer class code can be simplified if we >>>>>> assume that window mouse enter/exit events are always come to the >>>>>> current window. >>>>>> So the component mouse enter/exit events can be tracked only in the >>>>>> current or topmost window. >>>>>> For this case I separated the global lastCommonMouseEventPeer >>>>>> which is >>>>>> necessary for the cursor manager and the local lastMouseEventPeer. >>>>>> >>>>>> According to the specification: The proper order of mouse-entered >>>>>> and >>>>>> mouse-exited events received by tracking-area objects in an >>>>>> application cannot be guaranteed. >>>>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html >>>>>> >>>>>> >>>>>> So it seems it is not possible to have one lastMouseEventPeer >>>>>> instead >>>>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer. >>>>>> >>>>>> And there are possible situations that we can receive mouse drag >>>>>> event >>>>>> between enter and exit. >>>>>> To handle this the isMouseOver flag is added to the LWWindowPeer >>>>>> class. So the component mouse enter/exit events are not generated if >>>>>> the window mouse exited event is received and window mouse >>>>>> entered is >>>>>> not. >>>>>> >>>>>> There is the test: >>>>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >>>>>> It shows that even using the TrackingArea some mouse enter/exit >>>>>> events >>>>>> are not generateed in the following cases: >>>>>> - window is created under the mouse >>>>>> - window changes it's bounds so it becomes under the mouse >>>>>> >>>>>> For this cases it still necessary to generate mouse enter/exit >>>>>> events >>>>>> from our side. >>>>>> I just moved the related code to one method >>>>>> synthesizeMouseEnteredExitedEventsForAllWindows. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote: >>>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/ >>>>>>>>> >>>>>>>>> This is a regression after the fix 7154048 [macosx] At least drag >>>>>>>>> twice, the toolbar can be dragged to the left side. >>>>>>>>> >>>>>>>>> In the case where a toolbar is created under a mouse and it is >>>>>>>>> dragged over the initial window the mouse enter/exit events >>>>>>>>> should >>>>>>>>> not be generated for the components which are under the toolbar. >>>>>>>>> >>>>>>>>> The current fix is supposed to solve this regression and also to >>>>>>>>> fix generation of mouse enter/exit events for all cases where a >>>>>>>>> mouse is dragged from one window to another or a new window is >>>>>>>>> created under a mouse (like it is implemented for toolbar). >>>>>>>>> >>>>>>>>> Let's see the following cases >>>>>>>>> 1) Mouse is dragged from a window and back to the same window. >>>>>>>>> The Mac OS X system generates a mouse exit event only the first >>>>>>>>> time when a mouse is dragged from a window and does not generate >>>>>>>>> mouse enter/exit events next times during one drag trace. >>>>>>>>> >>>>>>>>> 2) Mouse is dragged from one window to another. >>>>>>>>> The Mac OS X system does not generate mouse enter/exit events for >>>>>>>>> the second window. >>>>>>>>> >>>>>>>>> 3) Mouse is dragged from one window to another and released. >>>>>>>>> In this case the Mac OS X system generates mouse enter event for >>>>>>>>> the second window only after releasing the mouse. >>>>>>>>> >>>>>>>>> 4) Clicking on window creates a new window after that the new >>>>>>>>> window is dragged (toolbar dragging). >>>>>>>>> >>>>>>>>> However the Java system generates mouse enter/exit events each >>>>>>>>> time >>>>>>>>> when a mouse is dragged over any window. >>>>>>>>> >>>>>>>>> To fix this the following methods are introduced: >>>>>>>>> - Get topmost window under mouse >>>>>>>>> - Synthesize mouse enter/exit events for all windows >>>>>>>>> >>>>>>>>> >>>>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is >>>>>>>>> handled previous and next components and is able to generate >>>>>>>>> mouse >>>>>>>>> enter/exit events for them. >>>>>>>>> However the the AWTView native class contains isMouseOver flag >>>>>>>>> which value becomes inconsistent if we do not updated it. Because >>>>>>>>> of this the fix generates the mouse enter/exit window events >>>>>>>>> on the >>>>>>>>> native side. >>>>>>>>> >>>>>>>>> Generating mouse enter/exit events always should be in order >>>>>>>>> where >>>>>>>>> mouse exit events are generated before the mouse enter events. >>>>>>>>> >>>>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method >>>>>>>>> tries to >>>>>>>>> generate mouse enter/exit events for all windows during mouse >>>>>>>>> drag >>>>>>>>> or window creation/window bounds changing. >>>>>>>>> However only those windows which isMouseOver flag is differ from >>>>>>>>> the isTopMostWindowUnderMouse state are affected. >>>>>>>>> This method also tries to generate both mouse enter and exit >>>>>>>>> event >>>>>>>>> for the same window but only one of them can be applicable >>>>>>>>> because >>>>>>>>> the isTopMostWindowUnderMouse state is not changed for these >>>>>>>>> calls. >>>>>>>>> >>>>>>>>> So the window enter/exit events now are always generated from the >>>>>>>>> native system and component enter/exit events are generated in >>>>>>>>> the >>>>>>>>> LWWindowPeer class. >>>>>>>>> >>>>>>>>> LWWindowPeer class now uses three links to components: current, >>>>>>>>> last and topmostUnderMouse. All of them are necessary because in >>>>>>>>> case when a mouse is dragged from one window to another the >>>>>>>>> current >>>>>>>>> component receives drag events and last and topmostUnderMouse >>>>>>>>> links >>>>>>>>> handle components mouse exit/enter events on the second window. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, Sergey. >>>>>>>> >>>>>> >>>>> >>> > -- Best regards, Sergey. From konstantin.shefov at oracle.com Tue Aug 28 07:07:20 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Tue, 28 Aug 2012 18:07:20 +0400 Subject: [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test In-Reply-To: <503CCBC8.5070907@oracle.com> References: <503BA04E.6000801@oracle.com> <503CBCC9.1040107@oracle.com> <503CC3E4.7000907@oracle.com> <503CCBC8.5070907@oracle.com> Message-ID: <503CD098.6040903@oracle.com> No, it is not the case. I checked it before already. As I have said test compiles successfully with JDK 1.4.2b28, so path is OK. I even tried to do as you have said right now (no jtreg, no MKS), and nothing changed as expected. Test passes against jdk 1.4.2b28 and fails against jdk 1.4.2_39b02 and jdk 8b53. LOG 1.4.2 u39 (dll is NOT produced): C:\JTwork\scratch>nmake -f Makefile.win Microsoft (R) Program Maintenance Utility Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. cl -nologo -IC:\jdk\j2sdk1.4.2_39b02\include\win32 -IC:\jdk\j2sdk1.4.2_39b02\include -c myfile.cpp myfile.cpp link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib -LIBPATH:C:\jdk\j2sdk1.4.2_39b02\lib jawt.lib Creating library mylib.lib and object mylib.exp myfile.obj : error LNK2019: unresolved external symbol __imp__JAWT_GetAWT at 8 referenced in function _Java_MyCanvas_paint at 12 mylib.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\link.EXE"' : return code '0x460' Stop. LOG 1.4.2 fcs (no errors, dll is produced): C:\JTwork\scratch>nmake -f Makefile.win Microsoft (R) Program Maintenance Utility Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. cl -nologo -IC:\jdk\j2sdk1.4.2b28\include\win32 -IC:\jdk\j2sdk1.4.2b28\include -c myfile.cpp myfile.cpp link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib -LIBPATH:C:\jdk\j2sdk1.4.2b28\lib jawt.lib Creating library mylib.lib and object mylib.exp LOG 8 b51 (dll is NOT produced): C:\JTwork\scratch>nmake -f Makefile.win Microsoft (R) Program Maintenance Utility Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. cl -nologo -IC:\jdk\jdk1.8.0b51\include\win32 -IC:\jdk\jdk1.8.0b51\include -c myfile.cpp myfile.cpp link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib -LIBPATH:C:\jdk\jdk1.8.0b51\lib jawt.lib Creating library mylib.lib and object mylib.exp myfile.obj : error LNK2019: unresolved external symbol __imp__JAWT_GetAWT at 8 referenced in function _Java_MyCanvas_paint at 12 mylib.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\link.EXE"' : return code '0x460' Stop. On 28.08.2012 17:46, Anthony Petrov wrote: > On 8/28/2012 5:13 PM, Konstantin Shefov wrote: >>> Why is this necessary? This must be a bug in JDK if the library >>> still needs to be copied to the current directory on Windows. Could >>> you verify if the test still works w/o copying the dll? It must, >>> actually. >> >> I cannot verify it on JDK 8 (Windows only issue, Solaris and Linux >> work fine) because on Windows this test compiles only with JDK 1.4.2 >> fcs b28! Even if I use JDK 1.4.2 u39 b02, I have the following >> compiler error: >> >> link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib >> C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib > > I believe this line causes the error. The linker simply doesn't see > the jawt.lib module. Please try using the following name for the module: > > "C:\jdk\j2sdk1.4.2_39b02\lib\jawt.lib" > > instead of the current one: > > "C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib" > > (note the changes in slashes). I think make and/or cygwin/MKS can > mangle the file name. There must be a way to make them return a proper > full path name for the file so that the linker could see the module. > > Actually, I suggest to pass the following option to the linker: > > -LC:\jdk\j2sdk1.4.2_39b02\lib > > and list the jawt.lib simply by name together with other .lib's you're > linking against. > > Please try this and see if it works for you. > > -- > best regards, > Anthony > >> Creating library mylib.lib and object mylib.exp >> myfile.obj : error LNK2019: unresolved external symbol >> __imp__JAWT_GetAWT at 8 referenced in function _Java_MyCanvas_paint at 12 >> mylib.dll : fatal error LNK1120: 1 unresolved externals >> NMAKE : fatal error U1077: '"C:\\Program Files (x86)\\Microsoft >> Visual Studio 11.0\\VC\\BIN\\link.EXE"' : return code '0x460' >> >> It seems there is no "__imp__JAWT_GetAWT at 8" in jawt.lib since 1.4.2 >> fcs... >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 8/27/2012 8:29 PM, Konstantin Shefov wrote: >>>> Hello, >>>> >>>> Please review a fix for the issue: >>>> >>>> 7190587 Open source and jtreg'ify JAWT regression test >>>> >>>> Test was modified in to be run with jtreg. >>>> >>>> The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/ >>>> >>>> >>>> Thanks, >>>> Konstantin >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120828/e91b7340/attachment.html From oleg.pekhovskiy at oracle.com Tue Aug 28 07:33:14 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Tue, 28 Aug 2012 18:33:14 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503263C9.4080206@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> Message-ID: <503CD6AA.5030005@oracle.com> Hi Artem, Anthony, thank you for your proposals! We with Artem also had off-line discussion, so as a result I prepared improved version of fix: http://cr.openjdk.java.net/~bagiras/8/7186109.3/ What was done: 1. EventQueue.detachDispatchThread(): moved SunToolkit.flushPnedingEvents() above the comments and added a separate comment to it. 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to SunToolkit. Deleted SunToolkitSubclass. 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - isThreadLocalFlushing and made it ThreadLocal. 4. Left PostEventQueue.flush() unsynchronized and created wait()-notifyAll() synchronization mechanism to avoid blocking of PostEventQueue.postEvent(). Looking forward to your comments! Thanks, Oleg 20.08.2012 20:20, Artem Ananiev wrote: > Hi, Oleg, > > here are a few comments: > > 1. What is the reason of keeping "isFlushingPendingEvents" in > SunToolkit, given that PEQ.flush() is synchronized (and therefore > serialized) anyway? > > 2. flushPendingEvents(AppContext) may be moved directly to SunToolkit, > so we don't need a separate sun-class for that. > > 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced > by another one. > > Thanks, > > Artem > > On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >> Hi! >> >> Please review the fix for CR: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >> >> Webrev: >> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >> >> The following changes were made: >> 1. Removed flushLock from SunToolkit.flushPendingEvent() >> 2. Returned method PostEventQueue.flush() as 'synchronized' back >> 3. Added call of SunToolkit.flushPendingEvents() to >> EventQueue.detachDispatchThread(), >> right before pushPopLock.lock() >> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >> EventQueue.detachDispatchThread() >> 5. Removed SunToolkit.isPostEventQueueEmpty() & >> PostEventQueue.noEvents(); >> >> Thanks, >> Oleg >> From Sergey.Bylokhov at oracle.com Tue Aug 28 08:23:22 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 28 Aug 2012 19:23:22 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503CD6AA.5030005@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> Message-ID: <503CE26A.9010309@oracle.com> Hi, Oleg. If I'm not missing something, the flush method became asynchronous for some invocations. Because it can returns before flush actually happens. This is expected? 28.08.2012 18:33, Oleg Pekhovskiy wrote: > Hi Artem, Anthony, > > thank you for your proposals! > > We with Artem also had off-line discussion, > so as a result I prepared improved version of fix: > http://cr.openjdk.java.net/~bagiras/8/7186109.3/ > > What was done: > 1. EventQueue.detachDispatchThread(): moved > SunToolkit.flushPnedingEvents() above the comments and added a > separate comment to it. > 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to > SunToolkit. Deleted SunToolkitSubclass. > 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - > isThreadLocalFlushing and made it ThreadLocal. > 4. Left PostEventQueue.flush() unsynchronized and created > wait()-notifyAll() synchronization mechanism to avoid blocking of > PostEventQueue.postEvent(). > > Looking forward to your comments! > > Thanks, > Oleg > > 20.08.2012 20:20, Artem Ananiev wrote: >> Hi, Oleg, >> >> here are a few comments: >> >> 1. What is the reason of keeping "isFlushingPendingEvents" in >> SunToolkit, given that PEQ.flush() is synchronized (and therefore >> serialized) anyway? >> >> 2. flushPendingEvents(AppContext) may be moved directly to >> SunToolkit, so we don't need a separate sun-class for that. >> >> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced >> by another one. >> >> Thanks, >> >> Artem >> >> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>> Hi! >>> >>> Please review the fix for CR: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >>> >>> The following changes were made: >>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>> 3. Added call of SunToolkit.flushPendingEvents() to >>> EventQueue.detachDispatchThread(), >>> right before pushPopLock.lock() >>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >>> EventQueue.detachDispatchThread() >>> 5. Removed SunToolkit.isPostEventQueueEmpty() & >>> PostEventQueue.noEvents(); >>> >>> Thanks, >>> Oleg >>> > > -- Best regards, Sergey. From anton.litvinov at oracle.com Tue Aug 28 09:25:41 2012 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Tue, 28 Aug 2012 20:25:41 +0400 Subject: [7u8] Review request for 7193219: JComboBox serialization fails in JDK 1.7 In-Reply-To: <503B89ED.1020008@oracle.com> References: <5037BB9A.4010905@oracle.com> <503B6CBD.7020109@oracle.com> <503B6E75.8050800@oracle.com> <503B89ED.1020008@oracle.com> Message-ID: <503CF105.5030808@oracle.com> Hello Anthony, Thank you for the review and additional information concerning the process of handling GraphicsConfiguration in AWT package. But I decided to fix this issue from side of Swing package. A corresponding review request was sent to "swing-dev at openjdk.java.net" e-mail alias. Thank you, Anton On 27.08.2012 18:53, Anton Litvinov wrote: > Hello Anthony, > > Thank you for the review. I would like to clarify that this issue is > an escalation. > > After working on this bug I came to a conclusion that a reason of this > bug is the fact that updateGraphicsData() method of not completely > deserialized container is called during deserialization process. In > this case the situation is the following: > 1. readObject() method of JPanel is called. > 1.1. readObject() method of JFrame is called during deserialization of > JPanel's subcomponents, since they depend on JFrame through > PropertyChangeSupport field. > 1.2. initDeserializedWindow of JFrame as java.awt.Window is called and > leads to subsequent calls to updateGraphicsData() of all subcomponents > including that JPanel in step 1, which was not executed completely yet. > Deferring of updateGraphicsData() method could be a solution, but how > can this be done technically? Also is there a guarantee that no logic, > which executes after updateGraphicsData() and before the end of > deserialization, relies on the results of updateGraphicsData() method? > > This issue is reproducible on JDK 8 too, but since it was originally > escalated on JDK 7 it should be fixed on JDK 7 first and then fixed in > JDK 8. > > Concerning a name of a directory containing the test, I am a new > employee and I do not know the exact naming conventions. But before > doing this I searched for existing tests and found many directories > created in 2012 whose names contain bug numbers. I am ready to apply > what ever name is better. I do not think that the test case can be > written without Swing package, because it is related to certain > escalation and I do not have right to change the original test case > provided with escalation significantly. > > Thank you, > Anton > > On 27.08.2012 16:56, Anthony Petrov wrote: >> Also, I suggest to name the test directory/filename with a >> human-readable name (just like all the other tests in AWT area do). >> BTW, since this is an AWT test, do we actually have to use Swing >> there? Can we make it an AWT-only test? >> >> -- >> best regards, >> Anthony >> >> On 08/27/12 16:49, Anthony Petrov wrote: >>> Hi Anton, >>> >>> After deserialization completes, the components in the 'component' >>> collection must all share the same graphics configuration as its parent >>> container (which is being deserialized). While your fix resolves the >>> NPE, it doesn't yet sets up the child components with the correct >>> graphics configuration after the 'component' collection has been >>> populated which children during deserialization. I think we should >>> probably add a deferred call to updateGraphicsData() somewhere at the >>> readObject() method. >>> >>> Also, should this issue be fixed for JDK 8 first, and then ported back >>> to JDK 7u? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 08/24/12 21:36, Anton Litvinov wrote: >>>> Hello, >>>> >>>> Please review the following fix for a bug. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219 >>>> Webrev: http://cr.openjdk.java.net/~alexp/7193219/webrev.00 >>>> >>>> For details on this bug please look at "Evaluation" field on a web >>>> page >>>> of this bug. The provided webrev contains both a fix and a >>>> corresponding >>>> unit-test. Also before publishing this webrev all unit-test from the >>>> "java.awt" and >>>> "javax.swing" swing related to serialization and usage of >>>> "GraphicsConfiguration" class were run and no negative changes were >>>> observed comparing the results of tests' runs on JDK with and without >>>> patch represented by this webrev. >>>> >>>> Thank you, >>>> Anton From anthony.petrov at oracle.com Tue Aug 28 09:37:53 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 28 Aug 2012 20:37:53 +0400 Subject: [7u8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503CC029.20302@oracle.com> References: <503CC029.20302@oracle.com> Message-ID: <503CF3E1.3040308@oracle.com> Hi Alexander, 1. Does the closed/javax/swing/plaf/basic/BasicToolBarUI/4331392/bug4331392.java test (mentioned in 7154048) pass with this fix? 2. What is the plan for DragWindowTest.java? We should either remove it with this fix, or file a CR and remove '@' from the '@run' jtreg tag so that it wouldn't fail for the time being. -- best regards, Anthony On 8/28/2012 4:57 PM, Alexander Scherbatiy wrote: > Hello, > > Please review the fix for the JDK 7u8: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 > webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev7.00/ > > This is a regression after the fix 7154048 [macosx] At least drag twice, > the toolbar can be dragged to the left side. > > In the case where a toolbar is created under a mouse and it is dragged > over the initial window the mouse enter/exit events should not be > generated for the components which are under the toolbar. > The disabling component mouse enter/exit events generation during drag > leads that it does not work in the case where a mouse is dragged over > the current window. > > The full fix that checks that a current window is a topmost window under > mouse requires some changes (using tracking area instead of tracking > rectangle and so on) is a quite complicated and it seems that it is > risky to include it to the JDK 7u8. > > Current fix just changes the condition for the component mouse > enter/exit events generation to the initial state how it was before the > 7154048 fix. > > This allows to generate components mouse enter/exit events, but the > following test will fail: > java/awt/Mouse/EnterExitEvents/DragWindowTest.java > However this test did not work before the 7154048 fix so it is not a > regression. > > > Thanks, > Alexandr. > From anthony.petrov at oracle.com Tue Aug 28 09:44:15 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 28 Aug 2012 20:44:15 +0400 Subject: [7u8] Review request for 7193219: JComboBox serialization fails in JDK 1.7 In-Reply-To: <503CF105.5030808@oracle.com> References: <5037BB9A.4010905@oracle.com> <503B6CBD.7020109@oracle.com> <503B6E75.8050800@oracle.com> <503B89ED.1020008@oracle.com> <503CF105.5030808@oracle.com> Message-ID: <503CF55F.1010509@oracle.com> Thanks. I've reviewed your new fix already. Note that someone else from Swing team must also take a look at it to make sure it's OK. -- best regards, Anthony On 8/28/2012 8:25 PM, Anton Litvinov wrote: > Hello Anthony, > > Thank you for the review and additional information concerning the > process of handling GraphicsConfiguration in AWT package. But I decided > to fix this issue from side of Swing package. A corresponding review > request was sent to "swing-dev at openjdk.java.net" e-mail alias. > > Thank you, > Anton > > On 27.08.2012 18:53, Anton Litvinov wrote: >> Hello Anthony, >> >> Thank you for the review. I would like to clarify that this issue is >> an escalation. >> >> After working on this bug I came to a conclusion that a reason of this >> bug is the fact that updateGraphicsData() method of not completely >> deserialized container is called during deserialization process. In >> this case the situation is the following: >> 1. readObject() method of JPanel is called. >> 1.1. readObject() method of JFrame is called during deserialization of >> JPanel's subcomponents, since they depend on JFrame through >> PropertyChangeSupport field. >> 1.2. initDeserializedWindow of JFrame as java.awt.Window is called and >> leads to subsequent calls to updateGraphicsData() of all subcomponents >> including that JPanel in step 1, which was not executed completely yet. >> Deferring of updateGraphicsData() method could be a solution, but how >> can this be done technically? Also is there a guarantee that no logic, >> which executes after updateGraphicsData() and before the end of >> deserialization, relies on the results of updateGraphicsData() method? >> >> This issue is reproducible on JDK 8 too, but since it was originally >> escalated on JDK 7 it should be fixed on JDK 7 first and then fixed in >> JDK 8. >> >> Concerning a name of a directory containing the test, I am a new >> employee and I do not know the exact naming conventions. But before >> doing this I searched for existing tests and found many directories >> created in 2012 whose names contain bug numbers. I am ready to apply >> what ever name is better. I do not think that the test case can be >> written without Swing package, because it is related to certain >> escalation and I do not have right to change the original test case >> provided with escalation significantly. >> >> Thank you, >> Anton >> >> On 27.08.2012 16:56, Anthony Petrov wrote: >>> Also, I suggest to name the test directory/filename with a >>> human-readable name (just like all the other tests in AWT area do). >>> BTW, since this is an AWT test, do we actually have to use Swing >>> there? Can we make it an AWT-only test? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 08/27/12 16:49, Anthony Petrov wrote: >>>> Hi Anton, >>>> >>>> After deserialization completes, the components in the 'component' >>>> collection must all share the same graphics configuration as its parent >>>> container (which is being deserialized). While your fix resolves the >>>> NPE, it doesn't yet sets up the child components with the correct >>>> graphics configuration after the 'component' collection has been >>>> populated which children during deserialization. I think we should >>>> probably add a deferred call to updateGraphicsData() somewhere at the >>>> readObject() method. >>>> >>>> Also, should this issue be fixed for JDK 8 first, and then ported back >>>> to JDK 7u? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 08/24/12 21:36, Anton Litvinov wrote: >>>>> Hello, >>>>> >>>>> Please review the following fix for a bug. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219 >>>>> Webrev: http://cr.openjdk.java.net/~alexp/7193219/webrev.00 >>>>> >>>>> For details on this bug please look at "Evaluation" field on a web >>>>> page >>>>> of this bug. The provided webrev contains both a fix and a >>>>> corresponding >>>>> unit-test. Also before publishing this webrev all unit-test from the >>>>> "java.awt" and >>>>> "javax.swing" swing related to serialization and usage of >>>>> "GraphicsConfiguration" class were run and no negative changes were >>>>> observed comparing the results of tests' runs on JDK with and without >>>>> patch represented by this webrev. >>>>> >>>>> Thank you, >>>>> Anton From alexandr.scherbatiy at oracle.com Wed Aug 29 02:59:20 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 29 Aug 2012 13:59:20 +0400 Subject: [7u8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503CF3E1.3040308@oracle.com> References: <503CC029.20302@oracle.com> <503CF3E1.3040308@oracle.com> Message-ID: <503DE7F8.2000401@oracle.com> Could you review the updated fix for the JDK 7u8 where the failed test is removed: http://cr.openjdk.java.net/~alexsch/7171045/webrev7.02/ On 8/28/2012 8:37 PM, Anthony Petrov wrote: > Hi Alexander, > > 1. Does the > closed/javax/swing/plaf/basic/BasicToolBarUI/4331392/bug4331392.java > test (mentioned in 7154048) pass with this fix? Yes, the test passes. The fix reverted back changes after the 7154048 fix. http://cr.openjdk.java.net/~alexsch/7154048/webrev7.00/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html > > 2. What is the plan for DragWindowTest.java? We should either remove > it with this fix, or file a CR and remove '@' from the '@run' jtreg > tag so that it wouldn't fail for the time being. I removed the failed DragWindowTest.java from the JDK 7u repository in the updated fix. But it still presents in the JDK 8 repository and passes with the fixed 7154048 and 7171045 issues. Thanks, Alexandr. > > -- > best regards, > Anthony > > On 8/28/2012 4:57 PM, Alexander Scherbatiy wrote: >> Hello, >> >> Please review the fix for the JDK 7u8: >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev7.00/ >> >> This is a regression after the fix 7154048 [macosx] At least drag >> twice, the toolbar can be dragged to the left side. >> >> In the case where a toolbar is created under a mouse and it is >> dragged over the initial window the mouse enter/exit events should >> not be generated for the components which are under the toolbar. >> The disabling component mouse enter/exit events generation during >> drag leads that it does not work in the case where a mouse is dragged >> over the current window. >> >> The full fix that checks that a current window is a topmost window >> under mouse requires some changes (using tracking area instead of >> tracking rectangle and so on) is a quite complicated and it seems >> that it is risky to include it to the JDK 7u8. >> >> Current fix just changes the condition for the component mouse >> enter/exit events generation to the initial state how it was before >> the 7154048 fix. >> >> This allows to generate components mouse enter/exit events, but the >> following test will fail: >> java/awt/Mouse/EnterExitEvents/DragWindowTest.java >> However this test did not work before the 7154048 fix so it is not a >> regression. >> >> >> Thanks, >> Alexandr. >> From anthony.petrov at oracle.com Wed Aug 29 03:03:44 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 29 Aug 2012 14:03:44 +0400 Subject: [7u8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. In-Reply-To: <503DE7F8.2000401@oracle.com> References: <503CC029.20302@oracle.com> <503CF3E1.3040308@oracle.com> <503DE7F8.2000401@oracle.com> Message-ID: <503DE900.1070807@oracle.com> Looks fine. Thanks. -- best regards, Anthony On 8/29/2012 1:59 PM, Alexander Scherbatiy wrote: > > Could you review the updated fix for the JDK 7u8 where the failed test > is removed: > http://cr.openjdk.java.net/~alexsch/7171045/webrev7.02/ > > On 8/28/2012 8:37 PM, Anthony Petrov wrote: >> Hi Alexander, >> >> 1. Does the >> closed/javax/swing/plaf/basic/BasicToolBarUI/4331392/bug4331392.java >> test (mentioned in 7154048) pass with this fix? > Yes, the test passes. The fix reverted back changes after the > 7154048 fix. > > http://cr.openjdk.java.net/~alexsch/7154048/webrev7.00/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html > >> >> 2. What is the plan for DragWindowTest.java? We should either remove >> it with this fix, or file a CR and remove '@' from the '@run' jtreg >> tag so that it wouldn't fail for the time being. > I removed the failed DragWindowTest.java from the JDK 7u repository > in the updated fix. But it still presents in the JDK 8 repository and > passes with the fixed 7154048 and 7171045 issues. > > Thanks, > Alexandr. > >> >> -- >> best regards, >> Anthony >> >> On 8/28/2012 4:57 PM, Alexander Scherbatiy wrote: >>> Hello, >>> >>> Please review the fix for the JDK 7u8: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045 >>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev7.00/ >>> >>> This is a regression after the fix 7154048 [macosx] At least drag >>> twice, the toolbar can be dragged to the left side. >>> >>> In the case where a toolbar is created under a mouse and it is >>> dragged over the initial window the mouse enter/exit events should >>> not be generated for the components which are under the toolbar. >>> The disabling component mouse enter/exit events generation during >>> drag leads that it does not work in the case where a mouse is dragged >>> over the current window. >>> >>> The full fix that checks that a current window is a topmost window >>> under mouse requires some changes (using tracking area instead of >>> tracking rectangle and so on) is a quite complicated and it seems >>> that it is risky to include it to the JDK 7u8. >>> >>> Current fix just changes the condition for the component mouse >>> enter/exit events generation to the initial state how it was before >>> the 7154048 fix. >>> >>> This allows to generate components mouse enter/exit events, but the >>> following test will fail: >>> java/awt/Mouse/EnterExitEvents/DragWindowTest.java >>> However this test did not work before the 7154048 fix so it is not a >>> regression. >>> >>> >>> Thanks, >>> Alexandr. >>> > From anton.tarasov at oracle.com Wed Aug 29 03:48:26 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 29 Aug 2012 14:48:26 +0400 Subject: [8] Review request for 6981400 Tabbing between textfield do not work properly when ALT+TAB In-Reply-To: <4FF5A4F7.7020308@oracle.com> References: <4FF5A290.6040308@oracle.com> <4FF5A4F7.7020308@oracle.com> Message-ID: <503DF37A.9060505@oracle.com> Please look at the updated version: http://cr.openjdk.java.net/~ant/6981400/webrev.6 It contains the following changes: 1. http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.udiff.html Comments updated. 2. http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/java/awt/Component.java.udiff.html The method: ((MouseEvent)currentEvent).getComponent() is called instead of getSource() in order to avoid "instanceof" check for non-component sources. 3. http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/sun/awt/SunToolkit.java.udiff.html AppContext is used to store window deactivation times to guarantee security. 4. http://cr.openjdk.java.net/~ant/6981400/webrev.6/test/java/awt/Focus/6981400/Test1.java.html Focus events order check is suppressed for XToolkit where this functionality can't be implemented due to time-less native focus messages. Thanks, Anton. On 05.07.2012 18:30, Anton V. Tarasov wrote: > [I had to fix the links in the previous e-mail, replaced webrev.4 with webrev.5, sorry] > > Hi, > > Please review a fix for the CR: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6981400 > > Webrev: > > http://cr.openjdk.java.net/~ant/6981400/webrev.5 > > The fix covers a number of issues and is an evaluated version of the fix originally integrated > into jdk6. The scenario which reproduces > the referred problems looks pretty like the following: > > A frame with components. The first component is focused. In its focusLost(..) listener it performs > some lengthy operation. > TAB key is pressed, say, 5 times. The first component loses focus, the lengthy operation begins > which freezes EDT for a while. > At the same time, a user switches to some other window by Alt-TAB and then switches back by > another Alt-TAB. When the lengthy > operation is done, the user expects focus to be transferred through the components in order as if > no toplevel switch has happened. > Alternatively, the toplevel switch could be done by a mouse click in a component of the other java > toplevel and then by a click to the > title of the original frame. > > This may cause the following unexpected results: > > 1) Focus doesn't go through all the 5 components (which 5 TABs should result in) but stops on, > say, the 3rd one. > 2) Components are being transferred in wrong order, say 2, 3, 2, 4, 5, 6 instead of 2, 3, 4, 5, 6. > 3) A menu of the original frame eventually gets activated (reproducible on MS Windows). > > Detailed description of why AWT behaves that way is quite lengthy & tangled. It can be found in > the CR. > Below I'll shortly comment the changes made. (The fix additionally contains changes not directly > related to the 3 problems mentioned above, > but those changes were introduced based on thorough testing with the focus regression test base > and analysing the failures). > > 1. Component.requestFocusHelper(..), Component.dispatchEventImpl(..), Container, Dialog, EventQueue > > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Component.java.sdiff.html > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Container.java.sdiff.html > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Dialog.java.sdiff.html > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/EventQueue.java.sdiff.html > > > A focus request, in order to set a type-ahead marker's time, uses the time stamp of the last > dispatched _key_ event. > A time stamp of a key event, which is put into the type-ahead queue, is not registered until the > event is retrieved from the queue for normal dispatching. > This establishes strong dependence b/w type-ahead markers and the order in which key events are > actually dispatched. > > 2. Component.requestFocusHelper(..) > > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Component.java.sdiff.html > > As the comments say, a focus request following a mouse event is forced to be "in-window" focus > requests. This is to make sure it won't re-activate the window > in case the window is inactive by the time the request takes its turn for processing. This type of > deferred side effect of the mouse event may not be correctly > processed under "tough" conditions and should be dropped. > > 3. LWComponentPeer, LWWindowPeer > > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWComponentPeer.java.sdiff.html > > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html > > > A simple (not Frame/Dialog) window or an active but not focused Frame/Dialog should request window > focus by mouse click right on dispatching of the mouse event > on the platform side, not after the event made the "platform -> java -> platform" cycle. > > 4. LWWindowPeer.dispatchKeyEvent(..) > > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html > > > This is actually a fix for 7157015 (which I'll close later). The bug affects behavior and troubles > testing of the whole fix, so I'm including this code as dependent. > > 5. XBaseWindow, XComponentPeer > > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/solaris/classes/sun/awt/X11/XBaseWindow.java.sdiff.html > > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/solaris/classes/sun/awt/X11/XComponentPeer.java.sdiff.html > > > Similarly to (3), but for X11 implementation. Additionally, "actualFocusedWindow" reference, which > is the most recent focused owned simple window, is reset because > a click in an owned window should deliver focus to that window, not to the most recently focused one. > > 6. DefaultKeyboardFocusManager.repostIfFollowsKeyEvents(..) > > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/DefaultKeyboardFocusManager.java.sdiff.html > > > (The change originally suggested by Oleg Pekhovskiy) Toplevel window focus events > (WINDOW_GAINED_FOCUS/WINDOW_LOST_FOCUS) should not be processed > until the type-ahead queue, populated before the event of switching toplevel windows actually > happened, is empty. The only we can do here is to repost the toplevel focus > events to the end of the EDT queue. > > 7. KeyboardFocusManagerPeerImpl > > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java.sdiff.html > > > The calls: > > SunToolkit.postPriorityEvent(fl); > > were originally wrong. This is an artefact of an old fix (5028014) that has been rolled out, but > went into jdk7 (with 6806217) by a mistake. > The focus events should not be sent in prioritized order here. > > 8. TimedWindowEvent > > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/TimedWindowEvent.java.html > > A WindowEvent with a time stamp. > > 9. SunToolkit > > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/SunToolkit.java.sdiff.html > > WINDOW_LOST_FOCUS event's time stamp is registered. > > 10. WindowsRootPaneUI > > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.sdiff.html > > > Skip menu activating events which weren't processed in time (while the containing toplevel window > is active). > > 11. awt_Window.cpp > > http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/windows/native/sun/windows/awt_Window.cpp.sdiff.html > > > Window focus events are supplied with a time stamp. > > - - - > Thanks, > Anton. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120829/eec5f772/attachment.html From leonid.romanov at oracle.com Wed Aug 29 03:51:37 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 29 Aug 2012 14:51:37 +0400 Subject: [8] Review request for 6981400 Tabbing between textfield do not work properly when ALT+TAB In-Reply-To: <503DF37A.9060505@oracle.com> References: <4FF5A290.6040308@oracle.com> <4FF5A4F7.7020308@oracle.com> <503DF37A.9060505@oracle.com> Message-ID: <001901cd85d4$448f10c0$cdad3240$@oracle.com> Looks OK. From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] Sent: Wednesday, August 29, 2012 2:48 PM To: AWT-DEV Mailing List Cc: Artem Ananiev; Leonid Romanov Subject: Re: [8] Review request for 6981400 Tabbing between textfield do not work properly when ALT+TAB Please look at the updated version: http://cr.openjdk.java.net/~ant/6981400/webrev.6 It contains the following changes: 1. http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.udiff.html Comments updated. 2. http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/java/awt/Component.java.udiff.html The method: ((MouseEvent)currentEvent).getComponent() is called instead of getSource() in order to avoid "instanceof" check for non-component sources. 3. http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/sun/awt/SunToolkit.java.udiff.html AppContext is used to store window deactivation times to guarantee security. 4. http://cr.openjdk.java.net/~ant/6981400/webrev.6/test/java/awt/Focus/6981400/Test1.java.html Focus events order check is suppressed for XToolkit where this functionality can't be implemented due to time-less native focus messages. Thanks, Anton. On 05.07.2012 18:30, Anton V. Tarasov wrote: [I had to fix the links in the previous e-mail, replaced webrev.4 with webrev.5, sorry] Hi, Please review a fix for the CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6981400 Webrev: http://cr.openjdk.java.net/~ant/6981400/webrev.5 The fix covers a number of issues and is an evaluated version of the fix originally integrated into jdk6. The scenario which reproduces the referred problems looks pretty like the following: A frame with components. The first component is focused. In its focusLost(..) listener it performs some lengthy operation. TAB key is pressed, say, 5 times. The first component loses focus, the lengthy operation begins which freezes EDT for a while. At the same time, a user switches to some other window by Alt-TAB and then switches back by another Alt-TAB. When the lengthy operation is done, the user expects focus to be transferred through the components in order as if no toplevel switch has happened. Alternatively, the toplevel switch could be done by a mouse click in a component of the other java toplevel and then by a click to the title of the original frame. This may cause the following unexpected results: 1) Focus doesn't go through all the 5 components (which 5 TABs should result in) but stops on, say, the 3rd one. 2) Components are being transferred in wrong order, say 2, 3, 2, 4, 5, 6 instead of 2, 3, 4, 5, 6. 3) A menu of the original frame eventually gets activated (reproducible on MS Windows). Detailed description of why AWT behaves that way is quite lengthy & tangled. It can be found in the CR. Below I'll shortly comment the changes made. (The fix additionally contains changes not directly related to the 3 problems mentioned above, but those changes were introduced based on thorough testing with the focus regression test base and analysing the failures). 1. Component.requestFocusHelper(..), Component.dispatchEventImpl(..), Container, Dialog, EventQueue http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Component.java.sdiff.html http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Container.java.sdiff.html http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Dialog.java.sdiff.html http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/EventQueue.java.sdiff.html A focus request, in order to set a type-ahead marker's time, uses the time stamp of the last dispatched _key_ event. A time stamp of a key event, which is put into the type-ahead queue, is not registered until the event is retrieved from the queue for normal dispatching. This establishes strong dependence b/w type-ahead markers and the order in which key events are actually dispatched. 2. Component.requestFocusHelper(..) http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Component.java.sdiff.html As the comments say, a focus request following a mouse event is forced to be "in-window" focus requests. This is to make sure it won't re-activate the window in case the window is inactive by the time the request takes its turn for processing. This type of deferred side effect of the mouse event may not be correctly processed under "tough" conditions and should be dropped. 3. LWComponentPeer, LWWindowPeer http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWComponentPeer.java.sdiff.html http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html A simple (not Frame/Dialog) window or an active but not focused Frame/Dialog should request window focus by mouse click right on dispatching of the mouse event on the platform side, not after the event made the "platform -> java -> platform" cycle. 4. LWWindowPeer.dispatchKeyEvent(..) http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html This is actually a fix for 7157015 (which I'll close later). The bug affects behavior and troubles testing of the whole fix, so I'm including this code as dependent. 5. XBaseWindow, XComponentPeer http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/solaris/classes/sun/awt/X11/XBaseWindow.java.sdiff.html http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/solaris/classes/sun/awt/X11/XComponentPeer.java.sdiff.html Similarly to (3), but for X11 implementation. Additionally, "actualFocusedWindow" reference, which is the most recent focused owned simple window, is reset because a click in an owned window should deliver focus to that window, not to the most recently focused one. 6. DefaultKeyboardFocusManager.repostIfFollowsKeyEvents(..) http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/DefaultKeyboardFocusManager.java.sdiff.html (The change originally suggested by Oleg Pekhovskiy) Toplevel window focus events (WINDOW_GAINED_FOCUS/WINDOW_LOST_FOCUS) should not be processed until the type-ahead queue, populated before the event of switching toplevel windows actually happened, is empty. The only we can do here is to repost the toplevel focus events to the end of the EDT queue. 7. KeyboardFocusManagerPeerImpl http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java.sdiff.html The calls: SunToolkit.postPriorityEvent(fl); were originally wrong. This is an artefact of an old fix (5028014) that has been rolled out, but went into jdk7 (with 6806217) by a mistake. The focus events should not be sent in prioritized order here. 8. TimedWindowEvent http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/TimedWindowEvent.java.html A WindowEvent with a time stamp. 9. SunToolkit http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/SunToolkit.java.sdiff.html WINDOW_LOST_FOCUS event's time stamp is registered. 10. WindowsRootPaneUI http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.sdiff.html Skip menu activating events which weren't processed in time (while the containing toplevel window is active). 11. awt_Window.cpp http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/windows/native/sun/windows/awt_Window.cpp.sdiff.html Window focus events are supplied with a time stamp. - - - Thanks, Anton. From anthony.petrov at oracle.com Wed Aug 29 04:08:52 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 29 Aug 2012 15:08:52 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503CD6AA.5030005@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> Message-ID: <503DF844.302@oracle.com> Hi Oleg, I'm still concerned about the following: detachDispatchThread() { flush(); lock(); // possibly detach unlock(); } at EventQueue.java. What if an even get posted to the queue after the flush() returns but before we even acquired the lock? We may still end up with a situation when we detach the thread while in fact there are some pending events present, which actually contradicts the current logic of the detach() method. I see that you say "Minimize discard possibility" in the comment instead of "Prevent ...", but I feel uncomfortable with this actually. What exactly prevents us from adding some synchronization to ensure that the detaching only happens when there's really no pending events? SunToolkit.java: > 2120 Boolean b = isThreadLocalFlushing.get(); > 2121 if (b != null && b) { > 2122 return; > 2123 } > 2124 > 2125 isThreadLocalFlushing.set(true); > 2126 try { How does access to the isThreadLocalFlushing synchronized? What happens if the flush() is being invoked from two different threads for the same post event queue? Why do we have two "isFlushing" flags? Can we collapse them into one? Why is the isFlushing set/reset in two disjunct synchronized(){} blocks? Overall, I find the current synchronization scheme in flush() very, *very* (and I mean it) confusing. Can we simplify it somehow? -- best regards, Anthony On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: > Hi Artem, Anthony, > > thank you for your proposals! > > We with Artem also had off-line discussion, > so as a result I prepared improved version of fix: > http://cr.openjdk.java.net/~bagiras/8/7186109.3/ > > What was done: > 1. EventQueue.detachDispatchThread(): moved > SunToolkit.flushPnedingEvents() above the comments and added a separate > comment to it. > 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to > SunToolkit. Deleted SunToolkitSubclass. > 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - > isThreadLocalFlushing and made it ThreadLocal. > 4. Left PostEventQueue.flush() unsynchronized and created > wait()-notifyAll() synchronization mechanism to avoid blocking of > PostEventQueue.postEvent(). > > Looking forward to your comments! > > Thanks, > Oleg > > 20.08.2012 20:20, Artem Ananiev wrote: >> Hi, Oleg, >> >> here are a few comments: >> >> 1. What is the reason of keeping "isFlushingPendingEvents" in >> SunToolkit, given that PEQ.flush() is synchronized (and therefore >> serialized) anyway? >> >> 2. flushPendingEvents(AppContext) may be moved directly to SunToolkit, >> so we don't need a separate sun-class for that. >> >> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced >> by another one. >> >> Thanks, >> >> Artem >> >> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>> Hi! >>> >>> Please review the fix for CR: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >>> >>> The following changes were made: >>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>> 3. Added call of SunToolkit.flushPendingEvents() to >>> EventQueue.detachDispatchThread(), >>> right before pushPopLock.lock() >>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >>> EventQueue.detachDispatchThread() >>> 5. Removed SunToolkit.isPostEventQueueEmpty() & >>> PostEventQueue.noEvents(); >>> >>> Thanks, >>> Oleg >>> > > From anthony.petrov at oracle.com Wed Aug 29 04:22:18 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 29 Aug 2012 15:22:18 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503DF844.302@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> <503DF844.302@oracle.com> Message-ID: <503DFB6A.6020209@oracle.com> On 8/29/2012 3:08 PM, Anthony Petrov wrote: > Hi Oleg, > > I'm still concerned about the following: > > detachDispatchThread() > { > flush(); > lock(); > // possibly detach > unlock(); > } > > at EventQueue.java. What if an even get posted to the queue after the A typo: s/even get/event gets/. -- best regards, Anthony > flush() returns but before we even acquired the lock? We may still end > up with a situation when we detach the thread while in fact there are > some pending events present, which actually contradicts the current > logic of the detach() method. I see that you say "Minimize discard > possibility" in the comment instead of "Prevent ...", but I feel > uncomfortable with this actually. > > What exactly prevents us from adding some synchronization to ensure that > the detaching only happens when there's really no pending events? > > SunToolkit.java: >> 2120 Boolean b = isThreadLocalFlushing.get(); >> 2121 if (b != null && b) { >> 2122 return; >> 2123 } >> 2124 2125 isThreadLocalFlushing.set(true); >> 2126 try { > > How does access to the isThreadLocalFlushing synchronized? What happens > if the flush() is being invoked from two different threads for the same > post event queue? Why do we have two "isFlushing" flags? Can we collapse > them into one? Why is the isFlushing set/reset in two disjunct > synchronized(){} blocks? > > Overall, I find the current synchronization scheme in flush() very, > *very* (and I mean it) confusing. Can we simplify it somehow? > > -- > best regards, > Anthony > > On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: >> Hi Artem, Anthony, >> >> thank you for your proposals! >> >> We with Artem also had off-line discussion, >> so as a result I prepared improved version of fix: >> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ >> >> What was done: >> 1. EventQueue.detachDispatchThread(): moved >> SunToolkit.flushPnedingEvents() above the comments and added a >> separate comment to it. >> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to >> SunToolkit. Deleted SunToolkitSubclass. >> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - >> isThreadLocalFlushing and made it ThreadLocal. >> 4. Left PostEventQueue.flush() unsynchronized and created >> wait()-notifyAll() synchronization mechanism to avoid blocking of >> PostEventQueue.postEvent(). >> >> Looking forward to your comments! >> >> Thanks, >> Oleg >> >> 20.08.2012 20:20, Artem Ananiev wrote: >>> Hi, Oleg, >>> >>> here are a few comments: >>> >>> 1. What is the reason of keeping "isFlushingPendingEvents" in >>> SunToolkit, given that PEQ.flush() is synchronized (and therefore >>> serialized) anyway? >>> >>> 2. flushPendingEvents(AppContext) may be moved directly to >>> SunToolkit, so we don't need a separate sun-class for that. >>> >>> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced >>> by another one. >>> >>> Thanks, >>> >>> Artem >>> >>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>>> Hi! >>>> >>>> Please review the fix for CR: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >>>> >>>> The following changes were made: >>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>>> 3. Added call of SunToolkit.flushPendingEvents() to >>>> EventQueue.detachDispatchThread(), >>>> right before pushPopLock.lock() >>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >>>> EventQueue.detachDispatchThread() >>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & >>>> PostEventQueue.noEvents(); >>>> >>>> Thanks, >>>> Oleg >>>> >> >> From konstantin.shefov at oracle.com Wed Aug 29 04:28:36 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 29 Aug 2012 15:28:36 +0400 Subject: [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test In-Reply-To: <503CCBC8.5070907@oracle.com> References: <503BA04E.6000801@oracle.com> <503CBCC9.1040107@oracle.com> <503CC3E4.7000907@oracle.com> <503CCBC8.5070907@oracle.com> Message-ID: <503DFCE4.7060202@oracle.com> Please, review new webrev: http://cr.openjdk.java.net/~kshefov/7190587/webrev.01/ On 28.08.2012 17:46, Anthony Petrov wrote: > On 8/28/2012 5:13 PM, Konstantin Shefov wrote: >>> Why is this necessary? This must be a bug in JDK if the library >>> still needs to be copied to the current directory on Windows. Could >>> you verify if the test still works w/o copying the dll? It must, >>> actually. >> >> I cannot verify it on JDK 8 (Windows only issue, Solaris and Linux >> work fine) because on Windows this test compiles only with JDK 1.4.2 >> fcs b28! Even if I use JDK 1.4.2 u39 b02, I have the following >> compiler error: >> >> link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib >> C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib > > I believe this line causes the error. The linker simply doesn't see > the jawt.lib module. Please try using the following name for the module: > > "C:\jdk\j2sdk1.4.2_39b02\lib\jawt.lib" > > instead of the current one: > > "C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib" > > (note the changes in slashes). I think make and/or cygwin/MKS can > mangle the file name. There must be a way to make them return a proper > full path name for the file so that the linker could see the module. > > Actually, I suggest to pass the following option to the linker: > > -LC:\jdk\j2sdk1.4.2_39b02\lib > > and list the jawt.lib simply by name together with other .lib's you're > linking against. > > Please try this and see if it works for you. > > -- > best regards, > Anthony > >> Creating library mylib.lib and object mylib.exp >> myfile.obj : error LNK2019: unresolved external symbol >> __imp__JAWT_GetAWT at 8 referenced in function _Java_MyCanvas_paint at 12 >> mylib.dll : fatal error LNK1120: 1 unresolved externals >> NMAKE : fatal error U1077: '"C:\\Program Files (x86)\\Microsoft >> Visual Studio 11.0\\VC\\BIN\\link.EXE"' : return code '0x460' >> >> It seems there is no "__imp__JAWT_GetAWT at 8" in jawt.lib since 1.4.2 >> fcs... >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 8/27/2012 8:29 PM, Konstantin Shefov wrote: >>>> Hello, >>>> >>>> Please review a fix for the issue: >>>> >>>> 7190587 Open source and jtreg'ify JAWT regression test >>>> >>>> Test was modified in to be run with jtreg. >>>> >>>> The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/ >>>> >>>> >>>> Thanks, >>>> Konstantin >>>> From anthony.petrov at oracle.com Wed Aug 29 04:33:58 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 29 Aug 2012 15:33:58 +0400 Subject: [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test In-Reply-To: <503DFCE4.7060202@oracle.com> References: <503BA04E.6000801@oracle.com> <503CBCC9.1040107@oracle.com> <503CC3E4.7000907@oracle.com> <503CCBC8.5070907@oracle.com> <503DFCE4.7060202@oracle.com> Message-ID: <503DFE26.6090205@oracle.com> The fix looks fine to me. Thank you. -- best regards, Anthony On 8/29/2012 3:28 PM, Konstantin Shefov wrote: > Please, review new webrev: > http://cr.openjdk.java.net/~kshefov/7190587/webrev.01/ > > > On 28.08.2012 17:46, Anthony Petrov wrote: >> On 8/28/2012 5:13 PM, Konstantin Shefov wrote: >>>> Why is this necessary? This must be a bug in JDK if the library >>>> still needs to be copied to the current directory on Windows. Could >>>> you verify if the test still works w/o copying the dll? It must, >>>> actually. >>> >>> I cannot verify it on JDK 8 (Windows only issue, Solaris and Linux >>> work fine) because on Windows this test compiles only with JDK 1.4.2 >>> fcs b28! Even if I use JDK 1.4.2 u39 b02, I have the following >>> compiler error: >>> >>> link -nologo -dll -out:mylib.dll myfile.obj gdi32.lib user32.lib >>> C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib >> >> I believe this line causes the error. The linker simply doesn't see >> the jawt.lib module. Please try using the following name for the module: >> >> "C:\jdk\j2sdk1.4.2_39b02\lib\jawt.lib" >> >> instead of the current one: >> >> "C:/jdk/j2sdk1.4.2_39b02\\lib\\jawt.lib" >> >> (note the changes in slashes). I think make and/or cygwin/MKS can >> mangle the file name. There must be a way to make them return a proper >> full path name for the file so that the linker could see the module. >> >> Actually, I suggest to pass the following option to the linker: >> >> -LC:\jdk\j2sdk1.4.2_39b02\lib >> >> and list the jawt.lib simply by name together with other .lib's you're >> linking against. >> >> Please try this and see if it works for you. >> >> -- >> best regards, >> Anthony >> >>> Creating library mylib.lib and object mylib.exp >>> myfile.obj : error LNK2019: unresolved external symbol >>> __imp__JAWT_GetAWT at 8 referenced in function _Java_MyCanvas_paint at 12 >>> mylib.dll : fatal error LNK1120: 1 unresolved externals >>> NMAKE : fatal error U1077: '"C:\\Program Files (x86)\\Microsoft >>> Visual Studio 11.0\\VC\\BIN\\link.EXE"' : return code '0x460' >>> >>> It seems there is no "__imp__JAWT_GetAWT at 8" in jawt.lib since 1.4.2 >>> fcs... >>> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 8/27/2012 8:29 PM, Konstantin Shefov wrote: >>>>> Hello, >>>>> >>>>> Please review a fix for the issue: >>>>> >>>>> 7190587 Open source and jtreg'ify JAWT regression test >>>>> >>>>> Test was modified in to be run with jtreg. >>>>> >>>>> The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/ >>>>> >>>>> >>>>> Thanks, >>>>> Konstantin >>>>> From david.holmes at oracle.com Wed Aug 29 04:45:45 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Aug 2012 21:45:45 +1000 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503DF844.302@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> <503DF844.302@oracle.com> Message-ID: <503E00E9.7060104@oracle.com> Hi Anthony, I took a look at the last incarnation of this so let me see if I can follow the new scheme. On 29/08/2012 9:08 PM, Anthony Petrov wrote: > Hi Oleg, > > I'm still concerned about the following: > > detachDispatchThread() > { > flush(); > lock(); > // possibly detach > unlock(); > } > > at EventQueue.java. What if an even get posted to the queue after the > flush() returns but before we even acquired the lock? We may still end > up with a situation when we detach the thread while in fact there are > some pending events present, which actually contradicts the current > logic of the detach() method. I see that you say "Minimize discard > possibility" in the comment instead of "Prevent ...", but I feel > uncomfortable with this actually. If a new event is posted before the lock() then within the locked region won't peekEvent() see it and so avoid the detach? > What exactly prevents us from adding some synchronization to ensure that > the detaching only happens when there's really no pending events? > > SunToolkit.java: >> 2120 Boolean b = isThreadLocalFlushing.get(); >> 2121 if (b != null && b) { >> 2122 return; >> 2123 } >> 2124 2125 isThreadLocalFlushing.set(true); >> 2126 try { > > How does access to the isThreadLocalFlushing synchronized? What happens > if the flush() is being invoked from two different threads for the same > post event queue? Why do we have two "isFlushing" flags? Can we collapse > them into one? Why is the isFlushing set/reset in two disjunct > synchronized(){} blocks? isThreadLocalFlushing is a ThreadLocal so no synchronization is needed. I presume it is used to prevent re-entrant/recursive calls to flush() when calling postEvent. The isFlushing variable is the global flag to coordinate flushing across multiple threads. It has to be set and cleared in synchronized blocks, but the synchronization lock has to be dropped when calling postEvent to avoid deadlocks. So a thread acquires the lock and checks if flushing is in progress, and if so it waits. Else/then it updates isFlushing to indicate if that thread is doing flushing and releases the lock. It then does any flushing needed, reacquires the lock, sets isFlushing to false and notifies any other threads who may be waiting. > Overall, I find the current synchronization scheme in flush() very, > *very* (and I mean it) confusing. Can we simplify it somehow? This seems like a reasonable protocol to coordinate multiple flushers whilst dropping the synchronization lock when posting events. The actual coordination might be simpler to understand if expressed using a Semaphore - but I think the semantics would be the same. David > -- > best regards, > Anthony > > On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: >> Hi Artem, Anthony, >> >> thank you for your proposals! >> >> We with Artem also had off-line discussion, >> so as a result I prepared improved version of fix: >> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ >> >> What was done: >> 1. EventQueue.detachDispatchThread(): moved >> SunToolkit.flushPnedingEvents() above the comments and added a >> separate comment to it. >> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to >> SunToolkit. Deleted SunToolkitSubclass. >> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - >> isThreadLocalFlushing and made it ThreadLocal. >> 4. Left PostEventQueue.flush() unsynchronized and created >> wait()-notifyAll() synchronization mechanism to avoid blocking of >> PostEventQueue.postEvent(). >> >> Looking forward to your comments! >> >> Thanks, >> Oleg >> >> 20.08.2012 20:20, Artem Ananiev wrote: >>> Hi, Oleg, >>> >>> here are a few comments: >>> >>> 1. What is the reason of keeping "isFlushingPendingEvents" in >>> SunToolkit, given that PEQ.flush() is synchronized (and therefore >>> serialized) anyway? >>> >>> 2. flushPendingEvents(AppContext) may be moved directly to >>> SunToolkit, so we don't need a separate sun-class for that. >>> >>> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced >>> by another one. >>> >>> Thanks, >>> >>> Artem >>> >>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>>> Hi! >>>> >>>> Please review the fix for CR: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >>>> >>>> The following changes were made: >>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>>> 3. Added call of SunToolkit.flushPendingEvents() to >>>> EventQueue.detachDispatchThread(), >>>> right before pushPopLock.lock() >>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >>>> EventQueue.detachDispatchThread() >>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & >>>> PostEventQueue.noEvents(); >>>> >>>> Thanks, >>>> Oleg >>>> >> >> From alexandr.scherbatiy at oracle.com Wed Aug 29 04:49:31 2012 From: alexandr.scherbatiy at oracle.com (alexandr.scherbatiy at oracle.com) Date: Wed, 29 Aug 2012 11:49:31 +0000 Subject: hg: jdk8/awt/jdk: 7171045: [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. Message-ID: <20120829114950.75559477AC@hg.openjdk.java.net> Changeset: e23311e924b1 Author: alexsch Date: 2012-08-29 15:54 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e23311e924b1 7171045: [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag. Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTView.h ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m From anthony.petrov at oracle.com Wed Aug 29 05:02:09 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 29 Aug 2012 16:02:09 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503E00E9.7060104@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> <503DF844.302@oracle.com> <503E00E9.7060104@oracle.com> Message-ID: <503E04C1.8060408@oracle.com> Hi David, On 8/29/2012 3:45 PM, David Holmes wrote: > I took a look at the last incarnation of this so let me see if I can > follow the new scheme. > > On 29/08/2012 9:08 PM, Anthony Petrov wrote: >> Hi Oleg, >> >> I'm still concerned about the following: >> >> detachDispatchThread() >> { >> flush(); >> lock(); >> // possibly detach >> unlock(); >> } >> >> at EventQueue.java. What if an even get posted to the queue after the >> flush() returns but before we even acquired the lock? We may still end >> up with a situation when we detach the thread while in fact there are >> some pending events present, which actually contradicts the current >> logic of the detach() method. I see that you say "Minimize discard >> possibility" in the comment instead of "Prevent ...", but I feel >> uncomfortable with this actually. > > If a new event is posted before the lock() then within the locked region > won't peekEvent() see it and so avoid the detach? peekEvent() checks the event queue only, while the posted event may be stuck in the PostEventQueue. The flushPendingEvents() actually posts the events from the PostEventQueue to the EventQueue. >> What exactly prevents us from adding some synchronization to ensure that >> the detaching only happens when there's really no pending events? >> >> SunToolkit.java: >>> 2120 Boolean b = isThreadLocalFlushing.get(); >>> 2121 if (b != null && b) { >>> 2122 return; >>> 2123 } >>> 2124 2125 isThreadLocalFlushing.set(true); >>> 2126 try { >> >> How does access to the isThreadLocalFlushing synchronized? What happens >> if the flush() is being invoked from two different threads for the same >> post event queue? Why do we have two "isFlushing" flags? Can we collapse >> them into one? Why is the isFlushing set/reset in two disjunct >> synchronized(){} blocks? > > isThreadLocalFlushing is a ThreadLocal so no synchronization is needed. > I presume it is used to prevent re-entrant/recursive calls to flush() > when calling postEvent. > > The isFlushing variable is the global flag to coordinate flushing across > multiple threads. It has to be set and cleared in synchronized blocks, > but the synchronization lock has to be dropped when calling postEvent to > avoid deadlocks. So a thread acquires the lock and checks if flushing is > in progress, and if so it waits. Else/then it updates isFlushing to > indicate if that thread is doing flushing and releases the lock. It then > does any flushing needed, reacquires the lock, sets isFlushing to false > and notifies any other threads who may be waiting. > >> Overall, I find the current synchronization scheme in flush() very, >> *very* (and I mean it) confusing. Can we simplify it somehow? > > This seems like a reasonable protocol to coordinate multiple flushers > whilst dropping the synchronization lock when posting events. The actual > coordination might be simpler to understand if expressed using a > Semaphore - but I think the semantics would be the same. Ah, I see. Thanks for the insight. It now looks much clearer. I think that the final isThreadLocalFlushing.set(false); must be in the finally{} block, though. -- best regards, Anthony > > David > >> -- >> best regards, >> Anthony >> >> On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: >>> Hi Artem, Anthony, >>> >>> thank you for your proposals! >>> >>> We with Artem also had off-line discussion, >>> so as a result I prepared improved version of fix: >>> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ >>> >>> What was done: >>> 1. EventQueue.detachDispatchThread(): moved >>> SunToolkit.flushPnedingEvents() above the comments and added a >>> separate comment to it. >>> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to >>> SunToolkit. Deleted SunToolkitSubclass. >>> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - >>> isThreadLocalFlushing and made it ThreadLocal. >>> 4. Left PostEventQueue.flush() unsynchronized and created >>> wait()-notifyAll() synchronization mechanism to avoid blocking of >>> PostEventQueue.postEvent(). >>> >>> Looking forward to your comments! >>> >>> Thanks, >>> Oleg >>> >>> 20.08.2012 20:20, Artem Ananiev wrote: >>>> Hi, Oleg, >>>> >>>> here are a few comments: >>>> >>>> 1. What is the reason of keeping "isFlushingPendingEvents" in >>>> SunToolkit, given that PEQ.flush() is synchronized (and therefore >>>> serialized) anyway? >>>> >>>> 2. flushPendingEvents(AppContext) may be moved directly to >>>> SunToolkit, so we don't need a separate sun-class for that. >>>> >>>> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced >>>> by another one. >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>>>> Hi! >>>>> >>>>> Please review the fix for CR: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >>>>> >>>>> The following changes were made: >>>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>>>> 3. Added call of SunToolkit.flushPendingEvents() to >>>>> EventQueue.detachDispatchThread(), >>>>> right before pushPopLock.lock() >>>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >>>>> EventQueue.detachDispatchThread() >>>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & >>>>> PostEventQueue.noEvents(); >>>>> >>>>> Thanks, >>>>> Oleg >>>>> >>> >>> From david.holmes at oracle.com Wed Aug 29 05:12:39 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Aug 2012 22:12:39 +1000 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503E04C1.8060408@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> <503DF844.302@oracle.com> <503E00E9.7060104@oracle.com> <503E04C1.8060408@oracle.com> Message-ID: <503E0737.1040209@oracle.com> > Ah, I see. Thanks for the insight. It now looks much clearer. I think > that the final isThreadLocalFlushing.set(false); must be in the > finally{} block, though. Right! Also there is a problem with the InterruptedException handling. Let thread A set isFlushing and be busy flushing. Then let Thread B call wait() but be interrupted. Thread B will enter the finally block grab the lock and set isFlushing to false, even though Thread A is actively flushing! We don't want the finally block to execute if InterruptedException is caught. David On 29/08/2012 10:02 PM, Anthony Petrov wrote: > Hi David, > > On 8/29/2012 3:45 PM, David Holmes wrote: >> I took a look at the last incarnation of this so let me see if I can >> follow the new scheme. >> >> On 29/08/2012 9:08 PM, Anthony Petrov wrote: >>> Hi Oleg, >>> >>> I'm still concerned about the following: >>> >>> detachDispatchThread() >>> { >>> flush(); >>> lock(); >>> // possibly detach >>> unlock(); >>> } >>> >>> at EventQueue.java. What if an even get posted to the queue after the >>> flush() returns but before we even acquired the lock? We may still end >>> up with a situation when we detach the thread while in fact there are >>> some pending events present, which actually contradicts the current >>> logic of the detach() method. I see that you say "Minimize discard >>> possibility" in the comment instead of "Prevent ...", but I feel >>> uncomfortable with this actually. >> >> If a new event is posted before the lock() then within the locked >> region won't peekEvent() see it and so avoid the detach? > > peekEvent() checks the event queue only, while the posted event may be > stuck in the PostEventQueue. The flushPendingEvents() actually posts the > events from the PostEventQueue to the EventQueue. > > >>> What exactly prevents us from adding some synchronization to ensure that >>> the detaching only happens when there's really no pending events? >>> >>> SunToolkit.java: >>>> 2120 Boolean b = isThreadLocalFlushing.get(); >>>> 2121 if (b != null && b) { >>>> 2122 return; >>>> 2123 } >>>> 2124 2125 isThreadLocalFlushing.set(true); >>>> 2126 try { >>> >>> How does access to the isThreadLocalFlushing synchronized? What happens >>> if the flush() is being invoked from two different threads for the same >>> post event queue? Why do we have two "isFlushing" flags? Can we collapse >>> them into one? Why is the isFlushing set/reset in two disjunct >>> synchronized(){} blocks? >> >> isThreadLocalFlushing is a ThreadLocal so no synchronization is >> needed. I presume it is used to prevent re-entrant/recursive calls to >> flush() when calling postEvent. >> >> The isFlushing variable is the global flag to coordinate flushing >> across multiple threads. It has to be set and cleared in synchronized >> blocks, but the synchronization lock has to be dropped when calling >> postEvent to avoid deadlocks. So a thread acquires the lock and checks >> if flushing is in progress, and if so it waits. Else/then it updates >> isFlushing to indicate if that thread is doing flushing and releases >> the lock. It then does any flushing needed, reacquires the lock, sets >> isFlushing to false and notifies any other threads who may be waiting. >> >>> Overall, I find the current synchronization scheme in flush() very, >>> *very* (and I mean it) confusing. Can we simplify it somehow? >> >> This seems like a reasonable protocol to coordinate multiple flushers >> whilst dropping the synchronization lock when posting events. The >> actual coordination might be simpler to understand if expressed using >> a Semaphore - but I think the semantics would be the same. > > Ah, I see. Thanks for the insight. It now looks much clearer. I think > that the final isThreadLocalFlushing.set(false); must be in the > finally{} block, though. > > -- > best regards, > Anthony > > >> >> David >> >>> -- >>> best regards, >>> Anthony >>> >>> On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: >>>> Hi Artem, Anthony, >>>> >>>> thank you for your proposals! >>>> >>>> We with Artem also had off-line discussion, >>>> so as a result I prepared improved version of fix: >>>> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ >>>> >>>> What was done: >>>> 1. EventQueue.detachDispatchThread(): moved >>>> SunToolkit.flushPnedingEvents() above the comments and added a >>>> separate comment to it. >>>> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to >>>> SunToolkit. Deleted SunToolkitSubclass. >>>> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - >>>> isThreadLocalFlushing and made it ThreadLocal. >>>> 4. Left PostEventQueue.flush() unsynchronized and created >>>> wait()-notifyAll() synchronization mechanism to avoid blocking of >>>> PostEventQueue.postEvent(). >>>> >>>> Looking forward to your comments! >>>> >>>> Thanks, >>>> Oleg >>>> >>>> 20.08.2012 20:20, Artem Ananiev wrote: >>>>> Hi, Oleg, >>>>> >>>>> here are a few comments: >>>>> >>>>> 1. What is the reason of keeping "isFlushingPendingEvents" in >>>>> SunToolkit, given that PEQ.flush() is synchronized (and therefore >>>>> serialized) anyway? >>>>> >>>>> 2. flushPendingEvents(AppContext) may be moved directly to >>>>> SunToolkit, so we don't need a separate sun-class for that. >>>>> >>>>> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced >>>>> by another one. >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>>>>> Hi! >>>>>> >>>>>> Please review the fix for CR: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >>>>>> >>>>>> The following changes were made: >>>>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>>>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>>>>> 3. Added call of SunToolkit.flushPendingEvents() to >>>>>> EventQueue.detachDispatchThread(), >>>>>> right before pushPopLock.lock() >>>>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >>>>>> EventQueue.detachDispatchThread() >>>>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & >>>>>> PostEventQueue.noEvents(); >>>>>> >>>>>> Thanks, >>>>>> Oleg >>>>>> >>>> >>>> From alexander.zuev at oracle.com Wed Aug 29 08:54:29 2012 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Wed, 29 Aug 2012 15:54:29 +0000 Subject: hg: jdk8/awt/jdk: 7124375: [macosx] Focus isn't transfered as expected between components Message-ID: <20120829155449.468AA477BB@hg.openjdk.java.net> Changeset: 9201b1df64e6 Author: leonidr Date: 2012-08-29 19:53 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9201b1df64e6 7124375: [macosx] Focus isn't transfered as expected between components Reviewed-by: art, ant, serb ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWKeyboardFocusManagerPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java ! src/share/classes/sun/awt/HToolkit.java ! src/share/classes/sun/awt/HeadlessToolkit.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerProvider.java ! src/share/classes/sun/awt/SunToolkit.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XDialogPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/windows/classes/sun/awt/windows/WKeyboardFocusManagerPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java From omajid at redhat.com Wed Aug 29 09:22:35 2012 From: omajid at redhat.com (Omair Majid) Date: Wed, 29 Aug 2012 12:22:35 -0400 Subject: [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test In-Reply-To: <503BA04E.6000801@oracle.com> References: <503BA04E.6000801@oracle.com> Message-ID: <503E41CB.5090204@redhat.com> Hi, On 08/27/2012 12:29 PM, Konstantin Shefov wrote: > Please review a fix for the issue: > > 7190587 Open source and jtreg'ify JAWT regression test > > Test was modified in to be run with jtreg. > > The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/ Is this the test case I was referred to earlier [1] ? I notice that it exports LD_LIBRARY_PATH before executing the jawt-using program. This would have missed a regression (bug 7190813 [2]). Can we avoid exporting LD_LIBRARY_PATH? Thanks, Omair [1] http://mail.openjdk.java.net/pipermail/build-dev/2012-August/006612.html [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7190813 From konstantin.shefov at oracle.com Wed Aug 29 09:43:48 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 29 Aug 2012 20:43:48 +0400 Subject: [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test In-Reply-To: <503E41CB.5090204@redhat.com> References: <503BA04E.6000801@oracle.com> <503E41CB.5090204@redhat.com> Message-ID: <503E46C4.2050002@oracle.com> Hi, Omair I can remove path to libjawt.so from LD_LIBRARY_PATH, but I have to leave working dir in it, i.e. export LD_LIBRARY_PATH="." Without it test cannot find libmylib.so in working directory. - Konstantin On 29.08.2012 20:22, Omair Majid wrote: > Hi, > > On 08/27/2012 12:29 PM, Konstantin Shefov wrote: >> Please review a fix for the issue: >> >> 7190587 Open source and jtreg'ify JAWT regression test >> >> Test was modified in to be run with jtreg. >> >> The webrev is http://cr.openjdk.java.net/~kshefov/7190587/webrev.00/ > Is this the test case I was referred to earlier [1] ? I notice that it > exports LD_LIBRARY_PATH before executing the jawt-using program. This > would have missed a regression (bug 7190813 [2]). Can we avoid exporting > LD_LIBRARY_PATH? > > Thanks, > Omair > > [1] http://mail.openjdk.java.net/pipermail/build-dev/2012-August/006612.html > [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7190813 From omajid at redhat.com Wed Aug 29 09:47:05 2012 From: omajid at redhat.com (Omair Majid) Date: Wed, 29 Aug 2012 12:47:05 -0400 Subject: [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test In-Reply-To: <503E46C4.2050002@oracle.com> References: <503BA04E.6000801@oracle.com> <503E41CB.5090204@redhat.com> <503E46C4.2050002@oracle.com> Message-ID: <503E4789.9020704@redhat.com> Hi Konstantin, On 08/29/2012 12:43 PM, Konstantin Shefov wrote: > I can remove path to libjawt.so from LD_LIBRARY_PATH, but I have to > leave working dir in it, i.e. > export LD_LIBRARY_PATH="." > Without it test cannot find libmylib.so in working directory. > Oh, of course. I somehow thought the test used an explicit path to libmylib.so. I would be perfectly happy if libjawt.so was removed from LD_LIBRARY_PATH. Thanks, Omair From konstantin.shefov at oracle.com Wed Aug 29 10:15:12 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Wed, 29 Aug 2012 21:15:12 +0400 Subject: [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test In-Reply-To: <503E4789.9020704@redhat.com> References: <503BA04E.6000801@oracle.com> <503E41CB.5090204@redhat.com> <503E46C4.2050002@oracle.com> <503E4789.9020704@redhat.com> Message-ID: <503E4E20.5000001@oracle.com> Here is updated webrev: http://cr.openjdk.java.net/~kshefov/7190587/webrev.02/ On 29.08.2012 20:47, Omair Majid wrote: > Hi Konstantin, > > On 08/29/2012 12:43 PM, Konstantin Shefov wrote: >> I can remove path to libjawt.so from LD_LIBRARY_PATH, but I have to >> leave working dir in it, i.e. >> export LD_LIBRARY_PATH="." >> Without it test cannot find libmylib.so in working directory. >> > Oh, of course. I somehow thought the test used an explicit path to > libmylib.so. I would be perfectly happy if libjawt.so was removed from > LD_LIBRARY_PATH. > > Thanks, > Omair -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120829/7544e567/attachment.html From kelly.ohair at oracle.com Wed Aug 29 10:15:56 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 29 Aug 2012 10:15:56 -0700 Subject: Objective-C and jcheck In-Reply-To: <503CAA06.6040007@oracle.com> References: <20120502135351.B9985470E9@hg.openjdk.java.net> <503CAA06.6040007@oracle.com> Message-ID: <786DB09E-3B55-4796-ACAD-04D548D2F878@oracle.com> CC John Coomes... First, the jcheck script contains: normext_re = re.compile(".*\.(java|c|h|cpp|hpp)$") I don't understand how you are getting this error, it isn't checking *.m files. Did something change? Second, it was my understanding that additions of Objective-C source code into the JDK was going to be very very limited. The more Objective-C code we add, the fewer developers we will have to fix issues with it. Not everyone is skilled at Objective-C. I understand we need to bridge a little, but I really hope it is limited and very well documented. -kto On Aug 28, 2012, at 4:22 AM, Sergey Bylokhov wrote: > Hi Everybody. > Looks like on the server we still use jcheck without fix for Objective-C files? Does anybody know how to apply the fix to jdk8? (see attachment) > > [jdk] > pulling from http://hg.openjdk.java.net/jdk8/awt/jdk > searching for changes > adding changesets > adding manifests > adding file changes > added 1 changesets with 10 changes to 10 files > [jcheck 25e85a608db1 2011-07-08 09:19 -0700] > > > Changeset: 5305:0fad89bd606b > > Author: alexsch > > Date: 2012-05-02 17:54 > > > > 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left > side > > Reviewed-by: anthony, leonidr > > src/macosx/native/sun/awt/AWTView.m:84: Trailing whitespace > src/macosx/native/sun/awt/AWTWindow.m:173: Trailing whitespace > > transaction abort! > rollback completed > skipped: pretxnchangegroup.jcheck hook failed > > 02.05.2012 17:53, alexandr.scherbatiy at oracle.com wrote >> Changeset: 0fad89bd606b >> Author: alexsch >> Date: 2012-05-02 17:54 +0400 >> URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0fad89bd606b >> >> 7154048: [macosx] At least drag twice, the toolbar can be dragged to the left side >> Reviewed-by: anthony, leonidr >> >> ! src/macosx/classes/sun/lwawt/LWWindowPeer.java >> ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java >> ! src/macosx/native/sun/awt/AWTView.h >> ! src/macosx/native/sun/awt/AWTView.m >> ! src/macosx/native/sun/awt/AWTWindow.h >> ! src/macosx/native/sun/awt/AWTWindow.m >> + test/java/awt/Mouse/EnterExitEvents/DragWindowOutOfFrameTest.java >> + test/java/awt/Mouse/EnterExitEvents/DragWindowTest.java >> + test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java >> ! test/java/awt/regtesthelpers/Util.java >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120829/3b448e9f/attachment.html From denis.fokin at oracle.com Wed Aug 29 10:23:55 2012 From: denis.fokin at oracle.com (denis.fokin at oracle.com) Date: Wed, 29 Aug 2012 17:23:55 +0000 Subject: hg: jdk8/awt/jdk: 7192887: java/awt/Window/Grab/GrabTest.java still failed (fix failed for CR 7149068) Message-ID: <20120829172407.27F56477BF@hg.openjdk.java.net> Changeset: 63d52eb20ce2 Author: denis Date: 2012-08-30 01:17 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/63d52eb20ce2 7192887: java/awt/Window/Grab/GrabTest.java still failed (fix failed for CR 7149068) Reviewed-by: ant, serb ! src/solaris/classes/sun/awt/X11/XWindowPeer.java From omajid at redhat.com Wed Aug 29 10:26:47 2012 From: omajid at redhat.com (Omair Majid) Date: Wed, 29 Aug 2012 13:26:47 -0400 Subject: [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test In-Reply-To: <503E4E20.5000001@oracle.com> References: <503BA04E.6000801@oracle.com> <503E41CB.5090204@redhat.com> <503E46C4.2050002@oracle.com> <503E4789.9020704@redhat.com> <503E4E20.5000001@oracle.com> Message-ID: <503E50D7.7020302@redhat.com> On 08/29/2012 01:15 PM, Konstantin Shefov wrote: > Here is updated webrev: > http://cr.openjdk.java.net/~kshefov/7190587/webrev.02/ > Thanks, that resolves my concerns! Cheers, Omair From oleg.pekhovskiy at oracle.com Wed Aug 29 13:18:38 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 30 Aug 2012 00:18:38 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503DFB6A.6020209@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> <503DF844.302@oracle.com> <503DFB6A.6020209@oracle.com> Message-ID: <503E791E.90207@oracle.com> Hi Anthony, I see your concerns. As PostEventQueue.flush() method left unsynchronized, we potentially could return PostEventQueue.noEvents() and return check in EventQueue.detachDispatchThread() back to the condition. But is could increase the possibility of deadlock in future (with PostEventQueue & pushPopLock). Artem, what do you think? Thanks, Oleg 29.08.2012 15:22, Anthony Petrov wrote: > On 8/29/2012 3:08 PM, Anthony Petrov wrote: >> Hi Oleg, >> >> I'm still concerned about the following: >> >> detachDispatchThread() >> { >> flush(); >> lock(); >> // possibly detach >> unlock(); >> } >> >> at EventQueue.java. What if an even get posted to the queue after the > > A typo: s/even get/event gets/. > > -- > best regards, > Anthony > >> flush() returns but before we even acquired the lock? We may still >> end up with a situation when we detach the thread while in fact there >> are some pending events present, which actually contradicts the >> current logic of the detach() method. I see that you say "Minimize >> discard possibility" in the comment instead of "Prevent ...", but I >> feel uncomfortable with this actually. >> >> What exactly prevents us from adding some synchronization to ensure >> that the detaching only happens when there's really no pending events? >> >> SunToolkit.java: >>> 2120 Boolean b = isThreadLocalFlushing.get(); >>> 2121 if (b != null && b) { >>> 2122 return; >>> 2123 } >>> 2124 2125 isThreadLocalFlushing.set(true); >>> 2126 try { >> >> How does access to the isThreadLocalFlushing synchronized? What >> happens if the flush() is being invoked from two different threads >> for the same post event queue? Why do we have two "isFlushing" flags? >> Can we collapse them into one? Why is the isFlushing set/reset in two >> disjunct synchronized(){} blocks? >> >> Overall, I find the current synchronization scheme in flush() very, >> *very* (and I mean it) confusing. Can we simplify it somehow? >> >> -- >> best regards, >> Anthony >> >> On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: >>> Hi Artem, Anthony, >>> >>> thank you for your proposals! >>> >>> We with Artem also had off-line discussion, >>> so as a result I prepared improved version of fix: >>> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ >>> >>> What was done: >>> 1. EventQueue.detachDispatchThread(): moved >>> SunToolkit.flushPnedingEvents() above the comments and added a >>> separate comment to it. >>> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to >>> SunToolkit. Deleted SunToolkitSubclass. >>> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name >>> - isThreadLocalFlushing and made it ThreadLocal. >>> 4. Left PostEventQueue.flush() unsynchronized and created >>> wait()-notifyAll() synchronization mechanism to avoid blocking of >>> PostEventQueue.postEvent(). >>> >>> Looking forward to your comments! >>> >>> Thanks, >>> Oleg >>> >>> 20.08.2012 20:20, Artem Ananiev wrote: >>>> Hi, Oleg, >>>> >>>> here are a few comments: >>>> >>>> 1. What is the reason of keeping "isFlushingPendingEvents" in >>>> SunToolkit, given that PEQ.flush() is synchronized (and therefore >>>> serialized) anyway? >>>> >>>> 2. flushPendingEvents(AppContext) may be moved directly to >>>> SunToolkit, so we don't need a separate sun-class for that. >>>> >>>> 3. EQ.java:1035-1040 - this comment is obsolete and must be >>>> replaced by another one. >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>>>> Hi! >>>>> >>>>> Please review the fix for CR: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >>>>> >>>>> The following changes were made: >>>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>>>> 3. Added call of SunToolkit.flushPendingEvents() to >>>>> EventQueue.detachDispatchThread(), >>>>> right before pushPopLock.lock() >>>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >>>>> EventQueue.detachDispatchThread() >>>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & >>>>> PostEventQueue.noEvents(); >>>>> >>>>> Thanks, >>>>> Oleg >>>>> >>> >>> From oleg.pekhovskiy at oracle.com Wed Aug 29 14:34:43 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 30 Aug 2012 01:34:43 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503E0737.1040209@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> <503DF844.302@oracle.com> <503E00E9.7060104@oracle.com> <503E04C1.8060408@oracle.com> <503E0737.1040209@oracle.com> Message-ID: <503E8AF3.6090001@oracle.com> Anthony, David, thank you for the review! Your comments are reasonable, I'll try to apply them both. Thanks, Oleg 29.08.2012 16:12, David Holmes wrote: > > Ah, I see. Thanks for the insight. It now looks much clearer. I think > > that the final isThreadLocalFlushing.set(false); must be in the > > finally{} block, though. > > Right! > > Also there is a problem with the InterruptedException handling. Let > thread A set isFlushing and be busy flushing. Then let Thread B call > wait() but be interrupted. Thread B will enter the finally block grab > the lock and set isFlushing to false, even though Thread A is actively > flushing! We don't want the finally block to execute if > InterruptedException is caught. > > David > > On 29/08/2012 10:02 PM, Anthony Petrov wrote: >> Hi David, >> >> On 8/29/2012 3:45 PM, David Holmes wrote: >>> I took a look at the last incarnation of this so let me see if I can >>> follow the new scheme. >>> >>> On 29/08/2012 9:08 PM, Anthony Petrov wrote: >>>> Hi Oleg, >>>> >>>> I'm still concerned about the following: >>>> >>>> detachDispatchThread() >>>> { >>>> flush(); >>>> lock(); >>>> // possibly detach >>>> unlock(); >>>> } >>>> >>>> at EventQueue.java. What if an even get posted to the queue after the >>>> flush() returns but before we even acquired the lock? We may still end >>>> up with a situation when we detach the thread while in fact there are >>>> some pending events present, which actually contradicts the current >>>> logic of the detach() method. I see that you say "Minimize discard >>>> possibility" in the comment instead of "Prevent ...", but I feel >>>> uncomfortable with this actually. >>> >>> If a new event is posted before the lock() then within the locked >>> region won't peekEvent() see it and so avoid the detach? >> >> peekEvent() checks the event queue only, while the posted event may be >> stuck in the PostEventQueue. The flushPendingEvents() actually posts the >> events from the PostEventQueue to the EventQueue. >> >> >>>> What exactly prevents us from adding some synchronization to ensure >>>> that >>>> the detaching only happens when there's really no pending events? >>>> >>>> SunToolkit.java: >>>>> 2120 Boolean b = isThreadLocalFlushing.get(); >>>>> 2121 if (b != null && b) { >>>>> 2122 return; >>>>> 2123 } >>>>> 2124 2125 isThreadLocalFlushing.set(true); >>>>> 2126 try { >>>> >>>> How does access to the isThreadLocalFlushing synchronized? What >>>> happens >>>> if the flush() is being invoked from two different threads for the >>>> same >>>> post event queue? Why do we have two "isFlushing" flags? Can we >>>> collapse >>>> them into one? Why is the isFlushing set/reset in two disjunct >>>> synchronized(){} blocks? >>> >>> isThreadLocalFlushing is a ThreadLocal so no synchronization is >>> needed. I presume it is used to prevent re-entrant/recursive calls to >>> flush() when calling postEvent. >>> >>> The isFlushing variable is the global flag to coordinate flushing >>> across multiple threads. It has to be set and cleared in synchronized >>> blocks, but the synchronization lock has to be dropped when calling >>> postEvent to avoid deadlocks. So a thread acquires the lock and checks >>> if flushing is in progress, and if so it waits. Else/then it updates >>> isFlushing to indicate if that thread is doing flushing and releases >>> the lock. It then does any flushing needed, reacquires the lock, sets >>> isFlushing to false and notifies any other threads who may be waiting. >>> >>>> Overall, I find the current synchronization scheme in flush() very, >>>> *very* (and I mean it) confusing. Can we simplify it somehow? >>> >>> This seems like a reasonable protocol to coordinate multiple flushers >>> whilst dropping the synchronization lock when posting events. The >>> actual coordination might be simpler to understand if expressed using >>> a Semaphore - but I think the semantics would be the same. >> >> Ah, I see. Thanks for the insight. It now looks much clearer. I think >> that the final isThreadLocalFlushing.set(false); must be in the >> finally{} block, though. >> >> -- >> best regards, >> Anthony >> >> >>> >>> David >>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: >>>>> Hi Artem, Anthony, >>>>> >>>>> thank you for your proposals! >>>>> >>>>> We with Artem also had off-line discussion, >>>>> so as a result I prepared improved version of fix: >>>>> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ >>>>> >>>>> What was done: >>>>> 1. EventQueue.detachDispatchThread(): moved >>>>> SunToolkit.flushPnedingEvents() above the comments and added a >>>>> separate comment to it. >>>>> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to >>>>> SunToolkit. Deleted SunToolkitSubclass. >>>>> 3. Moved isFlushingPendingEvents to PostEventQueue with the new >>>>> name - >>>>> isThreadLocalFlushing and made it ThreadLocal. >>>>> 4. Left PostEventQueue.flush() unsynchronized and created >>>>> wait()-notifyAll() synchronization mechanism to avoid blocking of >>>>> PostEventQueue.postEvent(). >>>>> >>>>> Looking forward to your comments! >>>>> >>>>> Thanks, >>>>> Oleg >>>>> >>>>> 20.08.2012 20:20, Artem Ananiev wrote: >>>>>> Hi, Oleg, >>>>>> >>>>>> here are a few comments: >>>>>> >>>>>> 1. What is the reason of keeping "isFlushingPendingEvents" in >>>>>> SunToolkit, given that PEQ.flush() is synchronized (and therefore >>>>>> serialized) anyway? >>>>>> >>>>>> 2. flushPendingEvents(AppContext) may be moved directly to >>>>>> SunToolkit, so we don't need a separate sun-class for that. >>>>>> >>>>>> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced >>>>>> by another one. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>>>>>> Hi! >>>>>>> >>>>>>> Please review the fix for CR: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >>>>>>> >>>>>>> The following changes were made: >>>>>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>>>>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>>>>>> 3. Added call of SunToolkit.flushPendingEvents() to >>>>>>> EventQueue.detachDispatchThread(), >>>>>>> right before pushPopLock.lock() >>>>>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >>>>>>> EventQueue.detachDispatchThread() >>>>>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & >>>>>>> PostEventQueue.noEvents(); >>>>>>> >>>>>>> Thanks, >>>>>>> Oleg >>>>>>> >>>>> >>>>> From artem.ananiev at oracle.com Thu Aug 30 03:54:17 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 30 Aug 2012 14:54:17 +0400 Subject: [8] Review request for 6981400 Tabbing between textfield do not work properly when ALT+TAB In-Reply-To: <503DF37A.9060505@oracle.com> References: <4FF5A290.6040308@oracle.com> <4FF5A4F7.7020308@oracle.com> <503DF37A.9060505@oracle.com> Message-ID: <503F4659.1050508@oracle.com> Approved. Thanks, Artem On 8/29/2012 2:48 PM, Anton V. Tarasov wrote: > Please look at the updated version: > > http://cr.openjdk.java.net/~ant/6981400/webrev.6 > > It contains the following changes: > > 1. > http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.udiff.html > > Comments updated. > > 2. > http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/java/awt/Component.java.udiff.html > > The method: > > ((MouseEvent)currentEvent).getComponent() > > > is called instead of getSource() in order to avoid "instanceof" check > for non-component sources. > > 3. > http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/sun/awt/SunToolkit.java.udiff.html > > AppContext is used to store window deactivation times to guarantee security. > > 4. > http://cr.openjdk.java.net/~ant/6981400/webrev.6/test/java/awt/Focus/6981400/Test1.java.html > > Focus events order check is suppressed for XToolkit where this > functionality can't be implemented due to time-less native focus messages. > > Thanks, > Anton. > > On 05.07.2012 18:30, Anton V. Tarasov wrote: >> [I had to fix the links in the previous e-mail, replaced webrev.4 with >> webrev.5, sorry] >> >> Hi, >> >> Please review a fix for the CR: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6981400 >> >> Webrev: >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5 >> >> The fix covers a number of issues and is an evaluated version of the >> fix originally integrated into jdk6. The scenario which reproduces >> the referred problems looks pretty like the following: >> >> A frame with components. The first component is focused. In its >> focusLost(..) listener it performs some lengthy operation. >> TAB key is pressed, say, 5 times. The first component loses focus, the >> lengthy operation begins which freezes EDT for a while. >> At the same time, a user switches to some other window by Alt-TAB and >> then switches back by another Alt-TAB. When the lengthy >> operation is done, the user expects focus to be transferred through >> the components in order as if no toplevel switch has happened. >> Alternatively, the toplevel switch could be done by a mouse click in a >> component of the other java toplevel and then by a click to the >> title of the original frame. >> >> This may cause the following unexpected results: >> >> 1) Focus doesn't go through all the 5 components (which 5 TABs should >> result in) but stops on, say, the 3rd one. >> 2) Components are being transferred in wrong order, say 2, 3, 2, 4, 5, >> 6 instead of 2, 3, 4, 5, 6. >> 3) A menu of the original frame eventually gets activated >> (reproducible on MS Windows). >> >> Detailed description of why AWT behaves that way is quite lengthy & >> tangled. It can be found in the CR. >> Below I'll shortly comment the changes made. (The fix additionally >> contains changes not directly related to the 3 problems mentioned above, >> but those changes were introduced based on thorough testing with the >> focus regression test base and analysing the failures). >> >> 1. Component.requestFocusHelper(..), Component.dispatchEventImpl(..), >> Container, Dialog, EventQueue >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Component.java.sdiff.html >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Container.java.sdiff.html >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Dialog.java.sdiff.html >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/EventQueue.java.sdiff.html >> >> >> A focus request, in order to set a type-ahead marker's time, uses the >> time stamp of the last dispatched _key_ event. >> A time stamp of a key event, which is put into the type-ahead queue, >> is not registered until the event is retrieved from the queue for >> normal dispatching. >> This establishes strong dependence b/w type-ahead markers and the >> order in which key events are actually dispatched. >> >> 2. Component.requestFocusHelper(..) >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Component.java.sdiff.html >> >> >> As the comments say, a focus request following a mouse event is forced >> to be "in-window" focus requests. This is to make sure it won't >> re-activate the window >> in case the window is inactive by the time the request takes its turn >> for processing. This type of deferred side effect of the mouse event >> may not be correctly >> processed under "tough" conditions and should be dropped. >> >> 3. LWComponentPeer, LWWindowPeer >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWComponentPeer.java.sdiff.html >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html >> >> >> A simple (not Frame/Dialog) window or an active but not focused >> Frame/Dialog should request window focus by mouse click right on >> dispatching of the mouse event >> on the platform side, not after the event made the "platform -> java >> -> platform" cycle. >> >> 4. LWWindowPeer.dispatchKeyEvent(..) >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html >> >> >> This is actually a fix for 7157015 (which I'll close later). The bug >> affects behavior and troubles testing of the whole fix, so I'm >> including this code as dependent. >> >> 5. XBaseWindow, XComponentPeer >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/solaris/classes/sun/awt/X11/XBaseWindow.java.sdiff.html >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/solaris/classes/sun/awt/X11/XComponentPeer.java.sdiff.html >> >> >> Similarly to (3), but for X11 implementation. Additionally, >> "actualFocusedWindow" reference, which is the most recent focused >> owned simple window, is reset because >> a click in an owned window should deliver focus to that window, not to >> the most recently focused one. >> >> 6. DefaultKeyboardFocusManager.repostIfFollowsKeyEvents(..) >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/DefaultKeyboardFocusManager.java.sdiff.html >> >> >> (The change originally suggested by Oleg Pekhovskiy) Toplevel window >> focus events (WINDOW_GAINED_FOCUS/WINDOW_LOST_FOCUS) should not be >> processed >> until the type-ahead queue, populated before the event of switching >> toplevel windows actually happened, is empty. The only we can do here >> is to repost the toplevel focus >> events to the end of the EDT queue. >> >> 7. KeyboardFocusManagerPeerImpl >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java.sdiff.html >> >> >> The calls: >> >> SunToolkit.postPriorityEvent(fl); >> >> were originally wrong. This is an artefact of an old fix (5028014) >> that has been rolled out, but went into jdk7 (with 6806217) by a mistake. >> The focus events should not be sent in prioritized order here. >> >> 8. TimedWindowEvent >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/TimedWindowEvent.java.html >> >> >> A WindowEvent with a time stamp. >> >> 9. SunToolkit >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/SunToolkit.java.sdiff.html >> >> >> WINDOW_LOST_FOCUS event's time stamp is registered. >> >> 10. WindowsRootPaneUI >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.sdiff.html >> >> >> Skip menu activating events which weren't processed in time (while the >> containing toplevel window is active). >> >> 11. awt_Window.cpp >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/windows/native/sun/windows/awt_Window.cpp.sdiff.html >> >> >> Window focus events are supplied with a time stamp. >> >> - - - >> Thanks, >> Anton. >> > From artem.ananiev at oracle.com Thu Aug 30 05:42:00 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 30 Aug 2012 16:42:00 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503DF844.302@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> <503DF844.302@oracle.com> Message-ID: <503F5F98.4020207@oracle.com> Hi, Anthony, On 8/29/2012 3:08 PM, Anthony Petrov wrote: > Hi Oleg, > > I'm still concerned about the following: > > detachDispatchThread() > { > flush(); > lock(); > // possibly detach > unlock(); > } > > at EventQueue.java. What if an even get posted to the queue after the > flush() returns but before we even acquired the lock? We may still end > up with a situation when we detach the thread while in fact there are > some pending events present, which actually contradicts the current > logic of the detach() method. I see that you say "Minimize discard > possibility" in the comment instead of "Prevent ...", but I feel > uncomfortable with this actually. yes, this is a known issue: we don't guarantee that no new events are posted between flush() and lock(). If this happens, we'll re-create event dispatch thread. > What exactly prevents us from adding some synchronization to ensure that > the detaching only happens when there's really no pending events? As Oleg wrote, this is exactly the deadlock we're trying to resolve. EQ.detachDispatchThread() was the only place where the order of locks was pushPopLock->flushLock, while in other cases we flush events without pushPopLock. > SunToolkit.java: >> 2120 Boolean b = isThreadLocalFlushing.get(); >> 2121 if (b != null && b) { >> 2122 return; >> 2123 } >> 2124 2125 isThreadLocalFlushing.set(true); >> 2126 try { > > How does access to the isThreadLocalFlushing synchronized? What happens > if the flush() is being invoked from two different threads for the same > post event queue? Why do we have two "isFlushing" flags? Can we collapse > them into one? Why is the isFlushing set/reset in two disjunct > synchronized(){} blocks? As David correctly wrote, isThreadLocalFlushing is a ThreadLocal object, which is thread-safe. isFlushing is used to synchronize access from multiple threads, isThreadLockFlushing is to prevent EQ.postEvent() to be called recursively. The only valid comment is that isThreadLocalFlushing should be set to false in the "finally" block. Oleg will include this change into the next version of the fix. > Overall, I find the current synchronization scheme in flush() very, > *very* (and I mean it) confusing. Can we simplify it somehow? The current Oleg's fix is the simplest yet (almost) backwards compatible solution we've found. If you have another ideas, please, let us know :) Thanks, Artem > -- > best regards, > Anthony > > On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: >> Hi Artem, Anthony, >> >> thank you for your proposals! >> >> We with Artem also had off-line discussion, >> so as a result I prepared improved version of fix: >> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ >> >> What was done: >> 1. EventQueue.detachDispatchThread(): moved >> SunToolkit.flushPnedingEvents() above the comments and added a >> separate comment to it. >> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to >> SunToolkit. Deleted SunToolkitSubclass. >> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - >> isThreadLocalFlushing and made it ThreadLocal. >> 4. Left PostEventQueue.flush() unsynchronized and created >> wait()-notifyAll() synchronization mechanism to avoid blocking of >> PostEventQueue.postEvent(). >> >> Looking forward to your comments! >> >> Thanks, >> Oleg >> >> 20.08.2012 20:20, Artem Ananiev wrote: >>> Hi, Oleg, >>> >>> here are a few comments: >>> >>> 1. What is the reason of keeping "isFlushingPendingEvents" in >>> SunToolkit, given that PEQ.flush() is synchronized (and therefore >>> serialized) anyway? >>> >>> 2. flushPendingEvents(AppContext) may be moved directly to >>> SunToolkit, so we don't need a separate sun-class for that. >>> >>> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced >>> by another one. >>> >>> Thanks, >>> >>> Artem >>> >>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>>> Hi! >>>> >>>> Please review the fix for CR: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >>>> >>>> The following changes were made: >>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>>> 3. Added call of SunToolkit.flushPendingEvents() to >>>> EventQueue.detachDispatchThread(), >>>> right before pushPopLock.lock() >>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >>>> EventQueue.detachDispatchThread() >>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & >>>> PostEventQueue.noEvents(); >>>> >>>> Thanks, >>>> Oleg >>>> >> >> From anthony.petrov at oracle.com Thu Aug 30 06:00:29 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 30 Aug 2012 17:00:29 +0400 Subject: [8] Review request for 7190587 Open source and jtreg'ify JAWT regression test In-Reply-To: <503E4E20.5000001@oracle.com> References: <503BA04E.6000801@oracle.com> <503E41CB.5090204@redhat.com> <503E46C4.2050002@oracle.com> <503E4789.9020704@redhat.com> <503E4E20.5000001@oracle.com> Message-ID: <503F63ED.70706@oracle.com> Looks great to me, too. Thanks! And thanks Omair for noticing the issue! -- best regards, Anthony On 08/29/12 21:15, Konstantin Shefov wrote: > Here is updated webrev: > http://cr.openjdk.java.net/~kshefov/7190587/webrev.02/ > > > On 29.08.2012 20:47, Omair Majid wrote: >> Hi Konstantin, >> >> On 08/29/2012 12:43 PM, Konstantin Shefov wrote: >>> I can remove path to libjawt.so from LD_LIBRARY_PATH, but I have to >>> leave working dir in it, i.e. >>> export LD_LIBRARY_PATH="." >>> Without it test cannot find libmylib.so in working directory. >>> >> Oh, of course. I somehow thought the test used an explicit path to >> libmylib.so. I would be perfectly happy if libjawt.so was removed from >> LD_LIBRARY_PATH. >> >> Thanks, >> Omair From anthony.petrov at oracle.com Thu Aug 30 06:20:14 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 30 Aug 2012 17:20:14 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503E791E.90207@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> <503DF844.302@oracle.com> <503DFB6A.6020209@oracle.com> <503E791E.90207@oracle.com> Message-ID: <503F688E.2090903@oracle.com> I see. After giving it more thought I don't see an easy solution for this issue, too. As long as we guarantee that the EDT is recreated should more events be posted, I don't see a big problem with this. So let's stick with the "Minimize..." approach then. -- best regards, Anthony On 08/30/12 00:18, Oleg Pekhovskiy wrote: > Hi Anthony, > > I see your concerns. > > As PostEventQueue.flush() method left unsynchronized, > we potentially could return PostEventQueue.noEvents() > and return check in EventQueue.detachDispatchThread() > back to the condition. > But is could increase the possibility of deadlock in future > (with PostEventQueue & pushPopLock). > > Artem, what do you think? > > Thanks, > Oleg > > 29.08.2012 15:22, Anthony Petrov wrote: >> On 8/29/2012 3:08 PM, Anthony Petrov wrote: >>> Hi Oleg, >>> >>> I'm still concerned about the following: >>> >>> detachDispatchThread() >>> { >>> flush(); >>> lock(); >>> // possibly detach >>> unlock(); >>> } >>> >>> at EventQueue.java. What if an even get posted to the queue after the >> >> A typo: s/even get/event gets/. >> >> -- >> best regards, >> Anthony >> >>> flush() returns but before we even acquired the lock? We may still >>> end up with a situation when we detach the thread while in fact there >>> are some pending events present, which actually contradicts the >>> current logic of the detach() method. I see that you say "Minimize >>> discard possibility" in the comment instead of "Prevent ...", but I >>> feel uncomfortable with this actually. >>> >>> What exactly prevents us from adding some synchronization to ensure >>> that the detaching only happens when there's really no pending events? >>> >>> SunToolkit.java: >>>> 2120 Boolean b = isThreadLocalFlushing.get(); >>>> 2121 if (b != null && b) { >>>> 2122 return; >>>> 2123 } >>>> 2124 2125 isThreadLocalFlushing.set(true); >>>> 2126 try { >>> >>> How does access to the isThreadLocalFlushing synchronized? What >>> happens if the flush() is being invoked from two different threads >>> for the same post event queue? Why do we have two "isFlushing" flags? >>> Can we collapse them into one? Why is the isFlushing set/reset in two >>> disjunct synchronized(){} blocks? >>> >>> Overall, I find the current synchronization scheme in flush() very, >>> *very* (and I mean it) confusing. Can we simplify it somehow? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: >>>> Hi Artem, Anthony, >>>> >>>> thank you for your proposals! >>>> >>>> We with Artem also had off-line discussion, >>>> so as a result I prepared improved version of fix: >>>> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ >>>> >>>> What was done: >>>> 1. EventQueue.detachDispatchThread(): moved >>>> SunToolkit.flushPnedingEvents() above the comments and added a >>>> separate comment to it. >>>> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to >>>> SunToolkit. Deleted SunToolkitSubclass. >>>> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name >>>> - isThreadLocalFlushing and made it ThreadLocal. >>>> 4. Left PostEventQueue.flush() unsynchronized and created >>>> wait()-notifyAll() synchronization mechanism to avoid blocking of >>>> PostEventQueue.postEvent(). >>>> >>>> Looking forward to your comments! >>>> >>>> Thanks, >>>> Oleg >>>> >>>> 20.08.2012 20:20, Artem Ananiev wrote: >>>>> Hi, Oleg, >>>>> >>>>> here are a few comments: >>>>> >>>>> 1. What is the reason of keeping "isFlushingPendingEvents" in >>>>> SunToolkit, given that PEQ.flush() is synchronized (and therefore >>>>> serialized) anyway? >>>>> >>>>> 2. flushPendingEvents(AppContext) may be moved directly to >>>>> SunToolkit, so we don't need a separate sun-class for that. >>>>> >>>>> 3. EQ.java:1035-1040 - this comment is obsolete and must be >>>>> replaced by another one. >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>>>>> Hi! >>>>>> >>>>>> Please review the fix for CR: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >>>>>> >>>>>> The following changes were made: >>>>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>>>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>>>>> 3. Added call of SunToolkit.flushPendingEvents() to >>>>>> EventQueue.detachDispatchThread(), >>>>>> right before pushPopLock.lock() >>>>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >>>>>> EventQueue.detachDispatchThread() >>>>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & >>>>>> PostEventQueue.noEvents(); >>>>>> >>>>>> Thanks, >>>>>> Oleg >>>>>> >>>> >>>> > From oleg.pekhovskiy at oracle.com Thu Aug 30 10:01:45 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 30 Aug 2012 21:01:45 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503F688E.2090903@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> <503DF844.302@oracle.com> <503DFB6A.6020209@oracle.com> <503E791E.90207@oracle.com> <503F688E.2090903@oracle.com> Message-ID: <503F9C79.2020104@oracle.com> Hi, I got another idea preparing the next version of fix. Previously we didn't catch InterruptedException and stack unwinding took place right up to try-catch section in EventDispatchThread.pumpOneEventForFilters(). So seems like it would be correct not eating that exception in PostEventQueue.flush() but just check the state using isInterrupted() method and add 'throws InterruptedException' to PostEventQueue.flush() and SunToolkit.flushPendingEvents() methods. Thoughts? Thanks, Oleg 8/30/2012 5:20 PM, Anthony Petrov wrote: > I see. After giving it more thought I don't see an easy solution for > this issue, too. As long as we guarantee that the EDT is recreated > should more events be posted, I don't see a big problem with this. So > let's stick with the "Minimize..." approach then. > > -- > best regards, > Anthony > > On 08/30/12 00:18, Oleg Pekhovskiy wrote: >> Hi Anthony, >> >> I see your concerns. >> >> As PostEventQueue.flush() method left unsynchronized, >> we potentially could return PostEventQueue.noEvents() >> and return check in EventQueue.detachDispatchThread() >> back to the condition. >> But is could increase the possibility of deadlock in future >> (with PostEventQueue & pushPopLock). >> >> Artem, what do you think? >> >> Thanks, >> Oleg >> >> 29.08.2012 15:22, Anthony Petrov wrote: >>> On 8/29/2012 3:08 PM, Anthony Petrov wrote: >>>> Hi Oleg, >>>> >>>> I'm still concerned about the following: >>>> >>>> detachDispatchThread() >>>> { >>>> flush(); >>>> lock(); >>>> // possibly detach >>>> unlock(); >>>> } >>>> >>>> at EventQueue.java. What if an even get posted to the queue after the >>> >>> A typo: s/even get/event gets/. >>> >>> -- >>> best regards, >>> Anthony >>> >>>> flush() returns but before we even acquired the lock? We may still >>>> end up with a situation when we detach the thread while in fact there >>>> are some pending events present, which actually contradicts the >>>> current logic of the detach() method. I see that you say "Minimize >>>> discard possibility" in the comment instead of "Prevent ...", but I >>>> feel uncomfortable with this actually. >>>> >>>> What exactly prevents us from adding some synchronization to ensure >>>> that the detaching only happens when there's really no pending events? >>>> >>>> SunToolkit.java: >>>>> 2120 Boolean b = isThreadLocalFlushing.get(); >>>>> 2121 if (b != null && b) { >>>>> 2122 return; >>>>> 2123 } >>>>> 2124 2125 isThreadLocalFlushing.set(true); >>>>> 2126 try { >>>> >>>> How does access to the isThreadLocalFlushing synchronized? What >>>> happens if the flush() is being invoked from two different threads >>>> for the same post event queue? Why do we have two "isFlushing" flags? >>>> Can we collapse them into one? Why is the isFlushing set/reset in two >>>> disjunct synchronized(){} blocks? >>>> >>>> Overall, I find the current synchronization scheme in flush() very, >>>> *very* (and I mean it) confusing. Can we simplify it somehow? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: >>>>> Hi Artem, Anthony, >>>>> >>>>> thank you for your proposals! >>>>> >>>>> We with Artem also had off-line discussion, >>>>> so as a result I prepared improved version of fix: >>>>> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ >>>>> >>>>> What was done: >>>>> 1. EventQueue.detachDispatchThread(): moved >>>>> SunToolkit.flushPnedingEvents() above the comments and added a >>>>> separate comment to it. >>>>> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to >>>>> SunToolkit. Deleted SunToolkitSubclass. >>>>> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name >>>>> - isThreadLocalFlushing and made it ThreadLocal. >>>>> 4. Left PostEventQueue.flush() unsynchronized and created >>>>> wait()-notifyAll() synchronization mechanism to avoid blocking of >>>>> PostEventQueue.postEvent(). >>>>> >>>>> Looking forward to your comments! >>>>> >>>>> Thanks, >>>>> Oleg >>>>> >>>>> 20.08.2012 20:20, Artem Ananiev wrote: >>>>>> Hi, Oleg, >>>>>> >>>>>> here are a few comments: >>>>>> >>>>>> 1. What is the reason of keeping "isFlushingPendingEvents" in >>>>>> SunToolkit, given that PEQ.flush() is synchronized (and therefore >>>>>> serialized) anyway? >>>>>> >>>>>> 2. flushPendingEvents(AppContext) may be moved directly to >>>>>> SunToolkit, so we don't need a separate sun-class for that. >>>>>> >>>>>> 3. EQ.java:1035-1040 - this comment is obsolete and must be >>>>>> replaced by another one. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>>>>>> Hi! >>>>>>> >>>>>>> Please review the fix for CR: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >>>>>>> >>>>>>> The following changes were made: >>>>>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>>>>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>>>>>> 3. Added call of SunToolkit.flushPendingEvents() to >>>>>>> EventQueue.detachDispatchThread(), >>>>>>> right before pushPopLock.lock() >>>>>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >>>>>>> EventQueue.detachDispatchThread() >>>>>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & >>>>>>> PostEventQueue.noEvents(); >>>>>>> >>>>>>> Thanks, >>>>>>> Oleg >>>>>>> >>>>> >>>>> >> From oleg.pekhovskiy at oracle.com Thu Aug 30 10:19:11 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 30 Aug 2012 21:19:11 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503F9C79.2020104@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> <503DF844.302@oracle.com> <503DFB6A.6020209@oracle.com> <503E791E.90207@oracle.com> <503F688E.2090903@oracle.com> <503F9C79.2020104@oracle.com> Message-ID: <503FA08F.7070603@oracle.com> There are also other 2 methods that will require 'throws InterruptedException' or try-catch: 1. EventQueue.postEvent() 2. EventQueue.removeSourceEvents() Thanks, Oleg 8/30/2012 9:01 PM, Oleg Pekhovskiy wrote: > Hi, > > I got another idea preparing the next version of fix. > > Previously we didn't catch InterruptedException and stack unwinding > took place right up to > try-catch section in EventDispatchThread.pumpOneEventForFilters(). > > So seems like it would be correct not eating that exception in > PostEventQueue.flush() > but just check the state using isInterrupted() method and add 'throws > InterruptedException' > to PostEventQueue.flush() and SunToolkit.flushPendingEvents() methods. > > Thoughts? > > Thanks, > Oleg > > 8/30/2012 5:20 PM, Anthony Petrov wrote: >> I see. After giving it more thought I don't see an easy solution for >> this issue, too. As long as we guarantee that the EDT is recreated >> should more events be posted, I don't see a big problem with this. So >> let's stick with the "Minimize..." approach then. >> >> -- >> best regards, >> Anthony >> >> On 08/30/12 00:18, Oleg Pekhovskiy wrote: >>> Hi Anthony, >>> >>> I see your concerns. >>> >>> As PostEventQueue.flush() method left unsynchronized, >>> we potentially could return PostEventQueue.noEvents() >>> and return check in EventQueue.detachDispatchThread() >>> back to the condition. >>> But is could increase the possibility of deadlock in future >>> (with PostEventQueue & pushPopLock). >>> >>> Artem, what do you think? >>> >>> Thanks, >>> Oleg >>> >>> 29.08.2012 15:22, Anthony Petrov wrote: >>>> On 8/29/2012 3:08 PM, Anthony Petrov wrote: >>>>> Hi Oleg, >>>>> >>>>> I'm still concerned about the following: >>>>> >>>>> detachDispatchThread() >>>>> { >>>>> flush(); >>>>> lock(); >>>>> // possibly detach >>>>> unlock(); >>>>> } >>>>> >>>>> at EventQueue.java. What if an even get posted to the queue after the >>>> >>>> A typo: s/even get/event gets/. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>>> flush() returns but before we even acquired the lock? We may still >>>>> end up with a situation when we detach the thread while in fact there >>>>> are some pending events present, which actually contradicts the >>>>> current logic of the detach() method. I see that you say "Minimize >>>>> discard possibility" in the comment instead of "Prevent ...", but I >>>>> feel uncomfortable with this actually. >>>>> >>>>> What exactly prevents us from adding some synchronization to ensure >>>>> that the detaching only happens when there's really no pending >>>>> events? >>>>> >>>>> SunToolkit.java: >>>>>> 2120 Boolean b = isThreadLocalFlushing.get(); >>>>>> 2121 if (b != null && b) { >>>>>> 2122 return; >>>>>> 2123 } >>>>>> 2124 2125 isThreadLocalFlushing.set(true); >>>>>> 2126 try { >>>>> >>>>> How does access to the isThreadLocalFlushing synchronized? What >>>>> happens if the flush() is being invoked from two different threads >>>>> for the same post event queue? Why do we have two "isFlushing" flags? >>>>> Can we collapse them into one? Why is the isFlushing set/reset in two >>>>> disjunct synchronized(){} blocks? >>>>> >>>>> Overall, I find the current synchronization scheme in flush() very, >>>>> *very* (and I mean it) confusing. Can we simplify it somehow? >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: >>>>>> Hi Artem, Anthony, >>>>>> >>>>>> thank you for your proposals! >>>>>> >>>>>> We with Artem also had off-line discussion, >>>>>> so as a result I prepared improved version of fix: >>>>>> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ >>>>>> >>>>>> What was done: >>>>>> 1. EventQueue.detachDispatchThread(): moved >>>>>> SunToolkit.flushPnedingEvents() above the comments and added a >>>>>> separate comment to it. >>>>>> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to >>>>>> SunToolkit. Deleted SunToolkitSubclass. >>>>>> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name >>>>>> - isThreadLocalFlushing and made it ThreadLocal. >>>>>> 4. Left PostEventQueue.flush() unsynchronized and created >>>>>> wait()-notifyAll() synchronization mechanism to avoid blocking of >>>>>> PostEventQueue.postEvent(). >>>>>> >>>>>> Looking forward to your comments! >>>>>> >>>>>> Thanks, >>>>>> Oleg >>>>>> >>>>>> 20.08.2012 20:20, Artem Ananiev wrote: >>>>>>> Hi, Oleg, >>>>>>> >>>>>>> here are a few comments: >>>>>>> >>>>>>> 1. What is the reason of keeping "isFlushingPendingEvents" in >>>>>>> SunToolkit, given that PEQ.flush() is synchronized (and therefore >>>>>>> serialized) anyway? >>>>>>> >>>>>>> 2. flushPendingEvents(AppContext) may be moved directly to >>>>>>> SunToolkit, so we don't need a separate sun-class for that. >>>>>>> >>>>>>> 3. EQ.java:1035-1040 - this comment is obsolete and must be >>>>>>> replaced by another one. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Artem >>>>>>> >>>>>>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>>>>>>> Hi! >>>>>>>> >>>>>>>> Please review the fix for CR: >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >>>>>>>> >>>>>>>> The following changes were made: >>>>>>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>>>>>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>>>>>>> 3. Added call of SunToolkit.flushPendingEvents() to >>>>>>>> EventQueue.detachDispatchThread(), >>>>>>>> right before pushPopLock.lock() >>>>>>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >>>>>>>> EventQueue.detachDispatchThread() >>>>>>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & >>>>>>>> PostEventQueue.noEvents(); >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Oleg >>>>>>>> >>>>>> >>>>>> >>> > From peter.levart at gmail.com Thu Aug 30 13:39:03 2012 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 30 Aug 2012 22:39:03 +0200 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503F5F98.4020207@oracle.com> References: <502E3DD1.9020604@oracle.com> <503DF844.302@oracle.com> <503F5F98.4020207@oracle.com> Message-ID: <7969013.t7YTOqxCuf@cube.localdomain> Hi Oleg, Now that SunToolkit is never called from EventQueue while holding pushPopLock (not even from detatchDispatchThread - I saw you removed SunToolkit.isPostEventQueueEmpty() check), there's no need for flushing loop in PostEventQueue not to be simply synchronized again and be done with InterruptedExceptions and handlers, Am I right? Regards, Peter On Thursday, August 30, 2012 04:42:00 PM Artem Ananiev wrote: > Hi, Anthony, > > On 8/29/2012 3:08 PM, Anthony Petrov wrote: > > Hi Oleg, > > > > I'm still concerned about the following: > > > > detachDispatchThread() > > { > > flush(); > > lock(); > > // possibly detach > > unlock(); > > } > > > > at EventQueue.java. What if an even get posted to the queue after the > > flush() returns but before we even acquired the lock? We may still end > > up with a situation when we detach the thread while in fact there are > > some pending events present, which actually contradicts the current > > logic of the detach() method. I see that you say "Minimize discard > > possibility" in the comment instead of "Prevent ...", but I feel > > uncomfortable with this actually. > > yes, this is a known issue: we don't guarantee that no new events are > posted between flush() and lock(). If this happens, we'll re-create > event dispatch thread. > > > What exactly prevents us from adding some synchronization to ensure that > > the detaching only happens when there's really no pending events? > > As Oleg wrote, this is exactly the deadlock we're trying to resolve. > EQ.detachDispatchThread() was the only place where the order of locks > was pushPopLock->flushLock, while in other cases we flush events without > pushPopLock. > > > SunToolkit.java: > >> 2120 Boolean b = isThreadLocalFlushing.get(); > >> 2121 if (b != null && b) { > >> 2122 return; > >> 2123 } > >> 2124 2125 isThreadLocalFlushing.set(true); > >> 2126 try { > > > > How does access to the isThreadLocalFlushing synchronized? What happens > > if the flush() is being invoked from two different threads for the same > > post event queue? Why do we have two "isFlushing" flags? Can we collapse > > them into one? Why is the isFlushing set/reset in two disjunct > > synchronized(){} blocks? > > As David correctly wrote, isThreadLocalFlushing is a ThreadLocal object, > which is thread-safe. isFlushing is used to synchronize access from > multiple threads, isThreadLockFlushing is to prevent EQ.postEvent() to > be called recursively. > > The only valid comment is that isThreadLocalFlushing should be set to > false in the "finally" block. Oleg will include this change into the > next version of the fix. > > > Overall, I find the current synchronization scheme in flush() very, > > *very* (and I mean it) confusing. Can we simplify it somehow? > > The current Oleg's fix is the simplest yet (almost) backwards compatible > solution we've found. If you have another ideas, please, let us know :) > > Thanks, > > Artem > > > -- > > best regards, > > Anthony > > > > On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: > >> Hi Artem, Anthony, > >> > >> thank you for your proposals! > >> > >> We with Artem also had off-line discussion, > >> so as a result I prepared improved version of fix: > >> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ > >> > >> What was done: > >> 1. EventQueue.detachDispatchThread(): moved > >> SunToolkit.flushPnedingEvents() above the comments and added a > >> separate comment to it. > >> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to > >> SunToolkit. Deleted SunToolkitSubclass. > >> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - > >> isThreadLocalFlushing and made it ThreadLocal. > >> 4. Left PostEventQueue.flush() unsynchronized and created > >> wait()-notifyAll() synchronization mechanism to avoid blocking of > >> PostEventQueue.postEvent(). > >> > >> Looking forward to your comments! > >> > >> Thanks, > >> Oleg > >> > >> 20.08.2012 20:20, Artem Ananiev wrote: > >>> Hi, Oleg, > >>> > >>> here are a few comments: > >>> > >>> 1. What is the reason of keeping "isFlushingPendingEvents" in > >>> SunToolkit, given that PEQ.flush() is synchronized (and therefore > >>> serialized) anyway? > >>> > >>> 2. flushPendingEvents(AppContext) may be moved directly to > >>> SunToolkit, so we don't need a separate sun-class for that. > >>> > >>> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced > >>> by another one. > >>> > >>> Thanks, > >>> > >>> Artem > >>> > >>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: > >>>> Hi! > >>>> > >>>> Please review the fix for CR: > >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 > >>>> > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ > >>>> > >>>> The following changes were made: > >>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() > >>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back > >>>> 3. Added call of SunToolkit.flushPendingEvents() to > >>>> EventQueue.detachDispatchThread(), > >>>> right before pushPopLock.lock() > >>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from > >>>> EventQueue.detachDispatchThread() > >>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & > >>>> PostEventQueue.noEvents(); > >>>> > >>>> Thanks, > >>>> Oleg > >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120830/fc4bc112/attachment.html From peter.levart at gmail.com Thu Aug 30 14:01:47 2012 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 30 Aug 2012 23:01:47 +0200 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <7969013.t7YTOqxCuf@cube.localdomain> References: <502E3DD1.9020604@oracle.com> <503F5F98.4020207@oracle.com> <7969013.t7YTOqxCuf@cube.localdomain> Message-ID: <2253829.ClliP5V5Oi@cube.localdomain> If I'm right, then instead of using thread-local flag for recursion-prevention, you can just re-instate a boolean flag: private boolean isFlushing = false; public synchronized void flush() { if (isFlushing) { // every EventQueue.postEvent calls us back - prevent recursion return; } isFlushing = true; try { EventQueueItem tempQueue = queueHead; queueHead = queueTail = null; while (tempQueue != null) { eventQueue.postEvent(tempQueue.event); tempQueue = tempQueue.next; } } } finally { isFlushing = false; } } Regards, Peter On Thursday, August 30, 2012 10:39:03 PM Peter Levart wrote: Hi Oleg, Now that SunToolkit is never called from EventQueue while holding pushPopLock (not even from detatchDispatchThread - I saw you removed SunToolkit.isPostEventQueueEmpty() check), there's no need for flushing loop in PostEventQueue not to be simply synchronized again and be done with InterruptedExceptions and handlers, Am I right? Regards, Peter On Thursday, August 30, 2012 04:42:00 PM Artem Ananiev wrote: > Hi, Anthony, > > On 8/29/2012 3:08 PM, Anthony Petrov wrote: > > Hi Oleg, > > > > I'm still concerned about the following: > > > > detachDispatchThread() > > { > > flush(); > > lock(); > > // possibly detach > > unlock(); > > } > > > > at EventQueue.java. What if an even get posted to the queue after the > > flush() returns but before we even acquired the lock? We may still end > > up with a situation when we detach the thread while in fact there are > > some pending events present, which actually contradicts the current > > logic of the detach() method. I see that you say "Minimize discard > > possibility" in the comment instead of "Prevent ...", but I feel > > uncomfortable with this actually. > > yes, this is a known issue: we don't guarantee that no new events are > posted between flush() and lock(). If this happens, we'll re-create > event dispatch thread. > > > What exactly prevents us from adding some synchronization to ensure that > > the detaching only happens when there's really no pending events? > > As Oleg wrote, this is exactly the deadlock we're trying to resolve. > EQ.detachDispatchThread() was the only place where the order of locks > was pushPopLock->flushLock, while in other cases we flush events without > pushPopLock. > > > SunToolkit.java: > >> 2120 Boolean b = isThreadLocalFlushing.get(); > >> 2121 if (b != null && b) { > >> 2122 return; > >> 2123 } > >> 2124 2125 isThreadLocalFlushing.set(true); > >> 2126 try { > > > > How does access to the isThreadLocalFlushing synchronized? What happens > > if the flush() is being invoked from two different threads for the same > > post event queue? Why do we have two "isFlushing" flags? Can we collapse > > them into one? Why is the isFlushing set/reset in two disjunct > > synchronized(){} blocks? > > As David correctly wrote, isThreadLocalFlushing is a ThreadLocal object, > which is thread-safe. isFlushing is used to synchronize access from > multiple threads, isThreadLockFlushing is to prevent EQ.postEvent() to > be called recursively. > > The only valid comment is that isThreadLocalFlushing should be set to > false in the "finally" block. Oleg will include this change into the > next version of the fix. > > > Overall, I find the current synchronization scheme in flush() very, > > *very* (and I mean it) confusing. Can we simplify it somehow? > > The current Oleg's fix is the simplest yet (almost) backwards compatible > solution we've found. If you have another ideas, please, let us know :) > > Thanks, > > Artem > > > -- > > best regards, > > Anthony > > > > On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: > >> Hi Artem, Anthony, > >> > >> thank you for your proposals! > >> > >> We with Artem also had off-line discussion, > >> so as a result I prepared improved version of fix: > >> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ > >> > >> What was done: > >> 1. EventQueue.detachDispatchThread(): moved > >> SunToolkit.flushPnedingEvents() above the comments and added a > >> separate comment to it. > >> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to > >> SunToolkit. Deleted SunToolkitSubclass. > >> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - > >> isThreadLocalFlushing and made it ThreadLocal. > >> 4. Left PostEventQueue.flush() unsynchronized and created > >> wait()-notifyAll() synchronization mechanism to avoid blocking of > >> PostEventQueue.postEvent(). > >> > >> Looking forward to your comments! > >> > >> Thanks, > >> Oleg > >> > >> 20.08.2012 20:20, Artem Ananiev wrote: > >>> Hi, Oleg, > >>> > >>> here are a few comments: > >>> > >>> 1. What is the reason of keeping "isFlushingPendingEvents" in > >>> SunToolkit, given that PEQ.flush() is synchronized (and therefore > >>> serialized) anyway? > >>> > >>> 2. flushPendingEvents(AppContext) may be moved directly to > >>> SunToolkit, so we don't need a separate sun-class for that. > >>> > >>> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced > >>> by another one. > >>> > >>> Thanks, > >>> > >>> Artem > >>> > >>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: > >>>> Hi! > >>>> > >>>> Please review the fix for CR: > >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 > >>>> > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ > >>>> > >>>> The following changes were made: > >>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() > >>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back > >>>> 3. Added call of SunToolkit.flushPendingEvents() to > >>>> EventQueue.detachDispatchThread(), > >>>> right before pushPopLock.lock() > >>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from > >>>> EventQueue.detachDispatchThread() > >>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & > >>>> PostEventQueue.noEvents(); > >>>> > >>>> Thanks, > >>>> Oleg > >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120830/e21a265a/attachment.html From peter.levart at gmail.com Thu Aug 30 14:21:37 2012 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 30 Aug 2012 23:21:37 +0200 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503F5F98.4020207@oracle.com> References: <502E3DD1.9020604@oracle.com> <503DF844.302@oracle.com> <503F5F98.4020207@oracle.com> Message-ID: <2227782.ivpGkXEkPi@cube.localdomain> Hi Oleg, Artem an others If you are concerned about loosing events in EventQueue.detachDispatchThread (a small window between returning from SunToolkit.flushPendingEvents() and acquire-ing the pushPopLock) and can add to SunToolkit an overloaded static flushPendingEvents method that takes an aditional Runnable parameter called "afterFlushCallback", then the pushPopLock guarded section of detachDispatchThread can be passed as such afterFlushCallback to SunToolkit.flushPendingEvents. This way you reverse the order of locks and prevent dead-lock while guarantee- ing that no events get discarded... Regards, Peter On Thursday, August 30, 2012 04:42:00 PM Artem Ananiev wrote: > Hi, Anthony, > > On 8/29/2012 3:08 PM, Anthony Petrov wrote: > > Hi Oleg, > > > > I'm still concerned about the following: > > > > detachDispatchThread() > > { > > flush(); > > lock(); > > // possibly detach > > unlock(); > > } > > > > at EventQueue.java. What if an even get posted to the queue after the > > flush() returns but before we even acquired the lock? We may still end > > up with a situation when we detach the thread while in fact there are > > some pending events present, which actually contradicts the current > > logic of the detach() method. I see that you say "Minimize discard > > possibility" in the comment instead of "Prevent ...", but I feel > > uncomfortable with this actually. > > yes, this is a known issue: we don't guarantee that no new events are > posted between flush() and lock(). If this happens, we'll re-create > event dispatch thread. > > > What exactly prevents us from adding some synchronization to ensure that > > the detaching only happens when there's really no pending events? > > As Oleg wrote, this is exactly the deadlock we're trying to resolve. > EQ.detachDispatchThread() was the only place where the order of locks > was pushPopLock->flushLock, while in other cases we flush events without > pushPopLock. > > > SunToolkit.java: > >> 2120 Boolean b = isThreadLocalFlushing.get(); > >> 2121 if (b != null && b) { > >> 2122 return; > >> 2123 } > >> 2124 2125 isThreadLocalFlushing.set(true); > >> 2126 try { > > > > How does access to the isThreadLocalFlushing synchronized? What happens > > if the flush() is being invoked from two different threads for the same > > post event queue? Why do we have two "isFlushing" flags? Can we collapse > > them into one? Why is the isFlushing set/reset in two disjunct > > synchronized(){} blocks? > > As David correctly wrote, isThreadLocalFlushing is a ThreadLocal object, > which is thread-safe. isFlushing is used to synchronize access from > multiple threads, isThreadLockFlushing is to prevent EQ.postEvent() to > be called recursively. > > The only valid comment is that isThreadLocalFlushing should be set to > false in the "finally" block. Oleg will include this change into the > next version of the fix. > > > Overall, I find the current synchronization scheme in flush() very, > > *very* (and I mean it) confusing. Can we simplify it somehow? > > The current Oleg's fix is the simplest yet (almost) backwards compatible > solution we've found. If you have another ideas, please, let us know :) > > Thanks, > > Artem > > > -- > > best regards, > > Anthony > > > > On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: > >> Hi Artem, Anthony, > >> > >> thank you for your proposals! > >> > >> We with Artem also had off-line discussion, > >> so as a result I prepared improved version of fix: > >> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ > >> > >> What was done: > >> 1. EventQueue.detachDispatchThread(): moved > >> SunToolkit.flushPnedingEvents() above the comments and added a > >> separate comment to it. > >> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to > >> SunToolkit. Deleted SunToolkitSubclass. > >> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - > >> isThreadLocalFlushing and made it ThreadLocal. > >> 4. Left PostEventQueue.flush() unsynchronized and created > >> wait()-notifyAll() synchronization mechanism to avoid blocking of > >> PostEventQueue.postEvent(). > >> > >> Looking forward to your comments! > >> > >> Thanks, > >> Oleg > >> > >> 20.08.2012 20:20, Artem Ananiev wrote: > >>> Hi, Oleg, > >>> > >>> here are a few comments: > >>> > >>> 1. What is the reason of keeping "isFlushingPendingEvents" in > >>> SunToolkit, given that PEQ.flush() is synchronized (and therefore > >>> serialized) anyway? > >>> > >>> 2. flushPendingEvents(AppContext) may be moved directly to > >>> SunToolkit, so we don't need a separate sun-class for that. > >>> > >>> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced > >>> by another one. > >>> > >>> Thanks, > >>> > >>> Artem > >>> > >>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: > >>>> Hi! > >>>> > >>>> Please review the fix for CR: > >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 > >>>> > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ > >>>> > >>>> The following changes were made: > >>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() > >>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back > >>>> 3. Added call of SunToolkit.flushPendingEvents() to > >>>> EventQueue.detachDispatchThread(), > >>>> right before pushPopLock.lock() > >>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from > >>>> EventQueue.detachDispatchThread() > >>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & > >>>> PostEventQueue.noEvents(); > >>>> > >>>> Thanks, > >>>> Oleg > >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120830/c60d4679/attachment.html From sergey.malenkov at oracle.com Fri Aug 31 03:37:32 2012 From: sergey.malenkov at oracle.com (sergey.malenkov at oracle.com) Date: Fri, 31 Aug 2012 10:37:32 +0000 Subject: hg: jdk8/awt/jdk: 7192955: Introspector overide PropertyDescriptor for generic type field defined in super class Message-ID: <20120831103824.0B25947832@hg.openjdk.java.net> Changeset: 973693566c46 Author: malenkov Date: 2012-08-31 14:32 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/973693566c46 7192955: Introspector overide PropertyDescriptor for generic type field defined in super class Reviewed-by: rupashka ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7192955.java From sergey.malenkov at oracle.com Fri Aug 31 03:56:24 2012 From: sergey.malenkov at oracle.com (sergey.malenkov at oracle.com) Date: Fri, 31 Aug 2012 10:56:24 +0000 Subject: hg: jdk8/awt/jdk: 7186794: Setter not found. PropertyDescriptor(PropertyDescriptor, PropertyDescriptor) Message-ID: <20120831105703.4AB9C47833@hg.openjdk.java.net> Changeset: b291b6d220c7 Author: malenkov Date: 2012-08-31 14:49 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b291b6d220c7 7186794: Setter not found. PropertyDescriptor(PropertyDescriptor,PropertyDescriptor) Reviewed-by: rupashka ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7186794.java ! test/java/beans/Introspector/Test7189112.java From oleg.pekhovskiy at oracle.com Fri Aug 31 04:01:01 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 31 Aug 2012 15:01:01 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <2253829.ClliP5V5Oi@cube.localdomain> References: <502E3DD1.9020604@oracle.com> <503F5F98.4020207@oracle.com> <7969013.t7YTOqxCuf@cube.localdomain> <2253829.ClliP5V5Oi@cube.localdomain> Message-ID: <5040996D.50709@oracle.com> Hi Peter, making PostEventQueue.flush() method 'synchronized' will block Toolkit thread during PostEventQueue.postEvent() call, that is bad. In our case synchronization monitor is released on wait(), thus no blocking occurs. Thanks, Oleg 31.08.2012 1:01, Peter Levart wrote: > > If I'm right, then instead of using thread-local flag for > recursion-prevention, you can just re-instate a boolean flag: > > private boolean isFlushing = false; > > public synchronized void flush() { > > if (isFlushing) { > > // every EventQueue.postEvent calls us back - prevent recursion > > return; > > } > > isFlushing = true; > > try { > > EventQueueItem tempQueue = queueHead; > > queueHead = queueTail = null; > > while (tempQueue != null) { > > eventQueue.postEvent(tempQueue.event); > > tempQueue = tempQueue.next; > > } > > } > > } > > finally { > > isFlushing = false; > > } > > } > > Regards, Peter > > On Thursday, August 30, 2012 10:39:03 PM Peter Levart wrote: > > Hi Oleg, > > Now that SunToolkit is never called from EventQueue while holding > pushPopLock (not even from detatchDispatchThread - I saw you removed > SunToolkit.isPostEventQueueEmpty() check), there's no need for > flushing loop in PostEventQueue not to be simply synchronized again > and be done with InterruptedExceptions and handlers, Am I right? > > Regards, Peter > > On Thursday, August 30, 2012 04:42:00 PM Artem Ananiev wrote: > > > Hi, Anthony, > > > > > > On 8/29/2012 3:08 PM, Anthony Petrov wrote: > > > > Hi Oleg, > > > > > > > > I'm still concerned about the following: > > > > > > > > detachDispatchThread() > > > > { > > > > flush(); > > > > lock(); > > > > // possibly detach > > > > unlock(); > > > > } > > > > > > > > at EventQueue.java. What if an even get posted to the queue after the > > > > flush() returns but before we even acquired the lock? We may still end > > > > up with a situation when we detach the thread while in fact there are > > > > some pending events present, which actually contradicts the current > > > > logic of the detach() method. I see that you say "Minimize discard > > > > possibility" in the comment instead of "Prevent ...", but I feel > > > > uncomfortable with this actually. > > > > > > yes, this is a known issue: we don't guarantee that no new events are > > > posted between flush() and lock(). If this happens, we'll re-create > > > event dispatch thread. > > > > > > > What exactly prevents us from adding some synchronization to > ensure that > > > > the detaching only happens when there's really no pending events? > > > > > > As Oleg wrote, this is exactly the deadlock we're trying to resolve. > > > EQ.detachDispatchThread() was the only place where the order of locks > > > was pushPopLock->flushLock, while in other cases we flush events without > > > pushPopLock. > > > > > > > SunToolkit.java: > > > >> 2120 Boolean b = isThreadLocalFlushing.get(); > > > >> 2121 if (b != null && b) { > > > >> 2122 return; > > > >> 2123 } > > > >> 2124 2125 isThreadLocalFlushing.set(true); > > > >> 2126 try { > > > > > > > > How does access to the isThreadLocalFlushing synchronized? What > happens > > > > if the flush() is being invoked from two different threads for the > same > > > > post event queue? Why do we have two "isFlushing" flags? Can we > collapse > > > > them into one? Why is the isFlushing set/reset in two disjunct > > > > synchronized(){} blocks? > > > > > > As David correctly wrote, isThreadLocalFlushing is a ThreadLocal object, > > > which is thread-safe. isFlushing is used to synchronize access from > > > multiple threads, isThreadLockFlushing is to prevent EQ.postEvent() to > > > be called recursively. > > > > > > The only valid comment is that isThreadLocalFlushing should be set to > > > false in the "finally" block. Oleg will include this change into the > > > next version of the fix. > > > > > > > Overall, I find the current synchronization scheme in flush() very, > > > > *very* (and I mean it) confusing. Can we simplify it somehow? > > > > > > The current Oleg's fix is the simplest yet (almost) backwards compatible > > > solution we've found. If you have another ideas, please, let us know :) > > > > > > Thanks, > > > > > > Artem > > > > > > > -- > > > > best regards, > > > > Anthony > > > > > > > > On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: > > > >> Hi Artem, Anthony, > > > >> > > > >> thank you for your proposals! > > > >> > > > >> We with Artem also had off-line discussion, > > > >> so as a result I prepared improved version of fix: > > > >> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ > > > >> > > > >> What was done: > > > >> 1. EventQueue.detachDispatchThread(): moved > > > >> SunToolkit.flushPnedingEvents() above the comments and added a > > > >> separate comment to it. > > > >> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to > > > >> SunToolkit. Deleted SunToolkitSubclass. > > > >> 3. Moved isFlushingPendingEvents to PostEventQueue with the new > name - > > > >> isThreadLocalFlushing and made it ThreadLocal. > > > >> 4. Left PostEventQueue.flush() unsynchronized and created > > > >> wait()-notifyAll() synchronization mechanism to avoid blocking of > > > >> PostEventQueue.postEvent(). > > > >> > > > >> Looking forward to your comments! > > > >> > > > >> Thanks, > > > >> Oleg > > > >> > > > >> 20.08.2012 20:20, Artem Ananiev wrote: > > > >>> Hi, Oleg, > > > >>> > > > >>> here are a few comments: > > > >>> > > > >>> 1. What is the reason of keeping "isFlushingPendingEvents" in > > > >>> SunToolkit, given that PEQ.flush() is synchronized (and therefore > > > >>> serialized) anyway? > > > >>> > > > >>> 2. flushPendingEvents(AppContext) may be moved directly to > > > >>> SunToolkit, so we don't need a separate sun-class for that. > > > >>> > > > >>> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced > > > >>> by another one. > > > >>> > > > >>> Thanks, > > > >>> > > > >>> Artem > > > >>> > > > >>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: > > > >>>> Hi! > > > >>>> > > > >>>> Please review the fix for CR: > > > >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 > > > >>>> > > > >>>> Webrev: > > > >>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ > > > >>>> > > > >>>> The following changes were made: > > > >>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() > > > >>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back > > > >>>> 3. Added call of SunToolkit.flushPendingEvents() to > > > >>>> EventQueue.detachDispatchThread(), > > > >>>> right before pushPopLock.lock() > > > >>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from > > > >>>> EventQueue.detachDispatchThread() > > > >>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & > > > >>>> PostEventQueue.noEvents(); > > > >>>> > > > >>>> Thanks, > > > >>>> Oleg > > > >>>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120831/5cb22982/attachment.html From anton.tarasov at oracle.com Fri Aug 31 04:52:15 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 31 Aug 2012 15:52:15 +0400 Subject: [8] Review request for 6981400 Tabbing between textfield do not work properly when ALT+TAB In-Reply-To: <503F4659.1050508@oracle.com> References: <4FF5A290.6040308@oracle.com> <4FF5A4F7.7020308@oracle.com> <503DF37A.9060505@oracle.com> <503F4659.1050508@oracle.com> Message-ID: <5040A56F.3070107@oracle.com> Had to adopt the changes in LWWindowPeer.java to the latest changes in jdk: http://cr.openjdk.java.net/~ant/6981400/webrev.7/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html The changes are inessential, still the last webrev is this: http://cr.openjdk.java.net/~ant/6981400/webrev.7 Thanks, Anton. On 8/30/12 2:54 PM, Artem Ananiev wrote: > > Approved. > > Thanks, > > Artem > > On 8/29/2012 2:48 PM, Anton V. Tarasov wrote: >> Please look at the updated version: >> >> http://cr.openjdk.java.net/~ant/6981400/webrev.6 >> >> It contains the following changes: >> >> 1. >> http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.udiff.html >> >> >> Comments updated. >> >> 2. >> http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/java/awt/Component.java.udiff.html >> >> >> The method: >> >> ((MouseEvent)currentEvent).getComponent() >> >> >> is called instead of getSource() in order to avoid "instanceof" check >> for non-component sources. >> >> 3. >> http://cr.openjdk.java.net/~ant/6981400/webrev.6/src/share/classes/sun/awt/SunToolkit.java.udiff.html >> >> >> AppContext is used to store window deactivation times to guarantee >> security. >> >> 4. >> http://cr.openjdk.java.net/~ant/6981400/webrev.6/test/java/awt/Focus/6981400/Test1.java.html >> >> >> Focus events order check is suppressed for XToolkit where this >> functionality can't be implemented due to time-less native focus >> messages. >> >> Thanks, >> Anton. >> >> On 05.07.2012 18:30, Anton V. Tarasov wrote: >>> [I had to fix the links in the previous e-mail, replaced webrev.4 with >>> webrev.5, sorry] >>> >>> Hi, >>> >>> Please review a fix for the CR: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6981400 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5 >>> >>> The fix covers a number of issues and is an evaluated version of the >>> fix originally integrated into jdk6. The scenario which reproduces >>> the referred problems looks pretty like the following: >>> >>> A frame with components. The first component is focused. In its >>> focusLost(..) listener it performs some lengthy operation. >>> TAB key is pressed, say, 5 times. The first component loses focus, the >>> lengthy operation begins which freezes EDT for a while. >>> At the same time, a user switches to some other window by Alt-TAB and >>> then switches back by another Alt-TAB. When the lengthy >>> operation is done, the user expects focus to be transferred through >>> the components in order as if no toplevel switch has happened. >>> Alternatively, the toplevel switch could be done by a mouse click in a >>> component of the other java toplevel and then by a click to the >>> title of the original frame. >>> >>> This may cause the following unexpected results: >>> >>> 1) Focus doesn't go through all the 5 components (which 5 TABs should >>> result in) but stops on, say, the 3rd one. >>> 2) Components are being transferred in wrong order, say 2, 3, 2, 4, 5, >>> 6 instead of 2, 3, 4, 5, 6. >>> 3) A menu of the original frame eventually gets activated >>> (reproducible on MS Windows). >>> >>> Detailed description of why AWT behaves that way is quite lengthy & >>> tangled. It can be found in the CR. >>> Below I'll shortly comment the changes made. (The fix additionally >>> contains changes not directly related to the 3 problems mentioned >>> above, >>> but those changes were introduced based on thorough testing with the >>> focus regression test base and analysing the failures). >>> >>> 1. Component.requestFocusHelper(..), Component.dispatchEventImpl(..), >>> Container, Dialog, EventQueue >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Component.java.sdiff.html >>> >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Container.java.sdiff.html >>> >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Dialog.java.sdiff.html >>> >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/EventQueue.java.sdiff.html >>> >>> >>> >>> A focus request, in order to set a type-ahead marker's time, uses the >>> time stamp of the last dispatched _key_ event. >>> A time stamp of a key event, which is put into the type-ahead queue, >>> is not registered until the event is retrieved from the queue for >>> normal dispatching. >>> This establishes strong dependence b/w type-ahead markers and the >>> order in which key events are actually dispatched. >>> >>> 2. Component.requestFocusHelper(..) >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/Component.java.sdiff.html >>> >>> >>> >>> As the comments say, a focus request following a mouse event is forced >>> to be "in-window" focus requests. This is to make sure it won't >>> re-activate the window >>> in case the window is inactive by the time the request takes its turn >>> for processing. This type of deferred side effect of the mouse event >>> may not be correctly >>> processed under "tough" conditions and should be dropped. >>> >>> 3. LWComponentPeer, LWWindowPeer >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWComponentPeer.java.sdiff.html >>> >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html >>> >>> >>> >>> A simple (not Frame/Dialog) window or an active but not focused >>> Frame/Dialog should request window focus by mouse click right on >>> dispatching of the mouse event >>> on the platform side, not after the event made the "platform -> java >>> -> platform" cycle. >>> >>> 4. LWWindowPeer.dispatchKeyEvent(..) >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/macosx/classes/sun/lwawt/LWWindowPeer.java.udiff.html >>> >>> >>> >>> This is actually a fix for 7157015 (which I'll close later). The bug >>> affects behavior and troubles testing of the whole fix, so I'm >>> including this code as dependent. >>> >>> 5. XBaseWindow, XComponentPeer >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/solaris/classes/sun/awt/X11/XBaseWindow.java.sdiff.html >>> >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/solaris/classes/sun/awt/X11/XComponentPeer.java.sdiff.html >>> >>> >>> >>> Similarly to (3), but for X11 implementation. Additionally, >>> "actualFocusedWindow" reference, which is the most recent focused >>> owned simple window, is reset because >>> a click in an owned window should deliver focus to that window, not to >>> the most recently focused one. >>> >>> 6. DefaultKeyboardFocusManager.repostIfFollowsKeyEvents(..) >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/java/awt/DefaultKeyboardFocusManager.java.sdiff.html >>> >>> >>> >>> (The change originally suggested by Oleg Pekhovskiy) Toplevel window >>> focus events (WINDOW_GAINED_FOCUS/WINDOW_LOST_FOCUS) should not be >>> processed >>> until the type-ahead queue, populated before the event of switching >>> toplevel windows actually happened, is empty. The only we can do here >>> is to repost the toplevel focus >>> events to the end of the EDT queue. >>> >>> 7. KeyboardFocusManagerPeerImpl >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java.sdiff.html >>> >>> >>> >>> The calls: >>> >>> SunToolkit.postPriorityEvent(fl); >>> >>> were originally wrong. This is an artefact of an old fix (5028014) >>> that has been rolled out, but went into jdk7 (with 6806217) by a >>> mistake. >>> The focus events should not be sent in prioritized order here. >>> >>> 8. TimedWindowEvent >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/TimedWindowEvent.java.html >>> >>> >>> >>> A WindowEvent with a time stamp. >>> >>> 9. SunToolkit >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/sun/awt/SunToolkit.java.sdiff.html >>> >>> >>> >>> WINDOW_LOST_FOCUS event's time stamp is registered. >>> >>> 10. WindowsRootPaneUI >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java.sdiff.html >>> >>> >>> >>> Skip menu activating events which weren't processed in time (while the >>> containing toplevel window is active). >>> >>> 11. awt_Window.cpp >>> >>> http://cr.openjdk.java.net/~ant/6981400/webrev.5/src/windows/native/sun/windows/awt_Window.cpp.sdiff.html >>> >>> >>> >>> Window focus events are supplied with a time stamp. >>> >>> - - - >>> Thanks, >>> Anton. >>> >> From anton.tarasov at oracle.com Fri Aug 31 05:33:16 2012 From: anton.tarasov at oracle.com (anton.tarasov at oracle.com) Date: Fri, 31 Aug 2012 12:33:16 +0000 Subject: hg: jdk8/awt/jdk: 6981400: Tabbing between textfield do not work properly when ALT+TAB; ... Message-ID: <20120831123337.2922A47836@hg.openjdk.java.net> Changeset: 0e007aa6f9db Author: ant Date: 2012-08-31 16:31 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0e007aa6f9db 6981400: Tabbing between textfield do not work properly when ALT+TAB 7157015: [macosx] Situation when KeyEventDispatcher doesn't work on AWT but does on Swing. 7121442: Regression : Reopen CR 6458497 still reproducible using JDK 7. Reviewed-by: art, leonidr ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/SequencedEvent.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/SunToolkit.java + src/share/classes/sun/awt/TimedWindowEvent.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/windows/native/sun/windows/awt_Window.cpp + test/java/awt/Focus/6981400/Test1.java + test/java/awt/Focus/6981400/Test2.java + test/java/awt/Focus/6981400/Test3.java From anthony.petrov at oracle.com Fri Aug 31 07:49:52 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 31 Aug 2012 18:49:52 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <503F9C79.2020104@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> <503DF844.302@oracle.com> <503DFB6A.6020209@oracle.com> <503E791E.90207@oracle.com> <503F688E.2090903@oracle.com> <503F9C79.2020104@oracle.com> Message-ID: <5040CF10.8030107@oracle.com> I think you should re-throw the InterruptedException caught at flush(). BTW, the flush() method can be invoked on a thread other than EDT (at least in theory). -- best regards, Anthony On 8/30/2012 9:01 PM, Oleg Pekhovskiy wrote: > Hi, > > I got another idea preparing the next version of fix. > > Previously we didn't catch InterruptedException and stack unwinding took > place right up to > try-catch section in EventDispatchThread.pumpOneEventForFilters(). > > So seems like it would be correct not eating that exception in > PostEventQueue.flush() > but just check the state using isInterrupted() method and add 'throws > InterruptedException' > to PostEventQueue.flush() and SunToolkit.flushPendingEvents() methods. > > Thoughts? > > Thanks, > Oleg > > 8/30/2012 5:20 PM, Anthony Petrov wrote: >> I see. After giving it more thought I don't see an easy solution for >> this issue, too. As long as we guarantee that the EDT is recreated >> should more events be posted, I don't see a big problem with this. So >> let's stick with the "Minimize..." approach then. >> >> -- >> best regards, >> Anthony >> >> On 08/30/12 00:18, Oleg Pekhovskiy wrote: >>> Hi Anthony, >>> >>> I see your concerns. >>> >>> As PostEventQueue.flush() method left unsynchronized, >>> we potentially could return PostEventQueue.noEvents() >>> and return check in EventQueue.detachDispatchThread() >>> back to the condition. >>> But is could increase the possibility of deadlock in future >>> (with PostEventQueue & pushPopLock). >>> >>> Artem, what do you think? >>> >>> Thanks, >>> Oleg >>> >>> 29.08.2012 15:22, Anthony Petrov wrote: >>>> On 8/29/2012 3:08 PM, Anthony Petrov wrote: >>>>> Hi Oleg, >>>>> >>>>> I'm still concerned about the following: >>>>> >>>>> detachDispatchThread() >>>>> { >>>>> flush(); >>>>> lock(); >>>>> // possibly detach >>>>> unlock(); >>>>> } >>>>> >>>>> at EventQueue.java. What if an even get posted to the queue after the >>>> >>>> A typo: s/even get/event gets/. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>>> flush() returns but before we even acquired the lock? We may still >>>>> end up with a situation when we detach the thread while in fact there >>>>> are some pending events present, which actually contradicts the >>>>> current logic of the detach() method. I see that you say "Minimize >>>>> discard possibility" in the comment instead of "Prevent ...", but I >>>>> feel uncomfortable with this actually. >>>>> >>>>> What exactly prevents us from adding some synchronization to ensure >>>>> that the detaching only happens when there's really no pending events? >>>>> >>>>> SunToolkit.java: >>>>>> 2120 Boolean b = isThreadLocalFlushing.get(); >>>>>> 2121 if (b != null && b) { >>>>>> 2122 return; >>>>>> 2123 } >>>>>> 2124 2125 isThreadLocalFlushing.set(true); >>>>>> 2126 try { >>>>> >>>>> How does access to the isThreadLocalFlushing synchronized? What >>>>> happens if the flush() is being invoked from two different threads >>>>> for the same post event queue? Why do we have two "isFlushing" flags? >>>>> Can we collapse them into one? Why is the isFlushing set/reset in two >>>>> disjunct synchronized(){} blocks? >>>>> >>>>> Overall, I find the current synchronization scheme in flush() very, >>>>> *very* (and I mean it) confusing. Can we simplify it somehow? >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: >>>>>> Hi Artem, Anthony, >>>>>> >>>>>> thank you for your proposals! >>>>>> >>>>>> We with Artem also had off-line discussion, >>>>>> so as a result I prepared improved version of fix: >>>>>> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ >>>>>> >>>>>> What was done: >>>>>> 1. EventQueue.detachDispatchThread(): moved >>>>>> SunToolkit.flushPnedingEvents() above the comments and added a >>>>>> separate comment to it. >>>>>> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to >>>>>> SunToolkit. Deleted SunToolkitSubclass. >>>>>> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name >>>>>> - isThreadLocalFlushing and made it ThreadLocal. >>>>>> 4. Left PostEventQueue.flush() unsynchronized and created >>>>>> wait()-notifyAll() synchronization mechanism to avoid blocking of >>>>>> PostEventQueue.postEvent(). >>>>>> >>>>>> Looking forward to your comments! >>>>>> >>>>>> Thanks, >>>>>> Oleg >>>>>> >>>>>> 20.08.2012 20:20, Artem Ananiev wrote: >>>>>>> Hi, Oleg, >>>>>>> >>>>>>> here are a few comments: >>>>>>> >>>>>>> 1. What is the reason of keeping "isFlushingPendingEvents" in >>>>>>> SunToolkit, given that PEQ.flush() is synchronized (and therefore >>>>>>> serialized) anyway? >>>>>>> >>>>>>> 2. flushPendingEvents(AppContext) may be moved directly to >>>>>>> SunToolkit, so we don't need a separate sun-class for that. >>>>>>> >>>>>>> 3. EQ.java:1035-1040 - this comment is obsolete and must be >>>>>>> replaced by another one. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Artem >>>>>>> >>>>>>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>>>>>>> Hi! >>>>>>>> >>>>>>>> Please review the fix for CR: >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ >>>>>>>> >>>>>>>> The following changes were made: >>>>>>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>>>>>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>>>>>>> 3. Added call of SunToolkit.flushPendingEvents() to >>>>>>>> EventQueue.detachDispatchThread(), >>>>>>>> right before pushPopLock.lock() >>>>>>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from >>>>>>>> EventQueue.detachDispatchThread() >>>>>>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & >>>>>>>> PostEventQueue.noEvents(); >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Oleg >>>>>>>> >>>>>> >>>>>> >>> > From anthony.petrov at oracle.com Fri Aug 31 07:55:50 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 31 Aug 2012 18:55:50 +0400 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <2227782.ivpGkXEkPi@cube.localdomain> References: <502E3DD1.9020604@oracle.com> <503DF844.302@oracle.com> <503F5F98.4020207@oracle.com> <2227782.ivpGkXEkPi@cube.localdomain> Message-ID: <5040D076.6090506@oracle.com> Hi Peter, Well, if an event is posted after the flush() call but before the lock() in detach(), two things may happen: 1. The event makes it to the event queue before detach() locks the pushPopLock. In which case the peekEvent() sees the event and prevents EDT detaching. 2. detach() takes the pushPopLock first, and hence the event is stuck in the PostEventQueue for a while. The EDT will be detached. However, once the lock is unlocked, the event will finally be delivered from PostEventQueue to the EventQueue, and the EDT must be re-created in this case to process the new event. So other than recreating the EDT on a new thread, it's not a big deal I think. -- best regards, Anthony On 8/31/2012 1:21 AM, Peter Levart wrote: > Hi Oleg, Artem an others > > > > If you are concerned about loosing events in > EventQueue.detachDispatchThread (a small window between returning from > SunToolkit.flushPendingEvents() and acquire-ing the pushPopLock) and can > add to SunToolkit an overloaded static flushPendingEvents method that > takes an aditional Runnable parameter called "afterFlushCallback", then > the pushPopLock guarded section of detachDispatchThread can be passed as > such afterFlushCallback to SunToolkit.flushPendingEvents. > > > > This way you reverse the order of locks and prevent dead-lock while > guarantee-ing that no events get discarded... > > > > Regards, Peter > > > > On Thursday, August 30, 2012 04:42:00 PM Artem Ananiev wrote: > > > Hi, Anthony, > > > > > > On 8/29/2012 3:08 PM, Anthony Petrov wrote: > > > > Hi Oleg, > > > > > > > > I'm still concerned about the following: > > > > > > > > detachDispatchThread() > > > > { > > > > flush(); > > > > lock(); > > > > // possibly detach > > > > unlock(); > > > > } > > > > > > > > at EventQueue.java. What if an even get posted to the queue after the > > > > flush() returns but before we even acquired the lock? We may still end > > > > up with a situation when we detach the thread while in fact there are > > > > some pending events present, which actually contradicts the current > > > > logic of the detach() method. I see that you say "Minimize discard > > > > possibility" in the comment instead of "Prevent ...", but I feel > > > > uncomfortable with this actually. > > > > > > yes, this is a known issue: we don't guarantee that no new events are > > > posted between flush() and lock(). If this happens, we'll re-create > > > event dispatch thread. > > > > > > > What exactly prevents us from adding some synchronization to ensure > that > > > > the detaching only happens when there's really no pending events? > > > > > > As Oleg wrote, this is exactly the deadlock we're trying to resolve. > > > EQ.detachDispatchThread() was the only place where the order of locks > > > was pushPopLock->flushLock, while in other cases we flush events without > > > pushPopLock. > > > > > > > SunToolkit.java: > > > >> 2120 Boolean b = isThreadLocalFlushing.get(); > > > >> 2121 if (b != null && b) { > > > >> 2122 return; > > > >> 2123 } > > > >> 2124 2125 isThreadLocalFlushing.set(true); > > > >> 2126 try { > > > > > > > > How does access to the isThreadLocalFlushing synchronized? What happens > > > > if the flush() is being invoked from two different threads for the same > > > > post event queue? Why do we have two "isFlushing" flags? Can we > collapse > > > > them into one? Why is the isFlushing set/reset in two disjunct > > > > synchronized(){} blocks? > > > > > > As David correctly wrote, isThreadLocalFlushing is a ThreadLocal object, > > > which is thread-safe. isFlushing is used to synchronize access from > > > multiple threads, isThreadLockFlushing is to prevent EQ.postEvent() to > > > be called recursively. > > > > > > The only valid comment is that isThreadLocalFlushing should be set to > > > false in the "finally" block. Oleg will include this change into the > > > next version of the fix. > > > > > > > Overall, I find the current synchronization scheme in flush() very, > > > > *very* (and I mean it) confusing. Can we simplify it somehow? > > > > > > The current Oleg's fix is the simplest yet (almost) backwards compatible > > > solution we've found. If you have another ideas, please, let us know :) > > > > > > Thanks, > > > > > > Artem > > > > > > > -- > > > > best regards, > > > > Anthony > > > > > > > > On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: > > > >> Hi Artem, Anthony, > > > >> > > > >> thank you for your proposals! > > > >> > > > >> We with Artem also had off-line discussion, > > > >> so as a result I prepared improved version of fix: > > > >> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ > > > >> > > > >> What was done: > > > >> 1. EventQueue.detachDispatchThread(): moved > > > >> SunToolkit.flushPnedingEvents() above the comments and added a > > > >> separate comment to it. > > > >> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to > > > >> SunToolkit. Deleted SunToolkitSubclass. > > > >> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - > > > >> isThreadLocalFlushing and made it ThreadLocal. > > > >> 4. Left PostEventQueue.flush() unsynchronized and created > > > >> wait()-notifyAll() synchronization mechanism to avoid blocking of > > > >> PostEventQueue.postEvent(). > > > >> > > > >> Looking forward to your comments! > > > >> > > > >> Thanks, > > > >> Oleg > > > >> > > > >> 20.08.2012 20:20, Artem Ananiev wrote: > > > >>> Hi, Oleg, > > > >>> > > > >>> here are a few comments: > > > >>> > > > >>> 1. What is the reason of keeping "isFlushingPendingEvents" in > > > >>> SunToolkit, given that PEQ.flush() is synchronized (and therefore > > > >>> serialized) anyway? > > > >>> > > > >>> 2. flushPendingEvents(AppContext) may be moved directly to > > > >>> SunToolkit, so we don't need a separate sun-class for that. > > > >>> > > > >>> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced > > > >>> by another one. > > > >>> > > > >>> Thanks, > > > >>> > > > >>> Artem > > > >>> > > > >>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: > > > >>>> Hi! > > > >>>> > > > >>>> Please review the fix for CR: > > > >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 > > > >>>> > > > >>>> Webrev: > > > >>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ > > > >>>> > > > >>>> The following changes were made: > > > >>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() > > > >>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back > > > >>>> 3. Added call of SunToolkit.flushPendingEvents() to > > > >>>> EventQueue.detachDispatchThread(), > > > >>>> right before pushPopLock.lock() > > > >>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from > > > >>>> EventQueue.detachDispatchThread() > > > >>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & > > > >>>> PostEventQueue.noEvents(); > > > >>>> > > > >>>> Thanks, > > > >>>> Oleg > > > >>>> > From scott.kovatch at oracle.com Fri Aug 31 10:45:18 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 31 Aug 2012 10:45:18 -0700 Subject: Review: Remove private API from graphics code Message-ID: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> http://cr.openjdk.java.net/~skovatch/7187834/webrev.00/ This is based on the patch submitted by Marco Dinacci. I had to modify it a bit to get it to compile against 7u-dev, but nothing major. The changes in ImageSurfaceData.h were needed as a result of my use of Xcode 4.4.1 on Mountain Lion. I ran the Java2Demo and don't see any problems. I paid close attention to the Images tab, since it looks like this code is heavily used by it. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120831/29c311a1/attachment.html From peter.levart at gmail.com Fri Aug 31 11:10:29 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 31 Aug 2012 20:10:29 +0200 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <5040CF10.8030107@oracle.com> References: <502E3DD1.9020604@oracle.com> <503263C9.4080206@oracle.com> <503CD6AA.5030005@oracle.com> <503DF844.302@oracle.com> <503DFB6A.6020209@oracle.com> <503E791E.90207@oracle.com> <503F688E.2090903@oracle.com> <503F9C79.2020104@oracle.com> <5040CF10.8030107@oracle.com> Message-ID: When you catch InterruptedException, you must do one of 3 things: 1 - handle it 2 - rethrow it 3 - re-assert thread interrupted status (Thread.currentThread().interrupt()) so that it will be thrown at some other (more appropriate) place/time. So if you don't want to complicate code and API to do 2, you can do 3. Regards, Peter On Aug 31, 2012 4:50 PM, "Anthony Petrov" wrote: > I think you should re-throw the InterruptedException caught at flush(). > BTW, the flush() method can be invoked on a thread other than EDT (at least > in theory). > > -- > best regards, > Anthony > > On 8/30/2012 9:01 PM, Oleg Pekhovskiy wrote: > >> Hi, >> >> I got another idea preparing the next version of fix. >> >> Previously we didn't catch InterruptedException and stack unwinding took >> place right up to >> try-catch section in EventDispatchThread.**pumpOneEventForFilters(). >> >> So seems like it would be correct not eating that exception in >> PostEventQueue.flush() >> but just check the state using isInterrupted() method and add 'throws >> InterruptedException' >> to PostEventQueue.flush() and SunToolkit.flushPendingEvents(**) methods. >> >> Thoughts? >> >> Thanks, >> Oleg >> >> 8/30/2012 5:20 PM, Anthony Petrov wrote: >> >>> I see. After giving it more thought I don't see an easy solution for >>> this issue, too. As long as we guarantee that the EDT is recreated should >>> more events be posted, I don't see a big problem with this. So let's stick >>> with the "Minimize..." approach then. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 08/30/12 00:18, Oleg Pekhovskiy wrote: >>> >>>> Hi Anthony, >>>> >>>> I see your concerns. >>>> >>>> As PostEventQueue.flush() method left unsynchronized, >>>> we potentially could return PostEventQueue.noEvents() >>>> and return check in EventQueue.**detachDispatchThread() >>>> back to the condition. >>>> But is could increase the possibility of deadlock in future >>>> (with PostEventQueue & pushPopLock). >>>> >>>> Artem, what do you think? >>>> >>>> Thanks, >>>> Oleg >>>> >>>> 29.08.2012 15:22, Anthony Petrov wrote: >>>> >>>>> On 8/29/2012 3:08 PM, Anthony Petrov wrote: >>>>> >>>>>> Hi Oleg, >>>>>> >>>>>> I'm still concerned about the following: >>>>>> >>>>>> detachDispatchThread() >>>>>> { >>>>>> flush(); >>>>>> lock(); >>>>>> // possibly detach >>>>>> unlock(); >>>>>> } >>>>>> >>>>>> at EventQueue.java. What if an even get posted to the queue after the >>>>>> >>>>> >>>>> A typo: s/even get/event gets/. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> flush() returns but before we even acquired the lock? We may still >>>>>> end up with a situation when we detach the thread while in fact there >>>>>> are some pending events present, which actually contradicts the >>>>>> current logic of the detach() method. I see that you say "Minimize >>>>>> discard possibility" in the comment instead of "Prevent ...", but I >>>>>> feel uncomfortable with this actually. >>>>>> >>>>>> What exactly prevents us from adding some synchronization to ensure >>>>>> that the detaching only happens when there's really no pending events? >>>>>> >>>>>> SunToolkit.java: >>>>>> >>>>>>> 2120 Boolean b = isThreadLocalFlushing.get(); >>>>>>> 2121 if (b != null && b) { >>>>>>> 2122 return; >>>>>>> 2123 } >>>>>>> 2124 2125 isThreadLocalFlushing.set(**true); >>>>>>> 2126 try { >>>>>>> >>>>>> >>>>>> How does access to the isThreadLocalFlushing synchronized? What >>>>>> happens if the flush() is being invoked from two different threads >>>>>> for the same post event queue? Why do we have two "isFlushing" flags? >>>>>> Can we collapse them into one? Why is the isFlushing set/reset in two >>>>>> disjunct synchronized(){} blocks? >>>>>> >>>>>> Overall, I find the current synchronization scheme in flush() very, >>>>>> *very* (and I mean it) confusing. Can we simplify it somehow? >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: >>>>>> >>>>>>> Hi Artem, Anthony, >>>>>>> >>>>>>> thank you for your proposals! >>>>>>> >>>>>>> We with Artem also had off-line discussion, >>>>>>> so as a result I prepared improved version of fix: >>>>>>> http://cr.openjdk.java.net/~**bagiras/8/7186109.3/ >>>>>>> >>>>>>> What was done: >>>>>>> 1. EventQueue.**detachDispatchThread(): moved >>>>>>> SunToolkit.flushPnedingEvents(**) above the comments and added a >>>>>>> separate comment to it. >>>>>>> 2. Moved SunToolkitSubclass.**flushPendingEvents(AppContext) method >>>>>>> to >>>>>>> SunToolkit. Deleted SunToolkitSubclass. >>>>>>> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name >>>>>>> - isThreadLocalFlushing and made it ThreadLocal. >>>>>>> 4. Left PostEventQueue.flush() unsynchronized and created >>>>>>> wait()-notifyAll() synchronization mechanism to avoid blocking of >>>>>>> PostEventQueue.postEvent(). >>>>>>> >>>>>>> Looking forward to your comments! >>>>>>> >>>>>>> Thanks, >>>>>>> Oleg >>>>>>> >>>>>>> 20.08.2012 20:20, Artem Ananiev wrote: >>>>>>> >>>>>>>> Hi, Oleg, >>>>>>>> >>>>>>>> here are a few comments: >>>>>>>> >>>>>>>> 1. What is the reason of keeping "isFlushingPendingEvents" in >>>>>>>> SunToolkit, given that PEQ.flush() is synchronized (and therefore >>>>>>>> serialized) anyway? >>>>>>>> >>>>>>>> 2. flushPendingEvents(AppContext) may be moved directly to >>>>>>>> SunToolkit, so we don't need a separate sun-class for that. >>>>>>>> >>>>>>>> 3. EQ.java:1035-1040 - this comment is obsolete and must be >>>>>>>> replaced by another one. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Artem >>>>>>>> >>>>>>>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: >>>>>>>> >>>>>>>>> Hi! >>>>>>>>> >>>>>>>>> Please review the fix for CR: >>>>>>>>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7186109 >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~**bagiras/8/7186109.1/ >>>>>>>>> >>>>>>>>> The following changes were made: >>>>>>>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() >>>>>>>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back >>>>>>>>> 3. Added call of SunToolkit.flushPendingEvents(**) to >>>>>>>>> EventQueue.**detachDispatchThread(), >>>>>>>>> right before pushPopLock.lock() >>>>>>>>> 4. Removed !SunToolkit.**isPostEventQueueEmpty() check from >>>>>>>>> EventQueue.**detachDispatchThread() >>>>>>>>> 5. Removed SunToolkit.**isPostEventQueueEmpty() & >>>>>>>>> PostEventQueue.noEvents(); >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Oleg >>>>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120831/c597697c/attachment.html From philip.race at oracle.com Fri Aug 31 11:16:27 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 31 Aug 2012 11:16:27 -0700 Subject: Review: Remove private API from graphics code In-Reply-To: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> References: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> Message-ID: <5040FF7B.4030106@oracle.com> Scott, These files were added by Bino to support printing. Quartz isn't used except for printing in JDK 7, so as I understand it, testing on-screen in Java2Demo should not exercise this code. I'm surprised that you saw it being exercised. Did you do any printing testing ? The matrix inversion seems unlikely to be applied to any non-invertible matrices, so that's fine, but I wonder if you have lost precision here due to floating point inaccuracies ? If you originally had a simple scale or identity, rotated it, and then applied the inverse to unrotate it, do you really end up with exactly the same results. The more you do this the more inaccuracies creep in, which may be part of the reason for the original approach. I find it a little hard to believe that there isn't a direct public way to restore a transform. The changes for mountain lion are safe for snow leopard I presume? I believe the builds still happen on snow leopard. Also this should have been sent to 2d-dev, not awt-dev. These files, APIs, and printing are all 2D, not awt. -phil. I am not sure why they are not used but it On 8/31/2012 10:45 AM, Scott Kovatch wrote: > http://cr.openjdk.java.net/~skovatch/7187834/webrev.00/ > > This is based on the patch submitted by Marco Dinacci. I had to modify it a bit to get it to compile against 7u-dev, but nothing major. > > The changes in ImageSurfaceData.h were needed as a result of my use of Xcode 4.4.1 on Mountain Lion. > > I ran the Java2Demo and don't see any problems. I paid close attention to the Images tab, since it looks like this code is heavily used by it. > > -- Scott K. > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > > From peter.levart at gmail.com Fri Aug 31 11:22:51 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 31 Aug 2012 20:22:51 +0200 Subject: [8] Review request for 7186109: Simplify lock machinery for PostEventQueue & EventQueue In-Reply-To: <5040996D.50709@oracle.com> References: <502E3DD1.9020604@oracle.com> <503F5F98.4020207@oracle.com> <7969013.t7YTOqxCuf@cube.localdomain> <2253829.ClliP5V5Oi@cube.localdomain> <5040996D.50709@oracle.com> Message-ID: But haven't we started with the synchronized flush at the beginning and only did that to prevent a deadlock? In any case, it's better not to block toolkit thread. Regards, Peter On Aug 31, 2012 1:01 PM, "Oleg Pekhovskiy" wrote: > Hi Peter, > > making PostEventQueue.flush() method 'synchronized' will block Toolkit > thread during PostEventQueue.postEvent() > call, that is bad. In our case synchronization monitor is released on > wait(), thus no blocking occurs. > > Thanks, > Oleg > > 31.08.2012 1:01, Peter Levart wrote: > > If I'm right, then instead of using thread-local flag for > recursion-prevention, you can just re-instate a boolean flag: > > > > > > private boolean isFlushing = false; > > > > public synchronized void flush() { > > if (isFlushing) { > > // every EventQueue.postEvent calls us back - prevent recursion > > return; > > } > > > > isFlushing = true; > > > > try { > > EventQueueItem tempQueue = queueHead; > > queueHead = queueTail = null; > > while (tempQueue != null) { > > eventQueue.postEvent(tempQueue.event); > > tempQueue = tempQueue.next; > > } > > } > > } > > finally { > > isFlushing = false; > > } > > } > > > > > > > > Regards, Peter > > > > On Thursday, August 30, 2012 10:39:03 PM Peter Levart wrote: > > Hi Oleg, > > > > Now that SunToolkit is never called from EventQueue while holding > pushPopLock (not even from detatchDispatchThread - I saw you removed > SunToolkit.isPostEventQueueEmpty() check), there's no need for flushing > loop in PostEventQueue not to be simply synchronized again and be done with > InterruptedExceptions and handlers, Am I right? > > > > Regards, Peter > > > > On Thursday, August 30, 2012 04:42:00 PM Artem Ananiev wrote: > > > Hi, Anthony, > > > > > > On 8/29/2012 3:08 PM, Anthony Petrov wrote: > > > > Hi Oleg, > > > > > > > > I'm still concerned about the following: > > > > > > > > detachDispatchThread() > > > > { > > > > flush(); > > > > lock(); > > > > // possibly detach > > > > unlock(); > > > > } > > > > > > > > at EventQueue.java. What if an even get posted to the queue after the > > > > flush() returns but before we even acquired the lock? We may still end > > > > up with a situation when we detach the thread while in fact there are > > > > some pending events present, which actually contradicts the current > > > > logic of the detach() method. I see that you say "Minimize discard > > > > possibility" in the comment instead of "Prevent ...", but I feel > > > > uncomfortable with this actually. > > > > > > yes, this is a known issue: we don't guarantee that no new events are > > > posted between flush() and lock(). If this happens, we'll re-create > > > event dispatch thread. > > > > > > > What exactly prevents us from adding some synchronization to ensure > that > > > > the detaching only happens when there's really no pending events? > > > > > > As Oleg wrote, this is exactly the deadlock we're trying to resolve. > > > EQ.detachDispatchThread() was the only place where the order of locks > > > was pushPopLock->flushLock, while in other cases we flush events without > > > pushPopLock. > > > > > > > SunToolkit.java: > > > >> 2120 Boolean b = isThreadLocalFlushing.get(); > > > >> 2121 if (b != null && b) { > > > >> 2122 return; > > > >> 2123 } > > > >> 2124 2125 isThreadLocalFlushing.set(true); > > > >> 2126 try { > > > > > > > > How does access to the isThreadLocalFlushing synchronized? What happens > > > > if the flush() is being invoked from two different threads for the same > > > > post event queue? Why do we have two "isFlushing" flags? Can we > collapse > > > > them into one? Why is the isFlushing set/reset in two disjunct > > > > synchronized(){} blocks? > > > > > > As David correctly wrote, isThreadLocalFlushing is a ThreadLocal object, > > > which is thread-safe. isFlushing is used to synchronize access from > > > multiple threads, isThreadLockFlushing is to prevent EQ.postEvent() to > > > be called recursively. > > > > > > The only valid comment is that isThreadLocalFlushing should be set to > > > false in the "finally" block. Oleg will include this change into the > > > next version of the fix. > > > > > > > Overall, I find the current synchronization scheme in flush() very, > > > > *very* (and I mean it) confusing. Can we simplify it somehow? > > > > > > The current Oleg's fix is the simplest yet (almost) backwards compatible > > > solution we've found. If you have another ideas, please, let us know :) > > > > > > Thanks, > > > > > > Artem > > > > > > > -- > > > > best regards, > > > > Anthony > > > > > > > > On 8/28/2012 6:33 PM, Oleg Pekhovskiy wrote: > > > >> Hi Artem, Anthony, > > > >> > > > >> thank you for your proposals! > > > >> > > > >> We with Artem also had off-line discussion, > > > >> so as a result I prepared improved version of fix: > > > >> http://cr.openjdk.java.net/~bagiras/8/7186109.3/ > > > >> > > > >> What was done: > > > >> 1. EventQueue.detachDispatchThread(): moved > > > >> SunToolkit.flushPnedingEvents() above the comments and added a > > > >> separate comment to it. > > > >> 2. Moved SunToolkitSubclass.flushPendingEvents(AppContext) method to > > > >> SunToolkit. Deleted SunToolkitSubclass. > > > >> 3. Moved isFlushingPendingEvents to PostEventQueue with the new name - > > > >> isThreadLocalFlushing and made it ThreadLocal. > > > >> 4. Left PostEventQueue.flush() unsynchronized and created > > > >> wait()-notifyAll() synchronization mechanism to avoid blocking of > > > >> PostEventQueue.postEvent(). > > > >> > > > >> Looking forward to your comments! > > > >> > > > >> Thanks, > > > >> Oleg > > > >> > > > >> 20.08.2012 20:20, Artem Ananiev wrote: > > > >>> Hi, Oleg, > > > >>> > > > >>> here are a few comments: > > > >>> > > > >>> 1. What is the reason of keeping "isFlushingPendingEvents" in > > > >>> SunToolkit, given that PEQ.flush() is synchronized (and therefore > > > >>> serialized) anyway? > > > >>> > > > >>> 2. flushPendingEvents(AppContext) may be moved directly to > > > >>> SunToolkit, so we don't need a separate sun-class for that. > > > >>> > > > >>> 3. EQ.java:1035-1040 - this comment is obsolete and must be replaced > > > >>> by another one. > > > >>> > > > >>> Thanks, > > > >>> > > > >>> Artem > > > >>> > > > >>> On 8/17/2012 4:49 PM, Oleg Pekhovskiy wrote: > > > >>>> Hi! > > > >>>> > > > >>>> Please review the fix for CR: > > > >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186109 > > > >>>> > > > >>>> Webrev: > > > >>>> http://cr.openjdk.java.net/~bagiras/8/7186109.1/ > > > >>>> > > > >>>> The following changes were made: > > > >>>> 1. Removed flushLock from SunToolkit.flushPendingEvent() > > > >>>> 2. Returned method PostEventQueue.flush() as 'synchronized' back > > > >>>> 3. Added call of SunToolkit.flushPendingEvents() to > > > >>>> EventQueue.detachDispatchThread(), > > > >>>> right before pushPopLock.lock() > > > >>>> 4. Removed !SunToolkit.isPostEventQueueEmpty() check from > > > >>>> EventQueue.detachDispatchThread() > > > >>>> 5. Removed SunToolkit.isPostEventQueueEmpty() & > > > >>>> PostEventQueue.noEvents(); > > > >>>> > > > >>>> Thanks, > > > >>>> Oleg > > > >>>> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120831/ca34262a/attachment.html From philip.race at oracle.com Fri Aug 31 11:50:34 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 31 Aug 2012 11:50:34 -0700 Subject: Review: Remove private API from graphics code In-Reply-To: <5040FF7B.4030106@oracle.com> References: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> <5040FF7B.4030106@oracle.com> Message-ID: <5041077A.7080002@oracle.com> The recommendation is to restore the graphics state rather than inverting :- https://developer.apple.com/library/mac/#documentation/graphicsimaging/conceptual/drawingwithquartz2d/dq_affine/dq_affine.html "Quartz also provides an affine transform function that inverts a matrix, |CGAffineTransformInvert|. Inversion is generally used to provide reverse transformation of points within transformed objects. Inversion can be useful when you need to recover a value that has been transformed by a matrix: Invert the matrix, and multiply the value by the inverted matrix, and the result is the original value. You usually don?t need to invert transforms because you can reverse the effects of transforming the CTM by saving and restoring the graphics state." -phil. On 8/31/2012 11:16 AM, Phil Race wrote: > Scott, > > These files were added by Bino to support printing. Quartz isn't used > except for printing in JDK 7, so as I understand it, testing on-screen in > Java2Demo should not exercise this code. I'm surprised that you saw > it being exercised. Did you do any printing testing ? > > The matrix inversion seems unlikely to be applied to any non-invertible > matrices, so that's fine, but I wonder if you have lost precision here > due to floating point inaccuracies ? > > If you originally had a simple scale or identity, rotated it, and then > applied the inverse to unrotate it, do you really end up with exactly > the same results. The more you do this the more inaccuracies creep in, > which may be part of the reason for the original approach. > I find it a little hard to believe that there isn't a direct public > way to > restore a transform. > > The changes for mountain lion are safe for snow leopard I presume? > I believe the builds still happen on snow leopard. > > Also this should have been sent to 2d-dev, not awt-dev. > These files, APIs, and printing are all 2D, not awt. > > -phil. > > I am not sure why they are not used but it > On 8/31/2012 10:45 AM, Scott Kovatch wrote: >> http://cr.openjdk.java.net/~skovatch/7187834/webrev.00/ >> >> This is based on the patch submitted by Marco Dinacci. I had to >> modify it a bit to get it to compile against 7u-dev, but nothing major. >> >> The changes in ImageSurfaceData.h were needed as a result of my use >> of Xcode 4.4.1 on Mountain Lion. >> >> I ran the Java2Demo and don't see any problems. I paid close >> attention to the Images tab, since it looks like this code is heavily >> used by it. >> >> -- Scott K. >> >> ---------------------------------------- >> Scott Kovatch >> scott.kovatch at oracle.com >> Santa Clara/Pleasanton, CA >> >> > From scott.kovatch at oracle.com Fri Aug 31 11:57:39 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Fri, 31 Aug 2012 11:57:39 -0700 Subject: Review: Remove private API from graphics code In-Reply-To: <5040FF7B.4030106@oracle.com> References: <0D0AC79D-BF87-44B0-BEE7-ACF1FFFE6D75@oracle.com> <5040FF7B.4030106@oracle.com> Message-ID: <37D89CC9-5CB7-46CC-AFBA-7A7E0643A917@oracle.com> On Aug 31, 2012, at 11:16 AM, Phil Race wrote: > Scott, > > These files were added by Bino to support printing. Quartz isn't used > except for printing in JDK 7, so as I understand it, testing on-screen in > Java2Demo should not exercise this code. I'm surprised that you saw > it being exercised. Did you do any printing testing ? I tried printing from the 2d demo, and now I'm not so sure about the changes. I printed one image and it was inverted. :-\ > The matrix inversion seems unlikely to be applied to any non-invertible > matrices, so that's fine, but I wonder if you have lost precision here > due to floating point inaccuracies ? I have to admit that I didn't go that deep into the code, since the main purpose of the changes were to get rid of the private API so we could submit something to the OS X app store. > If you originally had a simple scale or identity, rotated it, and then > applied the inverse to unrotate it, do you really end up with exactly > the same results. The more you do this the more inaccuracies creep in, > which may be part of the reason for the original approach. > I find it a little hard to believe that there isn't a direct public way to > restore a transform. I was surprised by that, too, but for what it's worth CGContextSave/RestoreGState save and restore the current transform. I didn't dig deeply enough to see if they could/should be used instead. > The changes for mountain lion are safe for snow leopard I presume? > I believe the builds still happen on snow leopard. I would think so, yes. I'm replacing private API with long-available public API. The core JDK builds on Lion due to the need for APIs that arrived in 10.7.3. > Also this should have been sent to 2d-dev, not awt-dev. > These files, APIs, and printing are all 2D, not awt. Okay. I didn't realize Quartz was only being used in printing, though in retrospect that makes sense now. I see you moved the bug already. -- Scott K.