From artem.ananiev at oracle.com Mon Jul 2 11:41:43 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 02 Jul 2012 22:41:43 +0400 Subject: deadlock involving a mutex Lock from java.awt.EventQueue and SunToolkit.PostEventQueue In-Reply-To: <1613204.D0BHuDS9Cs@cube.localdomain> References: <1613204.D0BHuDS9Cs@cube.localdomain> Message-ID: <4FF1EB67.8060801@oracle.com> Hi, Peter, this issue, originally posted to NetBeans bugzilla, is tracked as 7159230 at bugs.sun.com: http://bugs.sun.com/view_bug.do?bug_id=7159230 The reason of the deadlock is clear, but the scenario to reproduce it is unknown. As I wrote in the evaluation, it's very weird to have a call to EQ.detachDispatchThread() on NetBeans startup. That's why the bug is still open (but AWT team is going to fix it anyway, just the priority is not very high). Do you have a test case to reproduce it? Thanks, Artem On 6/28/2012 11:33 AM, Peter Levart wrote: > This started as a bug report on the NetBeans bugzila: > > http://netbeans.org/bugzilla/show_bug.cgi?id=214872 > > But is seems that it is caused by synchronization changes to > java.awt.EventQueue in JDK 1.7 (JDK 1.6 seems not to be affected). > > To quote the part of the NetBeans bug: > > I think that the root of the problem is in JDK 1.7, namely in the method: > > java.awt.EventQueue.detachDispatchThread > > ...where it calls SunToolkit.isPostEventQueueEmpty() while holding global > "pushPopLock". > > The static method SunToolkit.isPostEventQueueEmpty() invokes a synchronized > method on a singleton PostEventQueue object. Also other methods on this > singleton PostEventQueue are synchronized and some of them (for example > PostEventQueue.flush() invoked from static SunToolkit.flushPendingEvents()) are > also synchronized and call into the java.awt.EventQueue which tries to get the > global "pushPopLock" - hence the deadlock. > > SunToolkit.isPostEventQueueEmpty() (or any of it's methods that delegate to > PostEventQueue singleton) should not be called while holding global > "pushPopLock" in java.awt.EventQueue... > > My proposal to fix this bug is to rewrite the SunToolkit.PostEventQueue to use > the same global "pushPopLock" Lock instance that java.awt.EnetQueue uses for > it's synchronization instead of "synchronized" instance methods... > > > Regards, Peter > From artem.ananiev at oracle.com Mon Jul 2 11:58:33 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 02 Jul 2012 22:58:33 +0400 Subject: wrong logic to prevent recursion in SunToolkit.flushPendingEvents() In-Reply-To: <2272071.ve8hAvjk3h@cube.localdomain> References: <2270455.lkjLBiTOsh@cube.localdomain> <2272071.ve8hAvjk3h@cube.localdomain> Message-ID: <4FF1EF59.6090400@oracle.com> Hi, Peter, thanks for reporting this issue, it's clearly a bug in SunToolkit. I think it will be fixed as a part of 7159230. See more comments below. On 6/28/2012 11:53 AM, Peter Levart wrote: > Also, this is another spot that uses it's own synchronizer to serialize access > and calls into the PostEventQueue which is also synchronized (currently by > using synchronized methods but as I proposed in a previous message "deadlock > involving ..." could be using a global mutex) so it is prone to deadlock > "bugs". > > I would rather use a ThreadLocal flag here to prevent re-entrancy from the same > thread. Multiple threads can enter flushPendingEvents() with no danger since > PostEventQueue.flush() is already synchronized. flushPendingEvents() is not called from PostEventQueue.flush(). Instead, it's mostly called from EventQueue to make sure all the already posted events are processed. That's why we need synchronization in flushPendingEvents(). > For example like this: > > private static final ThreadLocal isFlushingPendingEvents = > new ThreadLocal(); > > /* > * Flush any pending events which haven't been posted to the AWT > * EventQueue yet. > */ > public static void flushPendingEvents() { > boolean wasFlushing = isFlushingPendingEvents.get() != null; > try { Here the thread may be interrupted, and "wasFlushing" may become stale. > // Don't call flushPendingEvents() recursively > if (!wasFlushing) { > isFlushingPendingEvents.set(true); > AppContext appContext = AppContext.getAppContext(); > PostEventQueue postEventQueue = > (PostEventQueue)appContext.get(POST_EVENT_QUEUE_KEY); > if (postEventQueue != null) { > postEventQueue.flush(); > } > } > } finally { > if (!wasFlushing) isFlushingPendingEvents.remove(); > } > } The easiest fix can be to check "isFlushingPendingEvents" in the beginning of the method: flushLock.lock(); boolean wasFlushing = isFlushingPendingEvents; try { // Don't call flushPendingEvents() recursively if (!isFlushingPendingEvents) { and rewrite the "finally" block: } finally { if (!wasFlushing) { isFlushingPendingEvents = false; } flushLock.unlock(); } But a better fix would be to get rid of the separate lock (flushLock) and use the one from EventQueue (pushPopLock). It's not as trivial as it seems to be, EventQueue and SunToolkit are in different packages, but definitely doable. Thanks, Artem > Peter > > On Thursday, June 28, 2012 09:36:08 AM Peter Levart wrote: >> While looking at the SunToolkit code I spoted another bug. The following >> code: >> >> >> private static final Lock flushLock = new ReentrantLock(); >> private static boolean isFlushingPendingEvents = false; >> >> /* >> * Flush any pending events which haven't been posted to the AWT >> * EventQueue yet. >> */ >> public static void flushPendingEvents() { >> flushLock.lock(); >> try { >> // Don't call flushPendingEvents() recursively >> if (!isFlushingPendingEvents) { >> isFlushingPendingEvents = true; >> AppContext appContext = AppContext.getAppContext(); >> PostEventQueue postEventQueue = >> (PostEventQueue)appContext.get(POST_EVENT_QUEUE_KEY); >> if (postEventQueue != null) { >> postEventQueue.flush(); >> } >> } >> } finally { >> isFlushingPendingEvents = false; >> flushLock.unlock(); >> } >> } >> >> >> ... is clearly wrong. The isFlushingPendingEvents flag is reset in finally >> block regardless of whether it was true or false at the entry to the try >> block. >> >> The 1st nested call to flushPendingEvents() prevents recursion but it also >> resets the flag so that the second nested call is allowed... >> >> >> >> Regards, Peter From artem.ananiev at oracle.com Mon Jul 2 12:03:20 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 02 Jul 2012 23:03:20 +0400 Subject: [8] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FED9EC8.3080508@oracle.com> References: <4FCCD91B.30503@oracle.com> <4FD895F1.3040605@oracle.com> <4FE8407C.7060103@oracle.com> <4FE880D0.3080108@oracle.com> <4FEC7ABC.8070302@oracle.com> <4FED9EC8.3080508@oracle.com> Message-ID: <4FF1F078.2090409@oracle.com> On 6/29/2012 4:25 PM, Anthony Petrov wrote: > Hi Sergey, > > The fix looks good. +1. > Btw, if you set a shape to a frame, will the Frame.printAll() use the > shape correctly? E.g. an ellipse-shaped window must be printed as an > ellipse. The parts laying outside of the shape shouldn't be printed. It's a separate issue. Sergey, could you file a new bug, please? Thanks, Artem > -- > best regards, > Anthony > > On 6/28/2012 7:39 PM, Sergey Bylokhov wrote: >> Hi Artem, Anthony. >> Updated webrev. >> http://cr.openjdk.java.net/~serb/7124244/webrev.04/ >> - CPlatformEmbeddedFrame now use correct backbuffer. >> - For simplification, creation of the backbuffer was reverted back. >> >> 25.06.2012 19:16, Artem Ananiev wrote: >>> Hi, Sergey, >>> >>> a few minor comments: >>> >>> 1. CPlatformWindow.java: invalidateShadow() in native is ready to be >>> called on any thread, so what's the reason behind invokeLater() here? >>> >>> 2. RepaintManager.java: the new field should better be named >>> "volatileBufferType". >>> >>> 3. LWComponentPeer.applyShape() is a peer method, which accepts >>> user-supplied object (right now it's constructed from Shape in AWT >>> internal code, but nothing prevents users from calling this method >>> directly), so it should be stored as a copy, not as a reference. >>> >>> Thanks, >>> >>> Artem >>> >>> On 6/25/2012 2:42 PM, Sergey Bylokhov wrote: >>>> Hi, Artem, Anthony. >>>> New version of the fix: >>>> http://cr.openjdk.java.net/~serb/7124244/webrev.01 >>>> >>>> 13.06.2012 06:30, Artem Ananiev wrote: >>>>> Hi, Sergey, >>>>> >>>>> a few minor comments: >>>>> >>>>> 1. There is no need in AWT_ASSERT_[NOT]_APPKIT_THREAD macros in >>>>> CPlatformWindow.nativeRevalidateNSWindowShadow(), since there are >>>>> corresponding checks just above. >>>> done. >>>>> >>>>> 2. invalidateShadow() is not used in sun.lwawt, so it can be just a >>>>> method in CPlatformWindow. BTW, do you have any ideas, why CGLayer >>>>> holds a reference to LWWindowPeer, not to CPlatformWindow? >>>> done. >>>>> >>>>> 3. As we don't expect isSwingBackbufferTranslucencySupported() to >>>>> return different values, it would be fine to call it only once to >>>>> avoid possible perf regressions. >>>> done. >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 6/4/2012 7:49 PM, Sergey Bylokhov wrote: >>>>>> Hi Everyone, >>>>>> Please review the fix. >>>>>> >>>>>> Shaped window was implemented as a translucent window with >>>>>> constrained >>>>>> graphics. Now translucent window doesn't use separate >>>>>> BufferedImage as a >>>>>> back buffer. Also alpha value for the swing back buffer was >>>>>> enabled(Shared code changed). >>>>>> Note that shaped windows are affected by this bugs: >>>>>> http://monaco.us.oracle.com/detail.jsf?cr=7124236 >>>>>> - Shadows disappear. >>>>>> - Transparent areas aren't transparent to mouse clicks. >>>>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7172431 >>>>>> - Opacity does not work for non opaque windows. >>>>>> >>>>>> Any suggestions are welcome. >>>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 >>>>>> Webrev can be found at: >>>>>> http://cr.openjdk.java.net/~serb/7124244/webrev.00 >>>>>> >>>> >>>> >> >> From artem.ananiev at oracle.com Mon Jul 2 12:23:38 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 02 Jul 2012 23:23:38 +0400 Subject: [8] Review request for 6868690 TEST: java/awt/FontClass/CreateFont/BigFont.java test should be modified in jdk7&8 to run via jtreg In-Reply-To: <4FD882F5.7030907@oracle.com> References: <4FC7793C.8020105@oracle.com> <4FCCB717.1070706@oracle.com> <4FCCD523.1080709@oracle.com> <4FD1C3B9.2050004@oracle.com> <4FD1D9F4.2020600@oracle.com> <4FD1EB01.2000907@oracle.com> <4FD882F5.7030907@oracle.com> Message-ID: <4FF1F53A.7020209@oracle.com> Hi, Konstantin, see my comments inline. On 6/13/2012 4:09 PM, Konstantin Shefov wrote: > Hello, > > I have decided to remove bigfont.html and turn an applet test into main > test, because applet test always fails with timeout. Could you clarify, how changing applet->main helps with the timeout? If the test should be run with a greater timeout, it can be specified as a modifier of @run tag. In the current version of the fix, BigFont.runTest2() is never called, and there is no .html file to run the test as applet. Have you had a chance to look at my proposal with @run main in BigFont.java and @run applet/manual in bigfont.html? > I have left method "runTest2()" commented because it requires rather > large font file (included > http://hg.openjdk.java.net/jdk8/awt/jdk/file/b57167b71169/test/java/awt/FontClass/CreateFont/A.ttf > font is a small file). > I have added fix for > test/java/awt/FontClass/CreateFont/fileaccess/FontFile.java as it was > done in jdk 7u4b11, and the test always passed with jdk 8 (it is also a > part of bug 6868690). What is the reason of having shell test here? The test explicitly checks that access to certain file is protected and that we get IOException for non-existing file. Thanks, Artem > Here is the webrev: > http://cr.openjdk.java.net/~kshefov/6868690/webrev.00/ > > > Thanks, > Konstantin > > On 08.06.2012 16:07, Artem Ananiev wrote: >> >> On 6/8/2012 12:54 PM, Konstantin Shefov wrote: >>> Artem, >>> >>> I think there are two ways: >>> 1) create one manual test with instructions to run applet (html) in >>> browser + one automatic test without html. >>> Method runTest2() should be used only within applet. >> >> OK, it can be implemented by having >> >> @run applet/manual >> >> in .html file, and >> >> @run main >> >> in .java file. >> >> Thanks, >> >> Artem >> >>> 2) remove html and runTest2() method at all, so only one automatic test >>> will remain. >>> >>> Konstantin >>> >>> On 08.06.2012 13:19, Artem Ananiev wrote: >>>> Hi, Konstantin, >>>> >>>> did you consider the following option: >>>> >>>> 1. Remove .html file >>>> >>>> 2. Add one more configuration: >>>> >>>> @run main BigFont test1 >>>> @run main/manual BigFont test1 test2 >>>> >>>> 3. Update the "main" method, so it recognizes different command line >>>> args: >>>> >>>> for (String arg: args) >>>> if (arg.equalsIgnoreCase("test1") >>>> bigTest.runTest1(); >>>> else if (arg.equalsIgnoreCase("test2") >>>> bigTest.runTest2(); >>>> >>>> The reason I'm asking about that even for manual runs people still use >>>> "jtreg", just passing "-m" to this script. As you have removed @run >>>> from the .html file, it will not be recognized by jtreg at all. >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 6/4/2012 5:32 PM, Konstantin Shefov wrote: >>>>> Hi, Artem >>>>> >>>>> As I have mentioned in review description, we can keep .html file and >>>>> runTest2() method commented in the BigFont.java if somebody wishes to >>>>> run it manually (e.g. when a failure happens). The .html file and the >>>>> method were kept in openjdk 7 regression testsuite. Or you think we >>>>> don't need to keep it? >>>>> >>>>> Konstantin >>>>> >>>>> On 04.06.2012 17:24, Artem Ananiev wrote: >>>>>> Hi, Konstantin, >>>>>> >>>>>> since you have replaced "@run applet" in .html with "@run main" in >>>>>> .java, does it also make sense to remove .html at all? Alternatively, >>>>>> you can keep the test as applet one, but mark it manual (@run >>>>>> applet/manual). >>>>>> >>>>>> BTW, copyright header dates should be updated to "2008, 2012", not >>>>>> "2008, 2011". >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Artem >>>>>> >>>>>> On 5/31/2012 5:59 PM, Konstantin Shefov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review a fix for the issue: >>>>>>> 6868690 TEST: java/awt/FontClass/CreateFont/BigFont.java test >>>>>>> should be >>>>>>> modified in jdk7&8 to run via jtreg >>>>>>> >>>>>>> The webrev is http://cr.openjdk.java.net/~serb/6868690/webrev.00/ >>>>>>> >>>>>>> The test in the current state affects a whole session if it's >>>>>>> executed >>>>>>> under jtreg. It was fixed already by the implemented >>>>>>> modifications in >>>>>>> 1.7.0 that are used as a base for modifications applicable for 1.8.0 >>>>>>> also. There is not risk are seen if the test be updated in jdk8 >>>>>>> repo. >>>>>>> >>>>>>> The current fix is identical to already pushed fix for jdk 7. >>>>>>> >>>>>>> The test works in the automatic invocation (under jtreg) without >>>>>>> bigfont.html file involvement. The only possible reason we may >>>>>>> keep it >>>>>>> (bigfont.html) for is - the test can be used in both the manual and >>>>>>> automatic invocations. It include two methods runTest1() & >>>>>>> runTest2(). >>>>>>> runTest2() is commented in the BigFont.java file as it's too >>>>>>> "risky" to >>>>>>> execute it in the automatic mode from the the applet environment. >>>>>>> But it >>>>>>> (runTest2()) is still valid for the manual invocation just for >>>>>>> "legacy/coverage" reason to be executed under applet environment >>>>>>> that is >>>>>>> more challenging. As mentioned bigfont.html does not work in >>>>>>> automatic >>>>>>> invocation, but it can work if somebody decide to run the test >>>>>>> manually >>>>>>> (runTest2()) under applet environment. >>>>>>> >>>>>>> Thanks, >>>>>>> Konstantin >>>>>>> From konstantin.shefov at oracle.com Mon Jul 2 13:42:50 2012 From: konstantin.shefov at oracle.com (Konstantin Shefov) Date: Tue, 03 Jul 2012 00:42:50 +0400 Subject: [8] Review request for 6868690 TEST: java/awt/FontClass/CreateFont/BigFont.java test should be modified in jdk7&8 to run via jtreg In-Reply-To: <4FF1F53A.7020209@oracle.com> References: <4FC7793C.8020105@oracle.com> <4FCCB717.1070706@oracle.com> <4FCCD523.1080709@oracle.com> <4FD1C3B9.2050004@oracle.com> <4FD1D9F4.2020600@oracle.com> <4FD1EB01.2000907@oracle.com> <4FD882F5.7030907@oracle.com> <4FF1F53A.7020209@oracle.com> Message-ID: <4FF207CA.1050604@oracle.com> Hello, Artem I commented inline. On 02.07.2012 23:23, Artem Ananiev wrote: > Hi, Konstantin, > > see my comments inline. > > On 6/13/2012 4:09 PM, Konstantin Shefov wrote: >> Hello, >> >> I have decided to remove bigfont.html and turn an applet test into main >> test, because applet test always fails with timeout. > > Could you clarify, how changing applet->main helps with the timeout? > If the test should be run with a greater timeout, it can be specified > as a modifier of @run tag. > > In the current version of the fix, BigFont.runTest2() is never called, > and there is no .html file to run the test as applet. Have you had a > chance to look at my proposal with > > @run main > > in BigFont.java and > > @run applet/manual > > in bigfont.html? If we run this test as applet in jtreg (with appletviewer), it just hangs and never finishes (I waited 24 hours - no effect, it hangs). The test hangs and all testsuite run hangs. If we run BigFont.runTest2() manually with browser (not jtreg, nor appletviewer) with file A.ttf, we should wait about 8 hours for the test to complete (file A.ttf is very small for this test). In jdk 6 and 7 we already have a fix pushed without applet and BigFont.runTest2() method at all (although bigfont.html remained in testsuite as just a file, it is not used there). > >> I have left method "runTest2()" commented because it requires rather >> large font file (included >> http://hg.openjdk.java.net/jdk8/awt/jdk/file/b57167b71169/test/java/awt/FontClass/CreateFont/A.ttf >> >> font is a small file). >> I have added fix for >> test/java/awt/FontClass/CreateFont/fileaccess/FontFile.java as it was >> done in jdk 7u4b11, and the test always passed with jdk 8 (it is also a >> part of bug 6868690). > > What is the reason of having shell test here? The test explicitly > checks that access to certain file is protected and that we get > IOException for non-existing file. > In fact this is a fix for bug 6802962, but there is no Multiple Release entry for jdk8 and it is discussed in CR 6868690. In the original state the test is a stopper for a whole testing session if executed under jtreg. It was modified to resolve this issue. The main reason is the system class loader is initialized at a very early point in the startup sequence. It copies the classpath into its own data structures, and the classpath property is not read again. For the particular test (when we run it under jtreg) the jtreg invokes the own main method and the codebase (not the codebase of the test class file location) that should work for this case. This is the know point. A wrapper file is a solution the is normally used for jtreg based test Workspaces. The shell script wrapper is used. This fix was integrated in jdk 7 ws already. > Thanks, > > Artem > >> Here is the webrev: >> http://cr.openjdk.java.net/~kshefov/6868690/webrev.00/ >> >> >> Thanks, >> Konstantin >> >> On 08.06.2012 16:07, Artem Ananiev wrote: >>> >>> On 6/8/2012 12:54 PM, Konstantin Shefov wrote: >>>> Artem, >>>> >>>> I think there are two ways: >>>> 1) create one manual test with instructions to run applet (html) in >>>> browser + one automatic test without html. >>>> Method runTest2() should be used only within applet. >>> >>> OK, it can be implemented by having >>> >>> @run applet/manual >>> >>> in .html file, and >>> >>> @run main >>> >>> in .java file. >>> >>> Thanks, >>> >>> Artem >>> >>>> 2) remove html and runTest2() method at all, so only one automatic >>>> test >>>> will remain. >>>> >>>> Konstantin >>>> >>>> On 08.06.2012 13:19, Artem Ananiev wrote: >>>>> Hi, Konstantin, >>>>> >>>>> did you consider the following option: >>>>> >>>>> 1. Remove .html file >>>>> >>>>> 2. Add one more configuration: >>>>> >>>>> @run main BigFont test1 >>>>> @run main/manual BigFont test1 test2 >>>>> >>>>> 3. Update the "main" method, so it recognizes different command line >>>>> args: >>>>> >>>>> for (String arg: args) >>>>> if (arg.equalsIgnoreCase("test1") >>>>> bigTest.runTest1(); >>>>> else if (arg.equalsIgnoreCase("test2") >>>>> bigTest.runTest2(); >>>>> >>>>> The reason I'm asking about that even for manual runs people still >>>>> use >>>>> "jtreg", just passing "-m" to this script. As you have removed @run >>>>> from the .html file, it will not be recognized by jtreg at all. >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 6/4/2012 5:32 PM, Konstantin Shefov wrote: >>>>>> Hi, Artem >>>>>> >>>>>> As I have mentioned in review description, we can keep .html file >>>>>> and >>>>>> runTest2() method commented in the BigFont.java if somebody >>>>>> wishes to >>>>>> run it manually (e.g. when a failure happens). The .html file and >>>>>> the >>>>>> method were kept in openjdk 7 regression testsuite. Or you think we >>>>>> don't need to keep it? >>>>>> >>>>>> Konstantin >>>>>> >>>>>> On 04.06.2012 17:24, Artem Ananiev wrote: >>>>>>> Hi, Konstantin, >>>>>>> >>>>>>> since you have replaced "@run applet" in .html with "@run main" in >>>>>>> .java, does it also make sense to remove .html at all? >>>>>>> Alternatively, >>>>>>> you can keep the test as applet one, but mark it manual (@run >>>>>>> applet/manual). >>>>>>> >>>>>>> BTW, copyright header dates should be updated to "2008, 2012", not >>>>>>> "2008, 2011". >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Artem >>>>>>> >>>>>>> On 5/31/2012 5:59 PM, Konstantin Shefov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review a fix for the issue: >>>>>>>> 6868690 TEST: java/awt/FontClass/CreateFont/BigFont.java test >>>>>>>> should be >>>>>>>> modified in jdk7&8 to run via jtreg >>>>>>>> >>>>>>>> The webrev is http://cr.openjdk.java.net/~serb/6868690/webrev.00/ >>>>>>>> >>>>>>>> The test in the current state affects a whole session if it's >>>>>>>> executed >>>>>>>> under jtreg. It was fixed already by the implemented >>>>>>>> modifications in >>>>>>>> 1.7.0 that are used as a base for modifications applicable for >>>>>>>> 1.8.0 >>>>>>>> also. There is not risk are seen if the test be updated in jdk8 >>>>>>>> repo. >>>>>>>> >>>>>>>> The current fix is identical to already pushed fix for jdk 7. >>>>>>>> >>>>>>>> The test works in the automatic invocation (under jtreg) without >>>>>>>> bigfont.html file involvement. The only possible reason we may >>>>>>>> keep it >>>>>>>> (bigfont.html) for is - the test can be used in both the manual >>>>>>>> and >>>>>>>> automatic invocations. It include two methods runTest1() & >>>>>>>> runTest2(). >>>>>>>> runTest2() is commented in the BigFont.java file as it's too >>>>>>>> "risky" to >>>>>>>> execute it in the automatic mode from the the applet environment. >>>>>>>> But it >>>>>>>> (runTest2()) is still valid for the manual invocation just for >>>>>>>> "legacy/coverage" reason to be executed under applet environment >>>>>>>> that is >>>>>>>> more challenging. As mentioned bigfont.html does not work in >>>>>>>> automatic >>>>>>>> invocation, but it can work if somebody decide to run the test >>>>>>>> manually >>>>>>>> (runTest2()) under applet environment. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Konstantin >>>>>>>> From kelly.ohair at oracle.com Tue Jul 3 11:42:46 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 3 Jul 2012 11:42:46 -0700 Subject: Review: Removing GenerateNativeHeader where not needed In-Reply-To: <4FF338B0.7060200@oracle.com> References: <4FF338B0.7060200@oracle.com> Message-ID: Reviewed it, looks fine. Unless I hear loud screams from anyone, I'll do test builds and push this change into jdk8/build in the next few hours. FYI, created this CR 7181508: Remove GenerateNativeHeader on awt java file -kto On Jul 3, 2012, at 11:23 AM, Erik Joelsson wrote: > The build infra project added the use of the annotation GenerateNativeHeader. It was addded to java classes without native methods that were listed in the old makefiles as needing headers generated for them. It was noted then that some of those classes didn't actually need native headers. To clean things up, we have tried to identify the empty headers and removed the annotation for those classes. > > http://cr.openjdk.java.net/~erikj/build-infra-m1.2/webrev-jdk-awt/ From sergey.bylokhov at oracle.com Wed Jul 4 04:44:45 2012 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Wed, 04 Jul 2012 11:44:45 +0000 Subject: hg: jdk8/awt/jdk: 2 new changesets Message-ID: <20120704114518.D604547CCA@hg.openjdk.java.net> Changeset: f1a90ee31b38 Author: serb Date: 2012-07-04 14:38 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f1a90ee31b38 7124244: [macosx] Shaped windows support Reviewed-by: anthony, art ! src/macosx/classes/sun/java2d/opengl/CGLLayer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWRepaintArea.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTWindow.m ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: 80c592c9458e Author: serb Date: 2012-07-04 15:36 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/80c592c9458e 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar Reviewed-by: anthony, art ! src/macosx/classes/com/apple/laf/AquaPanelUI.java ! src/macosx/classes/com/apple/laf/AquaRootPaneUI.java ! src/macosx/classes/com/apple/laf/AquaToolBarUI.java ! src/macosx/classes/com/apple/laf/AquaUtils.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/share/classes/javax/swing/JViewport.java From erik.joelsson at oracle.com Tue Jul 3 11:23:44 2012 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 03 Jul 2012 11:23:44 -0700 Subject: Review: Removing GenerateNativeHeader where not needed Message-ID: <4FF338B0.7060200@oracle.com> The build infra project added the use of the annotation GenerateNativeHeader. It was addded to java classes without native methods that were listed in the old makefiles as needing headers generated for them. It was noted then that some of those classes didn't actually need native headers. To clean things up, we have tried to identify the empty headers and removed the annotation for those classes. http://cr.openjdk.java.net/~erikj/build-infra-m1.2/webrev-jdk-awt/ From anthony.petrov at oracle.com Wed Jul 4 05:32:57 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 04 Jul 2012 16:32:57 +0400 Subject: Review: Removing GenerateNativeHeader where not needed In-Reply-To: <4FF338B0.7060200@oracle.com> References: <4FF338B0.7060200@oracle.com> Message-ID: <4FF437F9.1070305@oracle.com> Looks good to me. Although most of the changes are in Java2D code, so I'm also CC'ing 2d-dev@ to take a look. -- best regards, Anthony On 7/3/2012 10:23 PM, Erik Joelsson wrote: > The build infra project added the use of the annotation > GenerateNativeHeader. It was addded to java classes without native > methods that were listed in the old makefiles as needing headers > generated for them. It was noted then that some of those classes didn't > actually need native headers. To clean things up, we have tried to > identify the empty headers and removed the annotation for those classes. > > http://cr.openjdk.java.net/~erikj/build-infra-m1.2/webrev-jdk-awt/ > From anthony.petrov at oracle.com Wed Jul 4 07:54:25 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 04 Jul 2012 18:54:25 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 Message-ID: <4FF45921.707@oracle.com> Hello, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7177173 at: http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ The bug synopsis may sound misleading: the original problem with applying the extended state after showing a frame has been resolved a while back with another fix. The only issue currently left is that the state is reset when a frame is disposed/hidden, which prevents apps from tracking the last known state of a window. With this fix we avoid canceling/reapplying the maximized state to windows on each showing/hiding operation. Instead we track the state in the CPlatformWindow instance, and apply it on showing of the window if the state differs from what shared code expects. The behavior now matches that of Apple JDK (including handling of the ICONIFIED state). -- best regards, Anthony From Sergey.Bylokhov at oracle.com Wed Jul 4 08:07:53 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 04 Jul 2012 19:07:53 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF45921.707@oracle.com> References: <4FF45921.707@oracle.com> Message-ID: <4FF45C49.6070508@oracle.com> Hi, Anthony. Why there are two different methods for isZoomed? 481 final boolean isZoomed =*this.normalBounds == null*; But in the method we use another code. 471 private boolean isZoomed() { 472 return zoomed ||*this.normalBounds != null*; 473 } Probably it can be unified? 04.07.2012 18:54, Anthony Petrov wrote: > Hello, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7177173 > at: > > http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ > > The bug synopsis may sound misleading: the original problem with > applying the extended state after showing a frame has been resolved a > while back with another fix. The only issue currently left is that the > state is reset when a frame is disposed/hidden, which prevents apps > from tracking the last known state of a window. > > With this fix we avoid canceling/reapplying the maximized state to > windows on each showing/hiding operation. Instead we track the state > in the CPlatformWindow instance, and apply it on showing of the window > if the state differs from what shared code expects. The behavior now > matches that of Apple JDK (including handling of the ICONIFIED state). > > -- > best regards, > Anthony -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120704/d47c2e6e/attachment.html From anthony.petrov at oracle.com Wed Jul 4 08:15:42 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 04 Jul 2012 19:15:42 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF45C49.6070508@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> Message-ID: <4FF45E1E.6030801@oracle.com> Hi Sergey, Thanks for the review. On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: > Why there are two different methods for isZoomed? > > 481 final boolean isZoomed = *this.normalBounds == null*; Here we determine a new state that needs to be set to an undecorated window. This is what isZoomed() will return after the zoom() method returns. > But in the method we use another code. > > 471 private boolean isZoomed() { > 472 return zoomed || *this.normalBounds != null*; > 473 } This is a method that returns the current zoomed state for any window regardless whether it is decorated or not. > Probably it can be unified? No. These are completely different operations. We might change the first line to "final boolean isZoomed = !isZoomed();", but the current code looks a lot clearer to me. -- best regards, Anthony > > > 04.07.2012 18:54, Anthony Petrov wrote: >> Hello, >> >> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7177173 >> at: >> >> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >> >> The bug synopsis may sound misleading: the original problem with >> applying the extended state after showing a frame has been resolved a >> while back with another fix. The only issue currently left is that the >> state is reset when a frame is disposed/hidden, which prevents apps >> from tracking the last known state of a window. >> >> With this fix we avoid canceling/reapplying the maximized state to >> windows on each showing/hiding operation. Instead we track the state >> in the CPlatformWindow instance, and apply it on showing of the window >> if the state differs from what shared code expects. The behavior now >> matches that of Apple JDK (including handling of the ICONIFIED state). >> >> -- >> best regards, >> Anthony > > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Wed Jul 4 08:26:54 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 04 Jul 2012 19:26:54 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF45E1E.6030801@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> <4FF45E1E.6030801@oracle.com> Message-ID: <4FF460BE.1040901@oracle.com> Hi,Anthony. I just point to the same name "isZoomed", which contains different state: first is "true" for this.normalBounds == null and the second "true" for this.normalBounds != null. This is strange. I believe that correct code should be isZoomed = isZoomed();? 04.07.2012 19:15, Anthony Petrov wrote: > Hi Sergey, > > Thanks for the review. > > On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: >> Why there are two different methods for isZoomed? >> >> 481 final boolean isZoomed = *this.normalBounds == null*; > > Here we determine a new state that needs to be set to an undecorated > window. This is what isZoomed() will return after the zoom() method > returns. > >> But in the method we use another code. >> >> 471 private boolean isZoomed() { >> 472 return zoomed || *this.normalBounds != null*; >> 473 } > > This is a method that returns the current zoomed state for any window > regardless whether it is decorated or not. > >> Probably it can be unified? > > No. These are completely different operations. We might change the > first line to "final boolean isZoomed = !isZoomed();", but the current > code looks a lot clearer to me. > > -- > best regards, > Anthony > > >> >> >> 04.07.2012 18:54, Anthony Petrov wrote: >>> Hello, >>> >>> Please review a fix for >>> http://bugs.sun.com/view_bug.do?bug_id=7177173 at: >>> >>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >>> >>> The bug synopsis may sound misleading: the original problem with >>> applying the extended state after showing a frame has been resolved >>> a while back with another fix. The only issue currently left is that >>> the state is reset when a frame is disposed/hidden, which prevents >>> apps from tracking the last known state of a window. >>> >>> With this fix we avoid canceling/reapplying the maximized state to >>> windows on each showing/hiding operation. Instead we track the state >>> in the CPlatformWindow instance, and apply it on showing of the >>> window if the state differs from what shared code expects. The >>> behavior now matches that of Apple JDK (including handling of the >>> ICONIFIED state). >>> >>> -- >>> best regards, >>> Anthony >> >> >> -- >> Best regards, Sergey. -- Best regards, Sergey. From anthony.petrov at oracle.com Wed Jul 4 08:30:12 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 04 Jul 2012 19:30:12 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF460BE.1040901@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> <4FF45E1E.6030801@oracle.com> <4FF460BE.1040901@oracle.com> Message-ID: <4FF46184.20508@oracle.com> Hi Sergey, Please find an updated webrev at: http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.2/ I renamed the local variable from isZoomed to doZoom. -- best regards, Anthony On 7/4/2012 7:26 PM, Sergey Bylokhov wrote: > Hi,Anthony. > I just point to the same name "isZoomed", which contains different state: > first is "true" for this.normalBounds == null and the second "true" for > this.normalBounds != null. > This is strange. > I believe that correct code should be isZoomed = isZoomed();? > > 04.07.2012 19:15, Anthony Petrov wrote: >> Hi Sergey, >> >> Thanks for the review. >> >> On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: >>> Why there are two different methods for isZoomed? >>> >>> 481 final boolean isZoomed = *this.normalBounds == null*; >> >> Here we determine a new state that needs to be set to an undecorated >> window. This is what isZoomed() will return after the zoom() method >> returns. >> >>> But in the method we use another code. >>> >>> 471 private boolean isZoomed() { >>> 472 return zoomed || *this.normalBounds != null*; >>> 473 } >> >> This is a method that returns the current zoomed state for any window >> regardless whether it is decorated or not. >> >>> Probably it can be unified? >> >> No. These are completely different operations. We might change the >> first line to "final boolean isZoomed = !isZoomed();", but the current >> code looks a lot clearer to me. >> >> -- >> best regards, >> Anthony >> >> >>> >>> >>> 04.07.2012 18:54, Anthony Petrov wrote: >>>> Hello, >>>> >>>> Please review a fix for >>>> http://bugs.sun.com/view_bug.do?bug_id=7177173 at: >>>> >>>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >>>> >>>> The bug synopsis may sound misleading: the original problem with >>>> applying the extended state after showing a frame has been resolved >>>> a while back with another fix. The only issue currently left is that >>>> the state is reset when a frame is disposed/hidden, which prevents >>>> apps from tracking the last known state of a window. >>>> >>>> With this fix we avoid canceling/reapplying the maximized state to >>>> windows on each showing/hiding operation. Instead we track the state >>>> in the CPlatformWindow instance, and apply it on showing of the >>>> window if the state differs from what shared code expects. The >>>> behavior now matches that of Apple JDK (including handling of the >>>> ICONIFIED state). >>>> >>>> -- >>>> best regards, >>>> Anthony >>> >>> >>> -- >>> Best regards, Sergey. > > From Sergey.Bylokhov at oracle.com Thu Jul 5 02:29:42 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 05 Jul 2012 13:29:42 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF46184.20508@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> <4FF45E1E.6030801@oracle.com> <4FF460BE.1040901@oracle.com> <4FF46184.20508@oracle.com> Message-ID: <4FF55E86.9080200@oracle.com> Hi, Anthony. Fix looks good. 04.07.2012 19:30, Anthony Petrov wrote: > Hi Sergey, > > Please find an updated webrev at: > > http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.2/ > > I renamed the local variable from isZoomed to doZoom. > > -- > best regards, > Anthony > > On 7/4/2012 7:26 PM, Sergey Bylokhov wrote: >> Hi,Anthony. >> I just point to the same name "isZoomed", which contains different >> state: >> first is "true" for this.normalBounds == null and the second "true" >> for this.normalBounds != null. >> This is strange. >> I believe that correct code should be isZoomed = isZoomed();? >> >> 04.07.2012 19:15, Anthony Petrov wrote: >>> Hi Sergey, >>> >>> Thanks for the review. >>> >>> On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: >>>> Why there are two different methods for isZoomed? >>>> >>>> 481 final boolean isZoomed = *this.normalBounds == null*; >>> >>> Here we determine a new state that needs to be set to an undecorated >>> window. This is what isZoomed() will return after the zoom() method >>> returns. >>> >>>> But in the method we use another code. >>>> >>>> 471 private boolean isZoomed() { >>>> 472 return zoomed || *this.normalBounds != null*; >>>> 473 } >>> >>> This is a method that returns the current zoomed state for any >>> window regardless whether it is decorated or not. >>> >>>> Probably it can be unified? >>> >>> No. These are completely different operations. We might change the >>> first line to "final boolean isZoomed = !isZoomed();", but the >>> current code looks a lot clearer to me. >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>>> >>>> >>>> 04.07.2012 18:54, Anthony Petrov wrote: >>>>> Hello, >>>>> >>>>> Please review a fix for >>>>> http://bugs.sun.com/view_bug.do?bug_id=7177173 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >>>>> >>>>> The bug synopsis may sound misleading: the original problem with >>>>> applying the extended state after showing a frame has been >>>>> resolved a while back with another fix. The only issue currently >>>>> left is that the state is reset when a frame is disposed/hidden, >>>>> which prevents apps from tracking the last known state of a window. >>>>> >>>>> With this fix we avoid canceling/reapplying the maximized state to >>>>> windows on each showing/hiding operation. Instead we track the >>>>> state in the CPlatformWindow instance, and apply it on showing of >>>>> the window if the state differs from what shared code expects. The >>>>> behavior now matches that of Apple JDK (including handling of the >>>>> ICONIFIED state). >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>> >>>> >>>> -- >>>> Best regards, Sergey. >> >> -- Best regards, Sergey. From artem.ananiev at oracle.com Thu Jul 5 03:46:01 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 05 Jul 2012 14:46:01 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF46184.20508@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> <4FF45E1E.6030801@oracle.com> <4FF460BE.1040901@oracle.com> <4FF46184.20508@oracle.com> Message-ID: <4FF57069.60406@oracle.com> That's not the clearest code I've ever seen... Is it possible to refactor it to make easier to review and support? For example, replace zoom() with two separate methods, maximize() and restore(), or zoom() and unzoom(), or whatever. Each of those two methods would be no-op, if the window is already in the required state. isZoomed() method is not that trivial as well. In each of the two methods, I would have isUndecorated() condition, and based on the result, check for "isZoomed" or "normalBounds" field... Something like that. I would also enhance the test to include both decorated and undecorated frames. Thanks, Artem On 7/4/2012 7:30 PM, Anthony Petrov wrote: > Hi Sergey, > > Please find an updated webrev at: > > http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.2/ > > I renamed the local variable from isZoomed to doZoom. > > -- > best regards, > Anthony > > On 7/4/2012 7:26 PM, Sergey Bylokhov wrote: >> Hi,Anthony. >> I just point to the same name "isZoomed", which contains different state: >> first is "true" for this.normalBounds == null and the second "true" >> for this.normalBounds != null. >> This is strange. >> I believe that correct code should be isZoomed = isZoomed();? >> >> 04.07.2012 19:15, Anthony Petrov wrote: >>> Hi Sergey, >>> >>> Thanks for the review. >>> >>> On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: >>>> Why there are two different methods for isZoomed? >>>> >>>> 481 final boolean isZoomed = *this.normalBounds == null*; >>> >>> Here we determine a new state that needs to be set to an undecorated >>> window. This is what isZoomed() will return after the zoom() method >>> returns. >>> >>>> But in the method we use another code. >>>> >>>> 471 private boolean isZoomed() { >>>> 472 return zoomed || *this.normalBounds != null*; >>>> 473 } >>> >>> This is a method that returns the current zoomed state for any window >>> regardless whether it is decorated or not. >>> >>>> Probably it can be unified? >>> >>> No. These are completely different operations. We might change the >>> first line to "final boolean isZoomed = !isZoomed();", but the >>> current code looks a lot clearer to me. >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>>> >>>> >>>> 04.07.2012 18:54, Anthony Petrov wrote: >>>>> Hello, >>>>> >>>>> Please review a fix for >>>>> http://bugs.sun.com/view_bug.do?bug_id=7177173 at: >>>>> >>>>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >>>>> >>>>> The bug synopsis may sound misleading: the original problem with >>>>> applying the extended state after showing a frame has been resolved >>>>> a while back with another fix. The only issue currently left is >>>>> that the state is reset when a frame is disposed/hidden, which >>>>> prevents apps from tracking the last known state of a window. >>>>> >>>>> With this fix we avoid canceling/reapplying the maximized state to >>>>> windows on each showing/hiding operation. Instead we track the >>>>> state in the CPlatformWindow instance, and apply it on showing of >>>>> the window if the state differs from what shared code expects. The >>>>> behavior now matches that of Apple JDK (including handling of the >>>>> ICONIFIED state). >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>> >>>> >>>> -- >>>> Best regards, Sergey. >> >> From anthony.petrov at oracle.com Thu Jul 5 07:08:20 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 05 Jul 2012 18:08:20 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF57069.60406@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> <4FF45E1E.6030801@oracle.com> <4FF460BE.1040901@oracle.com> <4FF46184.20508@oracle.com> <4FF57069.60406@oracle.com> Message-ID: <4FF59FD4.6010506@oracle.com> Hi Artem, Thanks for the review. Please find an updated webrev at: http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.3/ All suggestions have been applied. -- best regards, Anthony On 07/05/12 14:46, Artem Ananiev wrote: > > That's not the clearest code I've ever seen... Is it possible to > refactor it to make easier to review and support? For example, replace > zoom() with two separate methods, maximize() and restore(), or zoom() > and unzoom(), or whatever. Each of those two methods would be no-op, if > the window is already in the required state. > > isZoomed() method is not that trivial as well. In each of the two > methods, I would have isUndecorated() condition, and based on the > result, check for "isZoomed" or "normalBounds" field... Something like > that. > > I would also enhance the test to include both decorated and undecorated > frames. > > Thanks, > > Artem > > On 7/4/2012 7:30 PM, Anthony Petrov wrote: >> Hi Sergey, >> >> Please find an updated webrev at: >> >> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.2/ >> >> I renamed the local variable from isZoomed to doZoom. >> >> -- >> best regards, >> Anthony >> >> On 7/4/2012 7:26 PM, Sergey Bylokhov wrote: >>> Hi,Anthony. >>> I just point to the same name "isZoomed", which contains different >>> state: >>> first is "true" for this.normalBounds == null and the second "true" >>> for this.normalBounds != null. >>> This is strange. >>> I believe that correct code should be isZoomed = isZoomed();? >>> >>> 04.07.2012 19:15, Anthony Petrov wrote: >>>> Hi Sergey, >>>> >>>> Thanks for the review. >>>> >>>> On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: >>>>> Why there are two different methods for isZoomed? >>>>> >>>>> 481 final boolean isZoomed = *this.normalBounds == null*; >>>> >>>> Here we determine a new state that needs to be set to an undecorated >>>> window. This is what isZoomed() will return after the zoom() method >>>> returns. >>>> >>>>> But in the method we use another code. >>>>> >>>>> 471 private boolean isZoomed() { >>>>> 472 return zoomed || *this.normalBounds != null*; >>>>> 473 } >>>> >>>> This is a method that returns the current zoomed state for any window >>>> regardless whether it is decorated or not. >>>> >>>>> Probably it can be unified? >>>> >>>> No. These are completely different operations. We might change the >>>> first line to "final boolean isZoomed = !isZoomed();", but the >>>> current code looks a lot clearer to me. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> >>>>> >>>>> >>>>> 04.07.2012 18:54, Anthony Petrov wrote: >>>>>> Hello, >>>>>> >>>>>> Please review a fix for >>>>>> http://bugs.sun.com/view_bug.do?bug_id=7177173 at: >>>>>> >>>>>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >>>>>> >>>>>> The bug synopsis may sound misleading: the original problem with >>>>>> applying the extended state after showing a frame has been resolved >>>>>> a while back with another fix. The only issue currently left is >>>>>> that the state is reset when a frame is disposed/hidden, which >>>>>> prevents apps from tracking the last known state of a window. >>>>>> >>>>>> With this fix we avoid canceling/reapplying the maximized state to >>>>>> windows on each showing/hiding operation. Instead we track the >>>>>> state in the CPlatformWindow instance, and apply it on showing of >>>>>> the window if the state differs from what shared code expects. The >>>>>> behavior now matches that of Apple JDK (including handling of the >>>>>> ICONIFIED state). >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>> >>>>> >>>>> -- >>>>> Best regards, Sergey. >>> >>> From anton.tarasov at oracle.com Thu Jul 5 07:20:00 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 05 Jul 2012 18:20:00 +0400 Subject: [8] Review request for 6981400 Tabbing between textfield do not work properly when ALT+TAB Message-ID: <4FF5A290.6040308@oracle.com> 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.4/src/share/classes/java/awt/Component.java.sdiff.html http://cr.openjdk.java.net/~ant/6981400/webrev.4/src/share/classes/java/awt/Container.java.sdiff.html http://cr.openjdk.java.net/~ant/6981400/webrev.4/src/share/classes/java/awt/Dialog.java.sdiff.html http://cr.openjdk.java.net/~ant/6981400/webrev.4/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.4/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.4/src/macosx/classes/sun/lwawt/LWComponentPeer.java.sdiff.html http://cr.openjdk.java.net/~ant/6981400/webrev.4/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.4/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.4/src/solaris/classes/sun/awt/X11/XBaseWindow.java.sdiff.html http://cr.openjdk.java.net/~ant/6981400/webrev.4/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.4/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.4/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.4/src/share/classes/sun/awt/TimedWindowEvent.java.html A WindowEvent with a time stamp. 9. SunToolkit http://cr.openjdk.java.net/~ant/6981400/webrev.4/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.4/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.4/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 Thu Jul 5 07:30:15 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 05 Jul 2012 18:30:15 +0400 Subject: [8] Review request for 6981400 Tabbing between textfield do not work properly when ALT+TAB In-Reply-To: <4FF5A290.6040308@oracle.com> References: <4FF5A290.6040308@oracle.com> Message-ID: <4FF5A4F7.7020308@oracle.com> [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/20120705/2470541e/attachment.html From artem.ananiev at oracle.com Thu Jul 5 08:04:32 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 05 Jul 2012 19:04:32 +0400 Subject: [8] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF59FD4.6010506@oracle.com> References: <4FF45921.707@oracle.com> <4FF45C49.6070508@oracle.com> <4FF45E1E.6030801@oracle.com> <4FF460BE.1040901@oracle.com> <4FF46184.20508@oracle.com> <4FF57069.60406@oracle.com> <4FF59FD4.6010506@oracle.com> Message-ID: <4FF5AD00.5040202@oracle.com> On 7/5/2012 6:08 PM, Anthony Petrov wrote: > Hi Artem, > > Thanks for the review. Please find an updated webrev at: > > http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.3/ > > All suggestions have been applied. That's much clearer! Thanks, it now looks fine. Artem > -- > best regards, > Anthony > > On 07/05/12 14:46, Artem Ananiev wrote: >> >> That's not the clearest code I've ever seen... Is it possible to >> refactor it to make easier to review and support? For example, replace >> zoom() with two separate methods, maximize() and restore(), or zoom() >> and unzoom(), or whatever. Each of those two methods would be no-op, if >> the window is already in the required state. >> >> isZoomed() method is not that trivial as well. In each of the two >> methods, I would have isUndecorated() condition, and based on the >> result, check for "isZoomed" or "normalBounds" field... Something like >> that. >> >> I would also enhance the test to include both decorated and undecorated >> frames. >> >> Thanks, >> >> Artem >> >> On 7/4/2012 7:30 PM, Anthony Petrov wrote: >>> Hi Sergey, >>> >>> Please find an updated webrev at: >>> >>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.2/ >>> >>> I renamed the local variable from isZoomed to doZoom. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 7/4/2012 7:26 PM, Sergey Bylokhov wrote: >>>> Hi,Anthony. >>>> I just point to the same name "isZoomed", which contains different >>>> state: >>>> first is "true" for this.normalBounds == null and the second "true" >>>> for this.normalBounds != null. >>>> This is strange. >>>> I believe that correct code should be isZoomed = isZoomed();? >>>> >>>> 04.07.2012 19:15, Anthony Petrov wrote: >>>>> Hi Sergey, >>>>> >>>>> Thanks for the review. >>>>> >>>>> On 7/4/2012 7:07 PM, Sergey Bylokhov wrote: >>>>>> Why there are two different methods for isZoomed? >>>>>> >>>>>> 481 final boolean isZoomed = *this.normalBounds == null*; >>>>> >>>>> Here we determine a new state that needs to be set to an undecorated >>>>> window. This is what isZoomed() will return after the zoom() method >>>>> returns. >>>>> >>>>>> But in the method we use another code. >>>>>> >>>>>> 471 private boolean isZoomed() { >>>>>> 472 return zoomed || *this.normalBounds != null*; >>>>>> 473 } >>>>> >>>>> This is a method that returns the current zoomed state for any window >>>>> regardless whether it is decorated or not. >>>>> >>>>>> Probably it can be unified? >>>>> >>>>> No. These are completely different operations. We might change the >>>>> first line to "final boolean isZoomed = !isZoomed();", but the >>>>> current code looks a lot clearer to me. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> >>>>>> >>>>>> >>>>>> 04.07.2012 18:54, Anthony Petrov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review a fix for >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=7177173 at: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~anthony/8-36-MaximizedBoth-7177173.1/ >>>>>>> >>>>>>> The bug synopsis may sound misleading: the original problem with >>>>>>> applying the extended state after showing a frame has been resolved >>>>>>> a while back with another fix. The only issue currently left is >>>>>>> that the state is reset when a frame is disposed/hidden, which >>>>>>> prevents apps from tracking the last known state of a window. >>>>>>> >>>>>>> With this fix we avoid canceling/reapplying the maximized state to >>>>>>> windows on each showing/hiding operation. Instead we track the >>>>>>> state in the CPlatformWindow instance, and apply it on showing of >>>>>>> the window if the state differs from what shared code expects. The >>>>>>> behavior now matches that of Apple JDK (including handling of the >>>>>>> ICONIFIED state). >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, Sergey. >>>> >>>> From anthony.petrov at oracle.com Fri Jul 6 03:21:06 2012 From: anthony.petrov at oracle.com (anthony.petrov at oracle.com) Date: Fri, 06 Jul 2012 10:21:06 +0000 Subject: hg: jdk8/awt/jdk: 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 Message-ID: <20120706102143.AB22947DD3@hg.openjdk.java.net> Changeset: 911195d40b89 Author: anthony Date: 2012-07-06 14:20 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/911195d40b89 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 Summary: Avoid unnecessary changes to the extended state Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java + test/java/awt/Frame/HideMaximized/HideMaximized.java From anthony.petrov at oracle.com Fri Jul 6 04:23:49 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 06 Jul 2012 15:23:49 +0400 Subject: [7u6] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 Message-ID: <4FF6CAC5.5080108@oracle.com> Hi Sergey, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7177173 at: http://cr.openjdk.java.net/~anthony/7u6-17-MaximizedBoth-7177173.0/ This is a 100% direct back-port of the same fix from JDK 8. -- best regards, Anthony From Sergey.Bylokhov at oracle.com Fri Jul 6 04:30:20 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 06 Jul 2012 15:30:20 +0400 Subject: [7u6] Review request for 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 In-Reply-To: <4FF6CAC5.5080108@oracle.com> References: <4FF6CAC5.5080108@oracle.com> Message-ID: <4FF6CC4C.7000806@oracle.com> Hi, Anthony. Fix looks good. 06.07.2012 15:23, Anthony Petrov wrote: > Hi Sergey, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7177173 > at: > > http://cr.openjdk.java.net/~anthony/7u6-17-MaximizedBoth-7177173.0/ > > This is a 100% direct back-port of the same fix from JDK 8. > > -- > best regards, > Anthony -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Jul 9 06:28:58 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 09 Jul 2012 17:28:58 +0400 Subject: [7u6] Review request for 7124244: [macosx] Shaped windows support Message-ID: <4FFADC9A.8090405@oracle.com> Hi Everyone, Please review the fix. This is a direct backport from JDK 8 to 7u6. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.04/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f1a90ee31b38 -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120709/01277889/attachment.html From Sergey.Bylokhov at oracle.com Mon Jul 9 06:33:45 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 09 Jul 2012 17:33:45 +0400 Subject: [7u6] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar Message-ID: <4FFADDB9.905@oracle.com> Hi Everyone, Please review the fix. This is a direct backport from JDK 8 to 7u6. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 Webrev can be found at: http://cr.openjdk.java.net/~serb/7124513/webrev.01 jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/80c592c9458e -- Best regards, Sergey. From philip.race at oracle.com Mon Jul 9 15:02:41 2012 From: philip.race at oracle.com (Phil Race) Date: Mon, 09 Jul 2012 15:02:41 -0700 Subject: [OpenJDK 2D-Dev] Review: Removing GenerateNativeHeader where not needed In-Reply-To: <4FF437F9.1070305@oracle.com> References: <4FF338B0.7060200@oracle.com> <4FF437F9.1070305@oracle.com> Message-ID: <4FFB5501.2020404@oracle.com> Fine by me. -phil. On 7/4/2012 5:32 AM, Anthony Petrov wrote: > Looks good to me. Although most of the changes are in Java2D code, so > I'm also CC'ing 2d-dev@ to take a look. > > -- > best regards, > Anthony > > On 7/3/2012 10:23 PM, Erik Joelsson wrote: >> The build infra project added the use of the annotation >> GenerateNativeHeader. It was addded to java classes without native >> methods that were listed in the old makefiles as needing headers >> generated for them. It was noted then that some of those classes >> didn't actually need native headers. To clean things up, we have >> tried to identify the empty headers and removed the annotation for >> those classes. >> >> http://cr.openjdk.java.net/~erikj/build-infra-m1.2/webrev-jdk-awt/ >> From anthony.petrov at oracle.com Tue Jul 10 02:52:46 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 10 Jul 2012 13:52:46 +0400 Subject: [7u6] Review request for 7162144: Missing AWT thread in headless mode in 7u4 b20 Message-ID: <4FFBFB6E.7050604@oracle.com> Hi Sergey and Oleg, Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7162144 at: http://cr.openjdk.java.net/~anthony/7u6-16-missingAWTThread-7162144.0/ Notes: 1. To prevent a hang, invokeAndWait() will throw InterruptedException when the EDT is interrupted. NetBeans team confirms that this solution helps resolve their issue. 2. There's no easy way to test it, so there's not a regression test. However, the bug contains a link to a huge test case that I used to verify this fix. 3. We're fixing this in 7u6 first, because we're currently unable to test it properly with JDK 8 due to broken headless mode (blocked by an open JVM bug). -- best regards, Anthony From Sergey.Bylokhov at oracle.com Tue Jul 10 03:22:40 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 10 Jul 2012 14:22:40 +0400 Subject: [7u6] Review request for 7162144: Missing AWT thread in headless mode in 7u4 b20 In-Reply-To: <4FFBFB6E.7050604@oracle.com> References: <4FFBFB6E.7050604@oracle.com> Message-ID: <4FFC0270.9030706@oracle.com> Hi, Anthony. Fix looks good. 10.07.2012 13:52, Anthony Petrov wrote: > Hi Sergey and Oleg, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7162144 > at: > > http://cr.openjdk.java.net/~anthony/7u6-16-missingAWTThread-7162144.0/ > > Notes: > > 1. To prevent a hang, invokeAndWait() will throw InterruptedException > when the EDT is interrupted. NetBeans team confirms that this solution > helps resolve their issue. > > 2. There's no easy way to test it, so there's not a regression test. > However, the bug contains a link to a huge test case that I used to > verify this fix. > > 3. We're fixing this in 7u6 first, because we're currently unable to > test it properly with JDK 8 due to broken headless mode (blocked by an > open JVM bug). > > -- > best regards, > Anthony -- Best regards, Sergey. From anthony.petrov at oracle.com Tue Jul 10 03:27:07 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 10 Jul 2012 14:27:07 +0400 Subject: [7u6] Review request for 7124244: [macosx] Shaped windows support In-Reply-To: <4FFADC9A.8090405@oracle.com> References: <4FFADC9A.8090405@oracle.com> Message-ID: <4FFC037B.3070702@oracle.com> Looks fine. -- best regards, Anthony On 7/9/2012 5:28 PM, Sergey Bylokhov wrote: > > Hi Everyone, > Please review the fix. This is a direct backport from JDK 8 to 7u6. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124244 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124244/webrev.04/ > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f1a90ee31b38 > > -- > Best regards, Sergey. > From anthony.petrov at oracle.com Tue Jul 10 03:29:14 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 10 Jul 2012 14:29:14 +0400 Subject: [7u6] Review request for 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar In-Reply-To: <4FFADDB9.905@oracle.com> References: <4FFADDB9.905@oracle.com> Message-ID: <4FFC03FA.9010608@oracle.com> Looks good. -- best regards, Anthony On 7/9/2012 5:33 PM, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. This is a direct backport from JDK 8 to 7u6. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124513 > Webrev can be found at: http://cr.openjdk.java.net/~serb/7124513/webrev.01 > jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/80c592c9458e > From oleg.pekhovskiy at oracle.com Tue Jul 10 04:22:22 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Tue, 10 Jul 2012 15:22:22 +0400 Subject: [7u6] Review request for 7162144: Missing AWT thread in headless mode in 7u4 b20 In-Reply-To: <4FFBFB6E.7050604@oracle.com> References: <4FFBFB6E.7050604@oracle.com> Message-ID: <4FFC106E.5060907@oracle.com> Hi Anthony, fix looks good. Oleg. 7/10/2012 1:52 PM, Anthony Petrov wrote: > Hi Sergey and Oleg, > > Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7162144 > at: > > http://cr.openjdk.java.net/~anthony/7u6-16-missingAWTThread-7162144.0/ > > Notes: > > 1. To prevent a hang, invokeAndWait() will throw InterruptedException > when the EDT is interrupted. NetBeans team confirms that this solution > helps resolve their issue. > > 2. There's no easy way to test it, so there's not a regression test. > However, the bug contains a link to a huge test case that I used to > verify this fix. > > 3. We're fixing this in 7u6 first, because we're currently unable to > test it properly with JDK 8 due to broken headless mode (blocked by an > open JVM bug). > > -- > best regards, > Anthony From leonid.romanov at oracle.com Wed Jul 11 06:46:07 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 11 Jul 2012 17:46:07 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode Message-ID: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> Hi, Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ Thanks, Leonid. From anthony.petrov at oracle.com Wed Jul 11 06:56:49 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 11 Jul 2012 17:56:49 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> Message-ID: <4FFD8621.3060706@oracle.com> Hi Leonid, Since GraphicsEnvironment is a shared class, I'm concerned with removing the check for "sun.awt.HeadlessGraphicsEnvironment" to determine whether we should run in headless mode. Can we keep this check in place, and also add the new one that checks the toolkit name? -- best regards, Anthony On 7/11/2012 5:46 PM, Leonid Romanov wrote: > Hi, > Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 > Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ > > Thanks, > Leonid. > From leonid.romanov at oracle.com Wed Jul 11 07:29:24 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 11 Jul 2012 18:29:24 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <4FFD8621.3060706@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFD8621.3060706@oracle.com> Message-ID: Hi, This had been my concern as well, but then I found this: http://cr.openjdk.java.net/~anthony/x-5-forceHeadless.0/src/share/classes/java/awt/GraphicsEnvironment.java.sdiff.html Looks like you added this check as part of the fix for http://java.net/jira/browse/MACOSX_PORT-774 Which means that this check is only useful for OS X, and therefore it's OK to replace it with another. On 11.07.2012, at 17:56, Anthony Petrov wrote: > Hi Leonid, > > Since GraphicsEnvironment is a shared class, I'm concerned with removing the check for "sun.awt.HeadlessGraphicsEnvironment" to determine whether we should run in headless mode. Can we keep this check in place, and also add the new one that checks the toolkit name? > > -- > best regards, > Anthony > > On 7/11/2012 5:46 PM, Leonid Romanov wrote: >> Hi, >> Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >> Thanks, >> Leonid. From anthony.petrov at oracle.com Wed Jul 11 07:34:36 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 11 Jul 2012 18:34:36 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFD8621.3060706@oracle.com> Message-ID: <4FFD8EFC.9030004@oracle.com> Indeed. Thanks for reminding about that. In this case I'm fine with your fix. -- best regards, Anthony On 7/11/2012 6:29 PM, Leonid Romanov wrote: > Hi, > This had been my concern as well, but then I found this: > http://cr.openjdk.java.net/~anthony/x-5-forceHeadless.0/src/share/classes/java/awt/GraphicsEnvironment.java.sdiff.html > > Looks like you added this check as part of the fix for http://java.net/jira/browse/MACOSX_PORT-774 > Which means that this check is only useful for OS X, and therefore it's OK to replace it with another. > > > On 11.07.2012, at 17:56, Anthony Petrov wrote: > >> Hi Leonid, >> >> Since GraphicsEnvironment is a shared class, I'm concerned with removing the check for "sun.awt.HeadlessGraphicsEnvironment" to determine whether we should run in headless mode. Can we keep this check in place, and also add the new one that checks the toolkit name? >> >> -- >> best regards, >> Anthony >> >> On 7/11/2012 5:46 PM, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>> Thanks, >>> Leonid. > From oleg.pekhovskiy at oracle.com Wed Jul 11 08:24:40 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Wed, 11 Jul 2012 19:24:40 +0400 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater Message-ID: <4FFD9AB8.2020001@oracle.com> Hi! Please review the fix for CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 Webrev: http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 The idea of the fix is that there are two concurrent threads that try to get two synchronization objects EventQueue.pushPopLock and PostEventQueue itself. For NetBeans these threads are (EDT & WarmUp) or (EDT & TimerQueue). Problem happens when EDT is interrupted and goes to EventQueue.detachDispatchThread() where EventQueue.pushPopLock is owned and EDT is waiting to own PostEventQueue when calling SunToolkit.isPostEventQueueEmpty() -> PostEventQueue.noEvents(). At the same time another thread calls EventQueue.postEvent() that calls EventQueue.flushPendingEvents() -> PostEventQueue.flush() where PostEventQueue is owned and another thread is waiting to own EventQueue.pushPopLock when calling EventQueue.postEvent() -> EventQueue.postEventPrivate(). To avoid potential deadlock I moved synchronization out of postEvent()'s cycle in PostEventQueue.flush(), but to be clear about the existence of Events that are not posted to EventQueue yet I added PostEventQueue.isPending flag that is true until the end of the cycle. There are only two classes that utilize PostEventQueue.flush() method: SunToolkit.flushPendingEvents() and SunToolkitSubclass.flushPendingEvents(). They are both synchronized by static SunToolkit.flushLock. That eliminates the situation when we have overlapped calls of PostEventQueue.flush(). Thanks, Oleg From anthony.petrov at oracle.com Wed Jul 11 08:35:53 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 11 Jul 2012 19:35:53 +0400 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <4FFD9AB8.2020001@oracle.com> References: <4FFD9AB8.2020001@oracle.com> Message-ID: <4FFD9D59.2030602@oracle.com> Hi Oleg, 1. I suggest to rename isPending to isFlushing, as it reflects the current state of the PostEventQueue more precisely. 2. I suggest to use the try{}finally{} pattern to set/reset the new flag in the flush() method to ensure the flag is reset even if the while() loop throws an exception. Otherwise the fix looks good. -- best regards, Anthony On 7/11/2012 7:24 PM, Oleg Pekhovskiy wrote: > Hi! > > Please review the fix for CR: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 > > Webrev: > http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 > > The idea of the fix is that there are two concurrent threads that try to > get two synchronization objects EventQueue.pushPopLock and > PostEventQueue itself. > For NetBeans these threads are (EDT & WarmUp) or (EDT & TimerQueue). > Problem happens when EDT is interrupted and goes to > EventQueue.detachDispatchThread() where EventQueue.pushPopLock is owned and > EDT is waiting to own PostEventQueue when calling > SunToolkit.isPostEventQueueEmpty() -> PostEventQueue.noEvents(). > At the same time another thread calls EventQueue.postEvent() that calls > EventQueue.flushPendingEvents() -> PostEventQueue.flush() where > PostEventQueue is owned > and another thread is waiting to own EventQueue.pushPopLock when calling > EventQueue.postEvent() -> EventQueue.postEventPrivate(). > > To avoid potential deadlock I moved synchronization out of postEvent()'s > cycle in PostEventQueue.flush(), > but to be clear about the existence of Events that are not posted to > EventQueue yet I added PostEventQueue.isPending flag that is true until > the end of the cycle. > > There are only two classes that utilize PostEventQueue.flush() method: > SunToolkit.flushPendingEvents() and > SunToolkitSubclass.flushPendingEvents(). > They are both synchronized by static SunToolkit.flushLock. That > eliminates the situation when we have overlapped calls of > PostEventQueue.flush(). > > Thanks, > Oleg From oleg.pekhovskiy at oracle.com Wed Jul 11 09:08:29 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Wed, 11 Jul 2012 20:08:29 +0400 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <4FFD9D59.2030602@oracle.com> References: <4FFD9AB8.2020001@oracle.com> <4FFD9D59.2030602@oracle.com> Message-ID: <4FFDA4FD.30009@oracle.com> Thank you for the review, Anthony, please review the next version of fix: http://cr.openjdk.java.net/~bagiras/7u6/7177040.2 I followed your suggestions there. I also added 'volatile' for isFlushing because it could be accessed from different threads. Thanks, Oleg 7/11/2012 7:35 PM, Anthony Petrov wrote: > Hi Oleg, > > 1. I suggest to rename isPending to isFlushing, as it reflects the > current state of the PostEventQueue more precisely. > > 2. I suggest to use the try{}finally{} pattern to set/reset the new > flag in the flush() method to ensure the flag is reset even if the > while() loop throws an exception. > > Otherwise the fix looks good. > > -- > best regards, > Anthony > > On 7/11/2012 7:24 PM, Oleg Pekhovskiy wrote: >> Hi! >> >> Please review the fix for CR: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 >> >> Webrev: >> http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 >> >> The idea of the fix is that there are two concurrent threads that try >> to get two synchronization objects EventQueue.pushPopLock and >> PostEventQueue itself. >> For NetBeans these threads are (EDT & WarmUp) or (EDT & TimerQueue). >> Problem happens when EDT is interrupted and goes to >> EventQueue.detachDispatchThread() where EventQueue.pushPopLock is >> owned and >> EDT is waiting to own PostEventQueue when calling >> SunToolkit.isPostEventQueueEmpty() -> PostEventQueue.noEvents(). >> At the same time another thread calls EventQueue.postEvent() that >> calls EventQueue.flushPendingEvents() -> PostEventQueue.flush() where >> PostEventQueue is owned >> and another thread is waiting to own EventQueue.pushPopLock when >> calling EventQueue.postEvent() -> EventQueue.postEventPrivate(). >> >> To avoid potential deadlock I moved synchronization out of >> postEvent()'s cycle in PostEventQueue.flush(), >> but to be clear about the existence of Events that are not posted to >> EventQueue yet I added PostEventQueue.isPending flag that is true >> until the end of the cycle. >> >> There are only two classes that utilize PostEventQueue.flush() >> method: SunToolkit.flushPendingEvents() and >> SunToolkitSubclass.flushPendingEvents(). >> They are both synchronized by static SunToolkit.flushLock. That >> eliminates the situation when we have overlapped calls of >> PostEventQueue.flush(). >> >> Thanks, >> Oleg From anthony.petrov at oracle.com Wed Jul 11 09:15:58 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 11 Jul 2012 20:15:58 +0400 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <4FFDA4FD.30009@oracle.com> References: <4FFD9AB8.2020001@oracle.com> <4FFD9D59.2030602@oracle.com> <4FFDA4FD.30009@oracle.com> Message-ID: <4FFDA6BE.2010909@oracle.com> Thanks for addressing the issues. The fix looks fine now. -- best regards, Anthony On 7/11/2012 8:08 PM, Oleg Pekhovskiy wrote: > Thank you for the review, Anthony, > > please review the next version of fix: > http://cr.openjdk.java.net/~bagiras/7u6/7177040.2 > > I followed your suggestions there. > I also added 'volatile' for isFlushing because it could be accessed from > different threads. > > Thanks, > Oleg > > 7/11/2012 7:35 PM, Anthony Petrov wrote: >> Hi Oleg, >> >> 1. I suggest to rename isPending to isFlushing, as it reflects the >> current state of the PostEventQueue more precisely. >> >> 2. I suggest to use the try{}finally{} pattern to set/reset the new >> flag in the flush() method to ensure the flag is reset even if the >> while() loop throws an exception. >> >> Otherwise the fix looks good. >> >> -- >> best regards, >> Anthony >> >> On 7/11/2012 7:24 PM, Oleg Pekhovskiy wrote: >>> Hi! >>> >>> Please review the fix for CR: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 >>> >>> The idea of the fix is that there are two concurrent threads that try >>> to get two synchronization objects EventQueue.pushPopLock and >>> PostEventQueue itself. >>> For NetBeans these threads are (EDT & WarmUp) or (EDT & TimerQueue). >>> Problem happens when EDT is interrupted and goes to >>> EventQueue.detachDispatchThread() where EventQueue.pushPopLock is >>> owned and >>> EDT is waiting to own PostEventQueue when calling >>> SunToolkit.isPostEventQueueEmpty() -> PostEventQueue.noEvents(). >>> At the same time another thread calls EventQueue.postEvent() that >>> calls EventQueue.flushPendingEvents() -> PostEventQueue.flush() where >>> PostEventQueue is owned >>> and another thread is waiting to own EventQueue.pushPopLock when >>> calling EventQueue.postEvent() -> EventQueue.postEventPrivate(). >>> >>> To avoid potential deadlock I moved synchronization out of >>> postEvent()'s cycle in PostEventQueue.flush(), >>> but to be clear about the existence of Events that are not posted to >>> EventQueue yet I added PostEventQueue.isPending flag that is true >>> until the end of the cycle. >>> >>> There are only two classes that utilize PostEventQueue.flush() >>> method: SunToolkit.flushPendingEvents() and >>> SunToolkitSubclass.flushPendingEvents(). >>> They are both synchronized by static SunToolkit.flushLock. That >>> eliminates the situation when we have overlapped calls of >>> PostEventQueue.flush(). >>> >>> Thanks, >>> Oleg > From oleg.pekhovskiy at oracle.com Wed Jul 11 09:14:16 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Wed, 11 Jul 2012 20:14:16 +0400 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <4FFDA6BE.2010909@oracle.com> References: <4FFD9AB8.2020001@oracle.com> <4FFD9D59.2030602@oracle.com> <4FFDA4FD.30009@oracle.com> <4FFDA6BE.2010909@oracle.com> Message-ID: <4FFDA658.400@oracle.com> Thank you, Anthony! Oleg. 7/11/2012 8:15 PM, Anthony Petrov wrote: > Thanks for addressing the issues. The fix looks fine now. > > -- > best regards, > Anthony > > On 7/11/2012 8:08 PM, Oleg Pekhovskiy wrote: >> Thank you for the review, Anthony, >> >> please review the next version of fix: >> http://cr.openjdk.java.net/~bagiras/7u6/7177040.2 >> >> I followed your suggestions there. >> I also added 'volatile' for isFlushing because it could be accessed >> from different threads. >> >> Thanks, >> Oleg >> >> 7/11/2012 7:35 PM, Anthony Petrov wrote: >>> Hi Oleg, >>> >>> 1. I suggest to rename isPending to isFlushing, as it reflects the >>> current state of the PostEventQueue more precisely. >>> >>> 2. I suggest to use the try{}finally{} pattern to set/reset the new >>> flag in the flush() method to ensure the flag is reset even if the >>> while() loop throws an exception. >>> >>> Otherwise the fix looks good. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 7/11/2012 7:24 PM, Oleg Pekhovskiy wrote: >>>> Hi! >>>> >>>> Please review the fix for CR: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 >>>> >>>> The idea of the fix is that there are two concurrent threads that >>>> try to get two synchronization objects EventQueue.pushPopLock and >>>> PostEventQueue itself. >>>> For NetBeans these threads are (EDT & WarmUp) or (EDT & TimerQueue). >>>> Problem happens when EDT is interrupted and goes to >>>> EventQueue.detachDispatchThread() where EventQueue.pushPopLock is >>>> owned and >>>> EDT is waiting to own PostEventQueue when calling >>>> SunToolkit.isPostEventQueueEmpty() -> PostEventQueue.noEvents(). >>>> At the same time another thread calls EventQueue.postEvent() that >>>> calls EventQueue.flushPendingEvents() -> PostEventQueue.flush() >>>> where PostEventQueue is owned >>>> and another thread is waiting to own EventQueue.pushPopLock when >>>> calling EventQueue.postEvent() -> EventQueue.postEventPrivate(). >>>> >>>> To avoid potential deadlock I moved synchronization out of >>>> postEvent()'s cycle in PostEventQueue.flush(), >>>> but to be clear about the existence of Events that are not posted >>>> to EventQueue yet I added PostEventQueue.isPending flag that is >>>> true until the end of the cycle. >>>> >>>> There are only two classes that utilize PostEventQueue.flush() >>>> method: SunToolkit.flushPendingEvents() and >>>> SunToolkitSubclass.flushPendingEvents(). >>>> They are both synchronized by static SunToolkit.flushLock. That >>>> eliminates the situation when we have overlapped calls of >>>> PostEventQueue.flush(). >>>> >>>> Thanks, >>>> Oleg >> From leonid.romanov at oracle.com Wed Jul 11 11:17:42 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 11 Jul 2012 22:17:42 +0400 Subject: [8] Review request for 7181027: [macosx] Unable to use headless mode Message-ID: Hi, Please review a fix for 7181027: [macosx] Unable to use headless mode, which exactly the same fix as for 7u6. Thanks, Leonid. From leonid.romanov at oracle.com Wed Jul 11 11:35:26 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 11 Jul 2012 22:35:26 +0400 Subject: [8] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: References: Message-ID: <4212A872-2C88-4076-A504-B1BA45E5CDA5@oracle.com> Ooops, sorry, here are the links: Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ On 11.07.2012, at 22:17, Leonid Romanov wrote: > Hi, > Please review a fix for 7181027: [macosx] Unable to use headless mode, which exactly the same fix as for 7u6. > > Thanks, > Leonid. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120711/cf845d28/attachment.html From anthony.petrov at oracle.com Wed Jul 11 14:52:07 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 12 Jul 2012 01:52:07 +0400 Subject: [8] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <4212A872-2C88-4076-A504-B1BA45E5CDA5@oracle.com> References: <4212A872-2C88-4076-A504-B1BA45E5CDA5@oracle.com> Message-ID: <4FFDF587.3070702@oracle.com> Looks fine to me. -- best regards, Anthony On 7/11/2012 10:35 PM, Leonid Romanov wrote: > Ooops, sorry, here are the links: > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 > Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ > > On 11.07.2012, at 22:17, Leonid Romanov wrote: > >> Hi, >> Please review a fix for 7181027: [macosx] Unable to use headless mode, >> which exactly the same fix as for 7u6. >> >> Thanks, >> Leonid. >> > From david.holmes at oracle.com Wed Jul 11 18:15:31 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Jul 2012 11:15:31 +1000 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> Message-ID: <4FFE2533.7020302@oracle.com> On 11/07/2012 11:46 PM, Leonid Romanov wrote: > Hi, > Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. sun.awt.HToolkit was introduced for use by SE-Embedded's reduced headless JRE. How did the OSX port end up using it ??? Headless handling on OSX should be like regular headless on Linux, Solaris. David > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 > Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ > > Thanks, > Leonid. > From david.holmes at oracle.com Wed Jul 11 18:41:43 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Jul 2012 11:41:43 +1000 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <4FFDA4FD.30009@oracle.com> References: <4FFD9AB8.2020001@oracle.com> <4FFD9D59.2030602@oracle.com> <4FFDA4FD.30009@oracle.com> Message-ID: <4FFE2B57.2000905@oracle.com> Hi Oleg, "deadlock" always grabs my attention :) On 12/07/2012 2:08 AM, Oleg Pekhovskiy wrote: > Thank you for the review, Anthony, > > please review the next version of fix: > http://cr.openjdk.java.net/~bagiras/7u6/7177040.2 > > I followed your suggestions there. > I also added 'volatile' for isFlushing because it could be accessed from > different threads. I was about to mention that :) I don't have the complete picture here but the actions of flush() no longer "ensure the flush is completed before a new event can be posted to this queue". The assurance may still be there in the way things are called, but it not ensured by the flush() method. It also seems that with this fix the interrupted EDT will not detach due to the flush being in progress. The EDT will resume the pumpEvents loop in its run() method. If the interrupt state of the EDT has not been maintained then the fact it was interrupted (and should detach?) is now lost. If it is maintained then presumably we will try to detachDispatchThread again, in which case the EDT will enter a busy polling loop trying, but failing, to detach, until the flush() has actually completed. Cheers, David > > Thanks, > Oleg > > 7/11/2012 7:35 PM, Anthony Petrov wrote: >> Hi Oleg, >> >> 1. I suggest to rename isPending to isFlushing, as it reflects the >> current state of the PostEventQueue more precisely. >> >> 2. I suggest to use the try{}finally{} pattern to set/reset the new >> flag in the flush() method to ensure the flag is reset even if the >> while() loop throws an exception. >> >> Otherwise the fix looks good. >> >> -- >> best regards, >> Anthony >> >> On 7/11/2012 7:24 PM, Oleg Pekhovskiy wrote: >>> Hi! >>> >>> Please review the fix for CR: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 >>> >>> The idea of the fix is that there are two concurrent threads that try >>> to get two synchronization objects EventQueue.pushPopLock and >>> PostEventQueue itself. >>> For NetBeans these threads are (EDT & WarmUp) or (EDT & TimerQueue). >>> Problem happens when EDT is interrupted and goes to >>> EventQueue.detachDispatchThread() where EventQueue.pushPopLock is >>> owned and >>> EDT is waiting to own PostEventQueue when calling >>> SunToolkit.isPostEventQueueEmpty() -> PostEventQueue.noEvents(). >>> At the same time another thread calls EventQueue.postEvent() that >>> calls EventQueue.flushPendingEvents() -> PostEventQueue.flush() where >>> PostEventQueue is owned >>> and another thread is waiting to own EventQueue.pushPopLock when >>> calling EventQueue.postEvent() -> EventQueue.postEventPrivate(). >>> >>> To avoid potential deadlock I moved synchronization out of >>> postEvent()'s cycle in PostEventQueue.flush(), >>> but to be clear about the existence of Events that are not posted to >>> EventQueue yet I added PostEventQueue.isPending flag that is true >>> until the end of the cycle. >>> >>> There are only two classes that utilize PostEventQueue.flush() >>> method: SunToolkit.flushPendingEvents() and >>> SunToolkitSubclass.flushPendingEvents(). >>> They are both synchronized by static SunToolkit.flushLock. That >>> eliminates the situation when we have overlapped calls of >>> PostEventQueue.flush(). >>> >>> Thanks, >>> Oleg > From leonid.romanov at oracle.com Thu Jul 12 01:58:56 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 12 Jul 2012 12:58:56 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <4FFE2533.7020302@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> Message-ID: <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> Perhaps Anthony might be able to answer your question: he has tinkered a lot with headless related stuff. David, are you implying that in the current form my fix is no-go? On 12.07.2012, at 5:15, David Holmes wrote: > On 11/07/2012 11:46 PM, Leonid Romanov wrote: >> Hi, >> Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. > > sun.awt.HToolkit was introduced for use by SE-Embedded's reduced headless JRE. How did the OSX port end up using it ??? > > Headless handling on OSX should be like regular headless on Linux, Solaris. > > David > >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >> >> Thanks, >> Leonid. >> From david.holmes at oracle.com Thu Jul 12 02:37:04 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Jul 2012 19:37:04 +1000 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> Message-ID: <4FFE9AC0.8010204@oracle.com> On 12/07/2012 6:58 PM, Leonid Romanov wrote: > Perhaps Anthony might be able to answer your question: he has tinkered a lot with headless related stuff. > David, are you implying that in the current form my fix is no-go? Not my place to do that. I'm just wondering how the HToolkit got involved with OSX, and why OSX headless is handled differently to Solaris/linux (which don't use HToolkit). David > On 12.07.2012, at 5:15, David Holmes wrote: > >> On 11/07/2012 11:46 PM, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. >> >> sun.awt.HToolkit was introduced for use by SE-Embedded's reduced headless JRE. How did the OSX port end up using it ??? >> >> Headless handling on OSX should be like regular headless on Linux, Solaris. >> >> David >> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>> >>> Thanks, >>> Leonid. >>> > From anthony.petrov at oracle.com Thu Jul 12 05:18:26 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 12 Jul 2012 16:18:26 +0400 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <4FFE2B57.2000905@oracle.com> References: <4FFD9AB8.2020001@oracle.com> <4FFD9D59.2030602@oracle.com> <4FFDA4FD.30009@oracle.com> <4FFE2B57.2000905@oracle.com> Message-ID: <4FFEC092.8090903@oracle.com> Hi David, On 07/12/12 05:41, David Holmes wrote: > "deadlock" always grabs my attention :) > > On 12/07/2012 2:08 AM, Oleg Pekhovskiy wrote: >> Thank you for the review, Anthony, >> >> please review the next version of fix: >> http://cr.openjdk.java.net/~bagiras/7u6/7177040.2 >> >> I followed your suggestions there. >> I also added 'volatile' for isFlushing because it could be accessed from >> different threads. > > I was about to mention that :) > > I don't have the complete picture here but the actions of flush() no > longer "ensure the flush is completed before a new event can be posted > to this queue". The assurance may still be there in the way things are > called, but it not ensured by the flush() method. This is a good catch. However, PostEventQueue.postEvent() will only add a new event to the queue, and will wakeup the EDT. This will only result in pushPopCond.signalAll() (see EventQueue.wakeup()), which should be harmless because flush() is posting the events to the EventQueue at the same time anyway. > It also seems that with this fix the interrupted EDT will not detach due > to the flush being in progress. The EDT will resume the pumpEvents loop > in its run() method. If the interrupt state of the EDT has not been > maintained then the fact it was interrupted (and should detach?) is now > lost. If it is maintained then presumably we will try to > detachDispatchThread again, in which case the EDT will enter a busy > polling loop trying, but failing, to detach, until the flush() has > actually completed. When interrupt() is called on EDT, the shutdown flag is set, which is subsequently passed as the forceDetach parameter to detachDispatchingThread(). If the parameter is true, the detaching happens unconditionally. So this shouldn't be an issue. -- best regards, Anthony > > Cheers, > David > >> >> Thanks, >> Oleg >> >> 7/11/2012 7:35 PM, Anthony Petrov wrote: >>> Hi Oleg, >>> >>> 1. I suggest to rename isPending to isFlushing, as it reflects the >>> current state of the PostEventQueue more precisely. >>> >>> 2. I suggest to use the try{}finally{} pattern to set/reset the new >>> flag in the flush() method to ensure the flag is reset even if the >>> while() loop throws an exception. >>> >>> Otherwise the fix looks good. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 7/11/2012 7:24 PM, Oleg Pekhovskiy wrote: >>>> Hi! >>>> >>>> Please review the fix for CR: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 >>>> >>>> The idea of the fix is that there are two concurrent threads that try >>>> to get two synchronization objects EventQueue.pushPopLock and >>>> PostEventQueue itself. >>>> For NetBeans these threads are (EDT & WarmUp) or (EDT & TimerQueue). >>>> Problem happens when EDT is interrupted and goes to >>>> EventQueue.detachDispatchThread() where EventQueue.pushPopLock is >>>> owned and >>>> EDT is waiting to own PostEventQueue when calling >>>> SunToolkit.isPostEventQueueEmpty() -> PostEventQueue.noEvents(). >>>> At the same time another thread calls EventQueue.postEvent() that >>>> calls EventQueue.flushPendingEvents() -> PostEventQueue.flush() where >>>> PostEventQueue is owned >>>> and another thread is waiting to own EventQueue.pushPopLock when >>>> calling EventQueue.postEvent() -> EventQueue.postEventPrivate(). >>>> >>>> To avoid potential deadlock I moved synchronization out of >>>> postEvent()'s cycle in PostEventQueue.flush(), >>>> but to be clear about the existence of Events that are not posted to >>>> EventQueue yet I added PostEventQueue.isPending flag that is true >>>> until the end of the cycle. >>>> >>>> There are only two classes that utilize PostEventQueue.flush() >>>> method: SunToolkit.flushPendingEvents() and >>>> SunToolkitSubclass.flushPendingEvents(). >>>> They are both synchronized by static SunToolkit.flushLock. That >>>> eliminates the situation when we have overlapped calls of >>>> PostEventQueue.flush(). >>>> >>>> Thanks, >>>> Oleg >> From anthony.petrov at oracle.com Thu Jul 12 05:33:22 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Thu, 12 Jul 2012 16:33:22 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> Message-ID: <4FFEC412.2060200@oracle.com> The logic is all in src/solaris/native/java/lang/java_props_macosx.c. The getPreferredToolkit() returns the HToolkit constant when the headless mode is needed on the Mac. And the GetJavaProperties() will then choose the sun.awt.HToolkit as the toolkit. Interesting. But it all seems to work fine in headless mode on the Mac, right? Leonid, did you run headless regression tests with your fix, btw? -- best regards, Anthony On 07/12/12 12:58, Leonid Romanov wrote: > Perhaps Anthony might be able to answer your question: he has tinkered a lot with headless related stuff. > David, are you implying that in the current form my fix is no-go? > > On 12.07.2012, at 5:15, David Holmes wrote: > >> On 11/07/2012 11:46 PM, Leonid Romanov wrote: >>> Hi, >>> Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. >> >> sun.awt.HToolkit was introduced for use by SE-Embedded's reduced headless JRE. How did the OSX port end up using it ??? >> >> Headless handling on OSX should be like regular headless on Linux, Solaris. >> >> David >> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>> >>> Thanks, >>> Leonid. >>> > From oleg.pekhovskiy at oracle.com Thu Jul 12 05:35:43 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 12 Jul 2012 16:35:43 +0400 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <4FFE2B57.2000905@oracle.com> References: <4FFD9AB8.2020001@oracle.com> <4FFD9D59.2030602@oracle.com> <4FFDA4FD.30009@oracle.com> <4FFE2B57.2000905@oracle.com> Message-ID: <4FFEC49F.7010008@oracle.com> Hi David, thank you for paying attention to that issue. I need it checking the fix from different points of view. I'll try to comment your thoughts: 1. We should differ PostEventQueue.postEvent and EventQueue.postEvent. But in both cases the order of posted events are kept as they goes. SunToolkit.flushLock guarantees that. From the other way PostEventQueue is not public class and its flush() method is called only from two classes: SunToolkit & SunToolkitSubclass. Their method flushPendingEvents both use SunToolkit.flushLock. 2. In spite of the fact EDT continues calling pumpEvents no events would be pumped because of EventDispatchThread.shutdown flag which is checked in EventDispatchThread.pumpEventsForFilter method in while-cycle condition that calls pumpOneEventForFilters. Thanks, Oleg 7/12/2012 5:41 AM, David Holmes wrote: > Hi Oleg, > > "deadlock" always grabs my attention :) > > On 12/07/2012 2:08 AM, Oleg Pekhovskiy wrote: >> Thank you for the review, Anthony, >> >> please review the next version of fix: >> http://cr.openjdk.java.net/~bagiras/7u6/7177040.2 >> >> I followed your suggestions there. >> I also added 'volatile' for isFlushing because it could be accessed from >> different threads. > > I was about to mention that :) > > I don't have the complete picture here but the actions of flush() no > longer "ensure the flush is completed before a new event can be posted > to this queue". The assurance may still be there in the way things are > called, but it not ensured by the flush() method. > > It also seems that with this fix the interrupted EDT will not detach > due to the flush being in progress. The EDT will resume the pumpEvents > loop in its run() method. If the interrupt state of the EDT has not > been maintained then the fact it was interrupted (and should detach?) > is now lost. If it is maintained then presumably we will try to > detachDispatchThread again, in which case the EDT will enter a busy > polling loop trying, but failing, to detach, until the flush() has > actually completed. > > Cheers, > David > >> >> Thanks, >> Oleg >> >> 7/11/2012 7:35 PM, Anthony Petrov wrote: >>> Hi Oleg, >>> >>> 1. I suggest to rename isPending to isFlushing, as it reflects the >>> current state of the PostEventQueue more precisely. >>> >>> 2. I suggest to use the try{}finally{} pattern to set/reset the new >>> flag in the flush() method to ensure the flag is reset even if the >>> while() loop throws an exception. >>> >>> Otherwise the fix looks good. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 7/11/2012 7:24 PM, Oleg Pekhovskiy wrote: >>>> Hi! >>>> >>>> Please review the fix for CR: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 >>>> >>>> The idea of the fix is that there are two concurrent threads that try >>>> to get two synchronization objects EventQueue.pushPopLock and >>>> PostEventQueue itself. >>>> For NetBeans these threads are (EDT & WarmUp) or (EDT & TimerQueue). >>>> Problem happens when EDT is interrupted and goes to >>>> EventQueue.detachDispatchThread() where EventQueue.pushPopLock is >>>> owned and >>>> EDT is waiting to own PostEventQueue when calling >>>> SunToolkit.isPostEventQueueEmpty() -> PostEventQueue.noEvents(). >>>> At the same time another thread calls EventQueue.postEvent() that >>>> calls EventQueue.flushPendingEvents() -> PostEventQueue.flush() where >>>> PostEventQueue is owned >>>> and another thread is waiting to own EventQueue.pushPopLock when >>>> calling EventQueue.postEvent() -> EventQueue.postEventPrivate(). >>>> >>>> To avoid potential deadlock I moved synchronization out of >>>> postEvent()'s cycle in PostEventQueue.flush(), >>>> but to be clear about the existence of Events that are not posted to >>>> EventQueue yet I added PostEventQueue.isPending flag that is true >>>> until the end of the cycle. >>>> >>>> There are only two classes that utilize PostEventQueue.flush() >>>> method: SunToolkit.flushPendingEvents() and >>>> SunToolkitSubclass.flushPendingEvents(). >>>> They are both synchronized by static SunToolkit.flushLock. That >>>> eliminates the situation when we have overlapped calls of >>>> PostEventQueue.flush(). >>>> >>>> Thanks, >>>> Oleg >> From anton.tarasov at oracle.com Thu Jul 12 06:27:14 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 12 Jul 2012 17:27:14 +0400 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <4FFDA4FD.30009@oracle.com> References: <4FFD9AB8.2020001@oracle.com> <4FFD9D59.2030602@oracle.com> <4FFDA4FD.30009@oracle.com> Message-ID: <4FFED0B2.7090602@oracle.com> Hi Oleg, I see nothing wrong in the fix. Hope you've run all the tests related. Thanks, Anton. On 11.07.2012 20:08, Oleg Pekhovskiy wrote: > Thank you for the review, Anthony, > > please review the next version of fix: > http://cr.openjdk.java.net/~bagiras/7u6/7177040.2 > > I followed your suggestions there. > I also added 'volatile' for isFlushing because it could be accessed from different threads. > > Thanks, > Oleg > > 7/11/2012 7:35 PM, Anthony Petrov wrote: >> Hi Oleg, >> >> 1. I suggest to rename isPending to isFlushing, as it reflects the current state of the >> PostEventQueue more precisely. >> >> 2. I suggest to use the try{}finally{} pattern to set/reset the new flag in the flush() method to >> ensure the flag is reset even if the while() loop throws an exception. >> >> Otherwise the fix looks good. >> >> -- >> best regards, >> Anthony >> >> On 7/11/2012 7:24 PM, Oleg Pekhovskiy wrote: >>> Hi! >>> >>> Please review the fix for CR: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 >>> >>> The idea of the fix is that there are two concurrent threads that try to get two synchronization >>> objects EventQueue.pushPopLock and PostEventQueue itself. >>> For NetBeans these threads are (EDT & WarmUp) or (EDT & TimerQueue). >>> Problem happens when EDT is interrupted and goes to EventQueue.detachDispatchThread() where >>> EventQueue.pushPopLock is owned and >>> EDT is waiting to own PostEventQueue when calling SunToolkit.isPostEventQueueEmpty() -> >>> PostEventQueue.noEvents(). >>> At the same time another thread calls EventQueue.postEvent() that calls >>> EventQueue.flushPendingEvents() -> PostEventQueue.flush() where PostEventQueue is owned >>> and another thread is waiting to own EventQueue.pushPopLock when calling EventQueue.postEvent() >>> -> EventQueue.postEventPrivate(). >>> >>> To avoid potential deadlock I moved synchronization out of postEvent()'s cycle in >>> PostEventQueue.flush(), >>> but to be clear about the existence of Events that are not posted to EventQueue yet I added >>> PostEventQueue.isPending flag that is true until the end of the cycle. >>> >>> There are only two classes that utilize PostEventQueue.flush() method: >>> SunToolkit.flushPendingEvents() and SunToolkitSubclass.flushPendingEvents(). >>> They are both synchronized by static SunToolkit.flushLock. That eliminates the situation when we >>> have overlapped calls of PostEventQueue.flush(). >>> >>> Thanks, >>> Oleg > From oleg.pekhovskiy at oracle.com Thu Jul 12 06:53:03 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 12 Jul 2012 17:53:03 +0400 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <4FFED0B2.7090602@oracle.com> References: <4FFD9AB8.2020001@oracle.com> <4FFD9D59.2030602@oracle.com> <4FFDA4FD.30009@oracle.com> <4FFED0B2.7090602@oracle.com> Message-ID: <4FFED6BF.3030202@oracle.com> Anton, thank you for the review! Oleg. 7/12/2012 5:27 PM, Anton V. Tarasov wrote: > Hi Oleg, > > I see nothing wrong in the fix. Hope you've run all the tests related. > > Thanks, > Anton. > > On 11.07.2012 20:08, Oleg Pekhovskiy wrote: >> Thank you for the review, Anthony, >> >> please review the next version of fix: >> http://cr.openjdk.java.net/~bagiras/7u6/7177040.2 >> >> I followed your suggestions there. >> I also added 'volatile' for isFlushing because it could be accessed >> from different threads. >> >> Thanks, >> Oleg >> >> 7/11/2012 7:35 PM, Anthony Petrov wrote: >>> Hi Oleg, >>> >>> 1. I suggest to rename isPending to isFlushing, as it reflects the >>> current state of the PostEventQueue more precisely. >>> >>> 2. I suggest to use the try{}finally{} pattern to set/reset the new >>> flag in the flush() method to ensure the flag is reset even if the >>> while() loop throws an exception. >>> >>> Otherwise the fix looks good. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 7/11/2012 7:24 PM, Oleg Pekhovskiy wrote: >>>> Hi! >>>> >>>> Please review the fix for CR: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 >>>> >>>> The idea of the fix is that there are two concurrent threads that >>>> try to get two synchronization objects EventQueue.pushPopLock and >>>> PostEventQueue itself. >>>> For NetBeans these threads are (EDT & WarmUp) or (EDT & TimerQueue). >>>> Problem happens when EDT is interrupted and goes to >>>> EventQueue.detachDispatchThread() where EventQueue.pushPopLock is >>>> owned and >>>> EDT is waiting to own PostEventQueue when calling >>>> SunToolkit.isPostEventQueueEmpty() -> PostEventQueue.noEvents(). >>>> At the same time another thread calls EventQueue.postEvent() that >>>> calls EventQueue.flushPendingEvents() -> PostEventQueue.flush() >>>> where PostEventQueue is owned >>>> and another thread is waiting to own EventQueue.pushPopLock when >>>> calling EventQueue.postEvent() -> EventQueue.postEventPrivate(). >>>> >>>> To avoid potential deadlock I moved synchronization out of >>>> postEvent()'s cycle in PostEventQueue.flush(), >>>> but to be clear about the existence of Events that are not posted >>>> to EventQueue yet I added PostEventQueue.isPending flag that is >>>> true until the end of the cycle. >>>> >>>> There are only two classes that utilize PostEventQueue.flush() >>>> method: SunToolkit.flushPendingEvents() and >>>> SunToolkitSubclass.flushPendingEvents(). >>>> They are both synchronized by static SunToolkit.flushLock. That >>>> eliminates the situation when we have overlapped calls of >>>> PostEventQueue.flush(). >>>> >>>> Thanks, >>>> Oleg >> > From ptisnovs at redhat.com Thu Jul 12 07:54:13 2012 From: ptisnovs at redhat.com (ptisnovs at redhat.com) Date: Thu, 12 Jul 2012 14:54:13 +0000 Subject: hg: jdk8/awt/jdk: 7022041: TitleBorder Null Pointer Exception Message-ID: <20120712145431.E84D647FC6@hg.openjdk.java.net> Changeset: 4d750ca79fb7 Author: ptisnovs Date: 2012-07-12 16:54 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4d750ca79fb7 7022041: TitleBorder Null Pointer Exception Summary: Added check if getTitleFont() and getTitleColor() don't return null Reviewed-by: alexsch ! src/share/classes/javax/swing/border/TitledBorder.java + test/javax/swing/border/Test7022041.java From Sergey.Bylokhov at oracle.com Thu Jul 12 08:28:12 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Jul 2012 19:28:12 +0400 Subject: [8] Review request for 7170657: [macosx] There seems to be no keyboard/mouse action to select non-contiguous items in List Message-ID: <4FFEED0C.2010709@oracle.com> Hi Everyone, Please review the fix. Bug in SwingUtilities.convertMouseEvent().This method does not convert extended state of the event. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170657 Webrev can be found at: http://cr.openjdk.java.net/~serb/7170657/webrev.00 -- Best regards, Sergey. From pavel.porvatov at oracle.com Thu Jul 12 09:26:19 2012 From: pavel.porvatov at oracle.com (Pavel Porvatov) Date: Thu, 12 Jul 2012 20:26:19 +0400 Subject: [8] Review request for 7170657: [macosx] There seems to be no keyboard/mouse action to select non-contiguous items in List In-Reply-To: <4FFEED0C.2010709@oracle.com> References: <4FFEED0C.2010709@oracle.com> Message-ID: <4FFEFAAB.2040109@oracle.com> Hi Sergey, The fix looks good. Could you please remove unnecessary code from the test like: 1. @run main/othervm bug7170657 2. The "FAILED" field: you can throw exception from the "fail" method 3. What is the reason to use final here: "public final class"? Regards, Pavel > Hi Everyone, > Please review the fix. > Bug in SwingUtilities.convertMouseEvent().This method does not convert > extended state of the event. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170657 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7170657/webrev.00 > From Sergey.Bylokhov at oracle.com Thu Jul 12 09:52:13 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Jul 2012 20:52:13 +0400 Subject: [8] Review request for 7170657: [macosx] There seems to be no keyboard/mouse action to select non-contiguous items in List In-Reply-To: <4FFEFAAB.2040109@oracle.com> References: <4FFEED0C.2010709@oracle.com> <4FFEFAAB.2040109@oracle.com> Message-ID: <4FFF00BD.8030804@oracle.com> Hi, Pavel. Thanks for review. See comments inline 12.07.2012 20:26, Pavel Porvatov wrote: > Hi Sergey, > > The fix looks good. Could you please remove unnecessary code from the > test like: > > 1. @run main/othervm bug7170657 done > 2. The "FAILED" field: you can throw exception from the "fail" method In this case we skip part of the test. Useful for debug. > 3. What is the reason to use final here: "public final class"? I do not think that someone will want to be inherited from it. I just make all classes final by default. New version of the fix: http://cr.openjdk.java.net/~serb/7170657/webrev.01/ > > Regards, Pavel >> Hi Everyone, >> Please review the fix. >> Bug in SwingUtilities.convertMouseEvent().This method does not >> convert extended state of the event. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170657 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7170657/webrev.00 >> > -- Best regards, Sergey. From leonid.romanov at oracle.com Thu Jul 12 01:58:56 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 12 Jul 2012 12:58:56 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <4FFE2533.7020302@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> Message-ID: <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> Perhaps Anthony might be able to answer your question: he has tinkered a lot with headless related stuff. David, are you implying that in the current form my fix is no-go? On 12.07.2012, at 5:15, David Holmes wrote: > On 11/07/2012 11:46 PM, Leonid Romanov wrote: >> Hi, >> Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here is that for headless mode "java.awt.graphicsenv" system property should be CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works: it first instantiates GraphicsEnvironment instance and then wraps it with HeadlessGraphicsEnvironment if in headless mode. This means twe can't use java.awt.graphicsenv property to determine whether we are in headless mode or not. So, I've replaced it with a toolkit check: if it's HToolkit, then we are in headless. > > sun.awt.HToolkit was introduced for use by SE-Embedded's reduced headless JRE. How did the OSX port end up using it ??? > > Headless handling on OSX should be like regular headless on Linux, Solaris. > > David > >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >> >> Thanks, >> Leonid. >> From david.holmes at oracle.com Thu Jul 12 14:10:38 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Jul 2012 07:10:38 +1000 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <4FFEC092.8090903@oracle.com> References: <4FFD9AB8.2020001@oracle.com> <4FFD9D59.2030602@oracle.com> <4FFDA4FD.30009@oracle.com> <4FFE2B57.2000905@oracle.com> <4FFEC092.8090903@oracle.com> Message-ID: <4FFF3D4E.5020104@oracle.com> On 12/07/2012 10:18 PM, Anthony Petrov wrote: > On 07/12/12 05:41, David Holmes wrote: >> It also seems that with this fix the interrupted EDT will not detach due >> to the flush being in progress. The EDT will resume the pumpEvents loop >> in its run() method. If the interrupt state of the EDT has not been >> maintained then the fact it was interrupted (and should detach?) is now >> lost. If it is maintained then presumably we will try to >> detachDispatchThread again, in which case the EDT will enter a busy >> polling loop trying, but failing, to detach, until the flush() has >> actually completed. > > When interrupt() is called on EDT, the shutdown flag is set, which is > subsequently passed as the forceDetach parameter to > detachDispatchingThread(). If the parameter is true, the detaching > happens unconditionally. So this shouldn't be an issue. I don't quite follow this part. The logic is: if (!forceDetach && (peekEvent() != null) || !SunToolkit.isPostEventQueueEmpty()) { return false; } If forceDetach is true then we won't execute peekEvent() and isPostEventQueueEmpty(), which means we would not have hit the original deadlock. Oleg's response seems to indicate that we will indeed keep looping but because of the values of various flags we won't do anything "useful". But that is the kind of "busy wait" that I was referring to. Cheers, David > -- > best regards, > Anthony > > >> >> Cheers, >> David >> >>> >>> Thanks, >>> Oleg >>> >>> 7/11/2012 7:35 PM, Anthony Petrov wrote: >>>> Hi Oleg, >>>> >>>> 1. I suggest to rename isPending to isFlushing, as it reflects the >>>> current state of the PostEventQueue more precisely. >>>> >>>> 2. I suggest to use the try{}finally{} pattern to set/reset the new >>>> flag in the flush() method to ensure the flag is reset even if the >>>> while() loop throws an exception. >>>> >>>> Otherwise the fix looks good. >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 7/11/2012 7:24 PM, Oleg Pekhovskiy wrote: >>>>> Hi! >>>>> >>>>> Please review the fix for CR: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 >>>>> >>>>> The idea of the fix is that there are two concurrent threads that try >>>>> to get two synchronization objects EventQueue.pushPopLock and >>>>> PostEventQueue itself. >>>>> For NetBeans these threads are (EDT & WarmUp) or (EDT & TimerQueue). >>>>> Problem happens when EDT is interrupted and goes to >>>>> EventQueue.detachDispatchThread() where EventQueue.pushPopLock is >>>>> owned and >>>>> EDT is waiting to own PostEventQueue when calling >>>>> SunToolkit.isPostEventQueueEmpty() -> PostEventQueue.noEvents(). >>>>> At the same time another thread calls EventQueue.postEvent() that >>>>> calls EventQueue.flushPendingEvents() -> PostEventQueue.flush() where >>>>> PostEventQueue is owned >>>>> and another thread is waiting to own EventQueue.pushPopLock when >>>>> calling EventQueue.postEvent() -> EventQueue.postEventPrivate(). >>>>> >>>>> To avoid potential deadlock I moved synchronization out of >>>>> postEvent()'s cycle in PostEventQueue.flush(), >>>>> but to be clear about the existence of Events that are not posted to >>>>> EventQueue yet I added PostEventQueue.isPending flag that is true >>>>> until the end of the cycle. >>>>> >>>>> There are only two classes that utilize PostEventQueue.flush() >>>>> method: SunToolkit.flushPendingEvents() and >>>>> SunToolkitSubclass.flushPendingEvents(). >>>>> They are both synchronized by static SunToolkit.flushLock. That >>>>> eliminates the situation when we have overlapped calls of >>>>> PostEventQueue.flush(). >>>>> >>>>> Thanks, >>>>> Oleg >>> From david.holmes at oracle.com Thu Jul 12 14:26:13 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Jul 2012 07:26:13 +1000 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <4FFEC412.2060200@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> Message-ID: <4FFF40F5.7090508@oracle.com> On 12/07/2012 10:33 PM, Anthony Petrov wrote: > The logic is all in src/solaris/native/java/lang/java_props_macosx.c. > The getPreferredToolkit() returns the HToolkit constant when the > headless mode is needed on the Mac. And the GetJavaProperties() will > then choose the sun.awt.HToolkit as the toolkit. Interesting. Interesting indeed. But my concerns remain. HToolkit was not intended for general use. OSX seems to be handling headless mode in a completely different way to Solaris/linux. Of course it may be that on OSX you run into the same conditions when headless that required the introduction of HToolkit. But somebody should have made a very conscious decision to do that. > But it all seems to work fine in headless mode on the Mac, right? You mean apart from this bug? ;-) I see a few bugs involving headless on OSX. Cheers, David > Leonid, did you run headless regression tests with your fix, btw? > > -- > best regards, > Anthony > > On 07/12/12 12:58, Leonid Romanov wrote: >> Perhaps Anthony might be able to answer your question: he has tinkered >> a lot with headless related stuff. >> David, are you implying that in the current form my fix is no-go? >> >> On 12.07.2012, at 5:15, David Holmes wrote: >> >>> On 11/07/2012 11:46 PM, Leonid Romanov wrote: >>>> Hi, >>>> Please review a fix for 7181027: [macosx] Unable to use headless >>>> mode. The problem here is that for headless mode >>>> "java.awt.graphicsenv" system property should be >>>> CGraphicsEnvironment because the way GraphicsEnvironment.createGE() >>>> method works: it first instantiates GraphicsEnvironment instance and >>>> then wraps it with HeadlessGraphicsEnvironment if in headless mode. >>>> This means twe can't use java.awt.graphicsenv property to determine >>>> whether we are in headless mode or not. So, I've replaced it with a >>>> toolkit check: if it's HToolkit, then we are in headless. >>> >>> sun.awt.HToolkit was introduced for use by SE-Embedded's reduced >>> headless JRE. How did the OSX port end up using it ??? >>> >>> Headless handling on OSX should be like regular headless on Linux, >>> Solaris. >>> >>> David >>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>>> >>>> Thanks, >>>> Leonid. >>>> >> From oleg.pekhovskiy at oracle.com Thu Jul 12 15:13:41 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 13 Jul 2012 02:13:41 +0400 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <4FFF3D4E.5020104@oracle.com> References: <4FFD9AB8.2020001@oracle.com> <4FFD9D59.2030602@oracle.com> <4FFDA4FD.30009@oracle.com> <4FFE2B57.2000905@oracle.com> <4FFEC092.8090903@oracle.com> <4FFF3D4E.5020104@oracle.com> Message-ID: <4FFF4C15.7060108@oracle.com> Hi David, the condition you mentioned: if (!forceDetach && (peekEvent() != null) || !SunToolkit.isPostEventQueueEmpty()) { return false; } could lead to understanding problem (braces are the best way to clarify). && has higher priority than ||, thus we could rewrite that condition like this: ( !forceDetach && (peekEvent() != null) ) || !SunToolkit.isPostEventQueueEmpty() That means SunToolkit.isPostEventQueueEmpty() is called when: forceDetach == true OR peekEvent() == null OR both above. Anthony has pushed the fix that changes (and simplifies) that place: http://cr.openjdk.java.net/~anthony/7u6-16-missingAWTThread-7162144.0/ So maybe we should discuss the new code - the new behavior. Thanks, Oleg 7/13/2012 1:10 AM, David Holmes wrote: > On 12/07/2012 10:18 PM, Anthony Petrov wrote: >> On 07/12/12 05:41, David Holmes wrote: > > > >>> It also seems that with this fix the interrupted EDT will not detach >>> due >>> to the flush being in progress. The EDT will resume the pumpEvents loop >>> in its run() method. If the interrupt state of the EDT has not been >>> maintained then the fact it was interrupted (and should detach?) is now >>> lost. If it is maintained then presumably we will try to >>> detachDispatchThread again, in which case the EDT will enter a busy >>> polling loop trying, but failing, to detach, until the flush() has >>> actually completed. >> >> When interrupt() is called on EDT, the shutdown flag is set, which is >> subsequently passed as the forceDetach parameter to >> detachDispatchingThread(). If the parameter is true, the detaching >> happens unconditionally. So this shouldn't be an issue. > > I don't quite follow this part. The logic is: > > if (!forceDetach && (peekEvent() != null) || > !SunToolkit.isPostEventQueueEmpty()) { > return false; > } > > If forceDetach is true then we won't execute peekEvent() and > isPostEventQueueEmpty(), which means we would not have hit the > original deadlock. > > Oleg's response seems to indicate that we will indeed keep looping but > because of the values of various flags we won't do anything "useful". > But that is the kind of "busy wait" that I was referring to. > > Cheers, > David > > > >> -- >> best regards, >> Anthony >> >> >>> >>> Cheers, >>> David >>> >>>> >>>> Thanks, >>>> Oleg >>>> >>>> 7/11/2012 7:35 PM, Anthony Petrov wrote: >>>>> Hi Oleg, >>>>> >>>>> 1. I suggest to rename isPending to isFlushing, as it reflects the >>>>> current state of the PostEventQueue more precisely. >>>>> >>>>> 2. I suggest to use the try{}finally{} pattern to set/reset the new >>>>> flag in the flush() method to ensure the flag is reset even if the >>>>> while() loop throws an exception. >>>>> >>>>> Otherwise the fix looks good. >>>>> >>>>> -- >>>>> best regards, >>>>> Anthony >>>>> >>>>> On 7/11/2012 7:24 PM, Oleg Pekhovskiy wrote: >>>>>> Hi! >>>>>> >>>>>> Please review the fix for CR: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 >>>>>> >>>>>> The idea of the fix is that there are two concurrent threads that >>>>>> try >>>>>> to get two synchronization objects EventQueue.pushPopLock and >>>>>> PostEventQueue itself. >>>>>> For NetBeans these threads are (EDT & WarmUp) or (EDT & TimerQueue). >>>>>> Problem happens when EDT is interrupted and goes to >>>>>> EventQueue.detachDispatchThread() where EventQueue.pushPopLock is >>>>>> owned and >>>>>> EDT is waiting to own PostEventQueue when calling >>>>>> SunToolkit.isPostEventQueueEmpty() -> PostEventQueue.noEvents(). >>>>>> At the same time another thread calls EventQueue.postEvent() that >>>>>> calls EventQueue.flushPendingEvents() -> PostEventQueue.flush() >>>>>> where >>>>>> PostEventQueue is owned >>>>>> and another thread is waiting to own EventQueue.pushPopLock when >>>>>> calling EventQueue.postEvent() -> EventQueue.postEventPrivate(). >>>>>> >>>>>> To avoid potential deadlock I moved synchronization out of >>>>>> postEvent()'s cycle in PostEventQueue.flush(), >>>>>> but to be clear about the existence of Events that are not posted to >>>>>> EventQueue yet I added PostEventQueue.isPending flag that is true >>>>>> until the end of the cycle. >>>>>> >>>>>> There are only two classes that utilize PostEventQueue.flush() >>>>>> method: SunToolkit.flushPendingEvents() and >>>>>> SunToolkitSubclass.flushPendingEvents(). >>>>>> They are both synchronized by static SunToolkit.flushLock. That >>>>>> eliminates the situation when we have overlapped calls of >>>>>> PostEventQueue.flush(). >>>>>> >>>>>> Thanks, >>>>>> Oleg >>>> From david.holmes at oracle.com Thu Jul 12 16:25:48 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Jul 2012 09:25:48 +1000 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <4FFF4C15.7060108@oracle.com> References: <4FFD9AB8.2020001@oracle.com> <4FFD9D59.2030602@oracle.com> <4FFDA4FD.30009@oracle.com> <4FFE2B57.2000905@oracle.com> <4FFEC092.8090903@oracle.com> <4FFF3D4E.5020104@oracle.com> <4FFF4C15.7060108@oracle.com> Message-ID: <4FFF5CFC.1010902@oracle.com> On 13/07/2012 8:13 AM, Oleg Pekhovskiy wrote: > Hi David, > > the condition you mentioned: > > if (!forceDetach && (peekEvent() != null) || > !SunToolkit.isPostEventQueueEmpty()) { > return false; > } > > could lead to understanding problem (braces are the best way to clarify). > > && has higher priority than ||, thus we could rewrite that condition > like this: > > ( !forceDetach && (peekEvent() != null) ) || > !SunToolkit.isPostEventQueueEmpty() Sorry - need to clean my glasses. I was seeing !f && ( X || Y) :( > That means SunToolkit.isPostEventQueueEmpty() is called when: > forceDetach == true > OR > peekEvent() == null > OR > both above. > > Anthony has pushed the fix that changes (and simplifies) that place: > http://cr.openjdk.java.net/~anthony/7u6-16-missingAWTThread-7162144.0/ > So maybe we should discuss the new code - the new behavior. Yes I saw that patch too. All clear now. Thanks, David > Thanks, > Oleg > > 7/13/2012 1:10 AM, David Holmes wrote: >> On 12/07/2012 10:18 PM, Anthony Petrov wrote: >>> On 07/12/12 05:41, David Holmes wrote: >> >> >> >>>> It also seems that with this fix the interrupted EDT will not detach >>>> due >>>> to the flush being in progress. The EDT will resume the pumpEvents loop >>>> in its run() method. If the interrupt state of the EDT has not been >>>> maintained then the fact it was interrupted (and should detach?) is now >>>> lost. If it is maintained then presumably we will try to >>>> detachDispatchThread again, in which case the EDT will enter a busy >>>> polling loop trying, but failing, to detach, until the flush() has >>>> actually completed. >>> >>> When interrupt() is called on EDT, the shutdown flag is set, which is >>> subsequently passed as the forceDetach parameter to >>> detachDispatchingThread(). If the parameter is true, the detaching >>> happens unconditionally. So this shouldn't be an issue. >> >> I don't quite follow this part. The logic is: >> >> if (!forceDetach && (peekEvent() != null) || >> !SunToolkit.isPostEventQueueEmpty()) { >> return false; >> } >> >> If forceDetach is true then we won't execute peekEvent() and >> isPostEventQueueEmpty(), which means we would not have hit the >> original deadlock. >> >> Oleg's response seems to indicate that we will indeed keep looping but >> because of the values of various flags we won't do anything "useful". >> But that is the kind of "busy wait" that I was referring to. >> >> Cheers, >> David >> >> >> >>> -- >>> best regards, >>> Anthony >>> >>> >>>> >>>> Cheers, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> Oleg >>>>> >>>>> 7/11/2012 7:35 PM, Anthony Petrov wrote: >>>>>> Hi Oleg, >>>>>> >>>>>> 1. I suggest to rename isPending to isFlushing, as it reflects the >>>>>> current state of the PostEventQueue more precisely. >>>>>> >>>>>> 2. I suggest to use the try{}finally{} pattern to set/reset the new >>>>>> flag in the flush() method to ensure the flag is reset even if the >>>>>> while() loop throws an exception. >>>>>> >>>>>> Otherwise the fix looks good. >>>>>> >>>>>> -- >>>>>> best regards, >>>>>> Anthony >>>>>> >>>>>> On 7/11/2012 7:24 PM, Oleg Pekhovskiy wrote: >>>>>>> Hi! >>>>>>> >>>>>>> Please review the fix for CR: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 >>>>>>> >>>>>>> The idea of the fix is that there are two concurrent threads that >>>>>>> try >>>>>>> to get two synchronization objects EventQueue.pushPopLock and >>>>>>> PostEventQueue itself. >>>>>>> For NetBeans these threads are (EDT & WarmUp) or (EDT & TimerQueue). >>>>>>> Problem happens when EDT is interrupted and goes to >>>>>>> EventQueue.detachDispatchThread() where EventQueue.pushPopLock is >>>>>>> owned and >>>>>>> EDT is waiting to own PostEventQueue when calling >>>>>>> SunToolkit.isPostEventQueueEmpty() -> PostEventQueue.noEvents(). >>>>>>> At the same time another thread calls EventQueue.postEvent() that >>>>>>> calls EventQueue.flushPendingEvents() -> PostEventQueue.flush() >>>>>>> where >>>>>>> PostEventQueue is owned >>>>>>> and another thread is waiting to own EventQueue.pushPopLock when >>>>>>> calling EventQueue.postEvent() -> EventQueue.postEventPrivate(). >>>>>>> >>>>>>> To avoid potential deadlock I moved synchronization out of >>>>>>> postEvent()'s cycle in PostEventQueue.flush(), >>>>>>> but to be clear about the existence of Events that are not posted to >>>>>>> EventQueue yet I added PostEventQueue.isPending flag that is true >>>>>>> until the end of the cycle. >>>>>>> >>>>>>> There are only two classes that utilize PostEventQueue.flush() >>>>>>> method: SunToolkit.flushPendingEvents() and >>>>>>> SunToolkitSubclass.flushPendingEvents(). >>>>>>> They are both synchronized by static SunToolkit.flushLock. That >>>>>>> eliminates the situation when we have overlapped calls of >>>>>>> PostEventQueue.flush(). >>>>>>> >>>>>>> Thanks, >>>>>>> Oleg >>>>> > From oleg.pekhovskiy at oracle.com Thu Jul 12 16:28:19 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 13 Jul 2012 03:28:19 +0400 Subject: [7u6] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <4FFF5CFC.1010902@oracle.com> References: <4FFD9AB8.2020001@oracle.com> <4FFD9D59.2030602@oracle.com> <4FFDA4FD.30009@oracle.com> <4FFE2B57.2000905@oracle.com> <4FFEC092.8090903@oracle.com> <4FFF3D4E.5020104@oracle.com> <4FFF4C15.7060108@oracle.com> <4FFF5CFC.1010902@oracle.com> Message-ID: <4FFF5D93.4080403@oracle.com> No probs :) Thank you, Oleg. 13.07.2012 3:25, David Holmes wrote: > On 13/07/2012 8:13 AM, Oleg Pekhovskiy wrote: >> Hi David, >> >> the condition you mentioned: >> >> if (!forceDetach && (peekEvent() != null) || >> !SunToolkit.isPostEventQueueEmpty()) { >> return false; >> } >> >> could lead to understanding problem (braces are the best way to >> clarify). >> >> && has higher priority than ||, thus we could rewrite that condition >> like this: >> >> ( !forceDetach && (peekEvent() != null) ) || >> !SunToolkit.isPostEventQueueEmpty() > > Sorry - need to clean my glasses. I was seeing !f && ( X || Y) > > :( > >> That means SunToolkit.isPostEventQueueEmpty() is called when: >> forceDetach == true >> OR >> peekEvent() == null >> OR >> both above. >> >> Anthony has pushed the fix that changes (and simplifies) that place: >> http://cr.openjdk.java.net/~anthony/7u6-16-missingAWTThread-7162144.0/ >> So maybe we should discuss the new code - the new behavior. > > Yes I saw that patch too. All clear now. > > Thanks, > David > > >> Thanks, >> Oleg >> >> 7/13/2012 1:10 AM, David Holmes wrote: >>> On 12/07/2012 10:18 PM, Anthony Petrov wrote: >>>> On 07/12/12 05:41, David Holmes wrote: >>> >>> >>> >>>>> It also seems that with this fix the interrupted EDT will not detach >>>>> due >>>>> to the flush being in progress. The EDT will resume the pumpEvents >>>>> loop >>>>> in its run() method. If the interrupt state of the EDT has not been >>>>> maintained then the fact it was interrupted (and should detach?) >>>>> is now >>>>> lost. If it is maintained then presumably we will try to >>>>> detachDispatchThread again, in which case the EDT will enter a busy >>>>> polling loop trying, but failing, to detach, until the flush() has >>>>> actually completed. >>>> >>>> When interrupt() is called on EDT, the shutdown flag is set, which is >>>> subsequently passed as the forceDetach parameter to >>>> detachDispatchingThread(). If the parameter is true, the detaching >>>> happens unconditionally. So this shouldn't be an issue. >>> >>> I don't quite follow this part. The logic is: >>> >>> if (!forceDetach && (peekEvent() != null) || >>> !SunToolkit.isPostEventQueueEmpty()) { >>> return false; >>> } >>> >>> If forceDetach is true then we won't execute peekEvent() and >>> isPostEventQueueEmpty(), which means we would not have hit the >>> original deadlock. >>> >>> Oleg's response seems to indicate that we will indeed keep looping but >>> because of the values of various flags we won't do anything "useful". >>> But that is the kind of "busy wait" that I was referring to. >>> >>> Cheers, >>> David >>> >>> >>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> Oleg >>>>>> >>>>>> 7/11/2012 7:35 PM, Anthony Petrov wrote: >>>>>>> Hi Oleg, >>>>>>> >>>>>>> 1. I suggest to rename isPending to isFlushing, as it reflects the >>>>>>> current state of the PostEventQueue more precisely. >>>>>>> >>>>>>> 2. I suggest to use the try{}finally{} pattern to set/reset the new >>>>>>> flag in the flush() method to ensure the flag is reset even if the >>>>>>> while() loop throws an exception. >>>>>>> >>>>>>> Otherwise the fix looks good. >>>>>>> >>>>>>> -- >>>>>>> best regards, >>>>>>> Anthony >>>>>>> >>>>>>> On 7/11/2012 7:24 PM, Oleg Pekhovskiy wrote: >>>>>>>> Hi! >>>>>>>> >>>>>>>> Please review the fix for CR: >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177040 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~bagiras/7u6/7177040.1 >>>>>>>> >>>>>>>> The idea of the fix is that there are two concurrent threads that >>>>>>>> try >>>>>>>> to get two synchronization objects EventQueue.pushPopLock and >>>>>>>> PostEventQueue itself. >>>>>>>> For NetBeans these threads are (EDT & WarmUp) or (EDT & >>>>>>>> TimerQueue). >>>>>>>> Problem happens when EDT is interrupted and goes to >>>>>>>> EventQueue.detachDispatchThread() where EventQueue.pushPopLock is >>>>>>>> owned and >>>>>>>> EDT is waiting to own PostEventQueue when calling >>>>>>>> SunToolkit.isPostEventQueueEmpty() -> PostEventQueue.noEvents(). >>>>>>>> At the same time another thread calls EventQueue.postEvent() that >>>>>>>> calls EventQueue.flushPendingEvents() -> PostEventQueue.flush() >>>>>>>> where >>>>>>>> PostEventQueue is owned >>>>>>>> and another thread is waiting to own EventQueue.pushPopLock when >>>>>>>> calling EventQueue.postEvent() -> EventQueue.postEventPrivate(). >>>>>>>> >>>>>>>> To avoid potential deadlock I moved synchronization out of >>>>>>>> postEvent()'s cycle in PostEventQueue.flush(), >>>>>>>> but to be clear about the existence of Events that are not >>>>>>>> posted to >>>>>>>> EventQueue yet I added PostEventQueue.isPending flag that is true >>>>>>>> until the end of the cycle. >>>>>>>> >>>>>>>> There are only two classes that utilize PostEventQueue.flush() >>>>>>>> method: SunToolkit.flushPendingEvents() and >>>>>>>> SunToolkitSubclass.flushPendingEvents(). >>>>>>>> They are both synchronized by static SunToolkit.flushLock. That >>>>>>>> eliminates the situation when we have overlapped calls of >>>>>>>> PostEventQueue.flush(). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Oleg >>>>>> >> From anthony.petrov at oracle.com Fri Jul 13 05:58:28 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 13 Jul 2012 16:58:28 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <4FFF40F5.7090508@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> <4FFF40F5.7090508@oracle.com> Message-ID: <50001B74.5070105@oracle.com> I dug into the code history a little. The following Mike's changeset is "to blame" for using HToolkit in headless mode on the Mac: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf I've looked through the LWCToolkit.m which implements native methods specific to the real, headful Mac toolkit, and actually all of the code seems to be related to headful behavior only. Note that in the headless mode the awt_LoadLibrary.c will still load the correct lwawt dynamic native library, so all the necessary steps to initialize the app from Mac OS X perspective will be performed anyway, and all the native methods required by CFontManager and other C* classes will be available also. So basically I don't really see a problem with using the HToolkit class for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will wrap the real toolkit instance into a HeadlessToolkit class anyway, so code that relies on instanceof checks against a toolkit instance should not be affected by this choice in any way. David, do you see any specific issues with using HToolkit on a desktop (Mac) system? -- best regards, Anthony On 7/13/2012 1:26 AM, David Holmes wrote: > On 12/07/2012 10:33 PM, Anthony Petrov wrote: >> The logic is all in src/solaris/native/java/lang/java_props_macosx.c. >> The getPreferredToolkit() returns the HToolkit constant when the >> headless mode is needed on the Mac. And the GetJavaProperties() will >> then choose the sun.awt.HToolkit as the toolkit. Interesting. > > Interesting indeed. But my concerns remain. HToolkit was not intended > for general use. OSX seems to be handling headless mode in a completely > different way to Solaris/linux. > > Of course it may be that on OSX you run into the same conditions when > headless that required the introduction of HToolkit. But somebody should > have made a very conscious decision to do that. > >> But it all seems to work fine in headless mode on the Mac, right? > > You mean apart from this bug? ;-) I see a few bugs involving headless on > OSX. > > Cheers, > David > >> Leonid, did you run headless regression tests with your fix, btw? >> >> -- >> best regards, >> Anthony >> >> On 07/12/12 12:58, Leonid Romanov wrote: >>> Perhaps Anthony might be able to answer your question: he has tinkered >>> a lot with headless related stuff. >>> David, are you implying that in the current form my fix is no-go? >>> >>> On 12.07.2012, at 5:15, David Holmes wrote: >>> >>>> On 11/07/2012 11:46 PM, Leonid Romanov wrote: >>>>> Hi, >>>>> Please review a fix for 7181027: [macosx] Unable to use headless >>>>> mode. The problem here is that for headless mode >>>>> "java.awt.graphicsenv" system property should be >>>>> CGraphicsEnvironment because the way GraphicsEnvironment.createGE() >>>>> method works: it first instantiates GraphicsEnvironment instance and >>>>> then wraps it with HeadlessGraphicsEnvironment if in headless mode. >>>>> This means twe can't use java.awt.graphicsenv property to determine >>>>> whether we are in headless mode or not. So, I've replaced it with a >>>>> toolkit check: if it's HToolkit, then we are in headless. >>>> >>>> sun.awt.HToolkit was introduced for use by SE-Embedded's reduced >>>> headless JRE. How did the OSX port end up using it ??? >>>> >>>> Headless handling on OSX should be like regular headless on Linux, >>>> Solaris. >>>> >>>> David >>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>>>> >>>>> Thanks, >>>>> Leonid. >>>>> >>> From david.holmes at oracle.com Fri Jul 13 06:09:59 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Jul 2012 23:09:59 +1000 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <50001B74.5070105@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> <4FFF40F5.7090508@oracle.com> <50001B74.5070105@oracle.com> Message-ID: <50001E27.2090601@oracle.com> On 13/07/2012 10:58 PM, Anthony Petrov wrote: > I dug into the code history a little. The following Mike's changeset is > "to blame" for using HToolkit in headless mode on the Mac: > > http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf > > I've looked through the LWCToolkit.m which implements native methods > specific to the real, headful Mac toolkit, and actually all of the code > seems to be related to headful behavior only. > > Note that in the headless mode the awt_LoadLibrary.c will still load the > correct lwawt dynamic native library, so all the necessary steps to > initialize the app from Mac OS X perspective will be performed anyway, > and all the native methods required by CFontManager and other C* classes > will be available also. > > So basically I don't really see a problem with using the HToolkit class > for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will > wrap the real toolkit instance into a HeadlessToolkit class anyway, so > code that relies on instanceof checks against a toolkit instance should > not be affected by this choice in any way. > > David, do you see any specific issues with using HToolkit on a desktop > (Mac) system? No. I'm just wary of it. I'm curious what would have been done if this HToolkit class had not existed? David ----- > -- > best regards, > Anthony > > On 7/13/2012 1:26 AM, David Holmes wrote: >> On 12/07/2012 10:33 PM, Anthony Petrov wrote: >>> The logic is all in src/solaris/native/java/lang/java_props_macosx.c. >>> The getPreferredToolkit() returns the HToolkit constant when the >>> headless mode is needed on the Mac. And the GetJavaProperties() will >>> then choose the sun.awt.HToolkit as the toolkit. Interesting. >> >> Interesting indeed. But my concerns remain. HToolkit was not intended >> for general use. OSX seems to be handling headless mode in a >> completely different way to Solaris/linux. >> >> Of course it may be that on OSX you run into the same conditions when >> headless that required the introduction of HToolkit. But somebody >> should have made a very conscious decision to do that. >> >>> But it all seems to work fine in headless mode on the Mac, right? >> >> You mean apart from this bug? ;-) I see a few bugs involving headless >> on OSX. >> >> Cheers, >> David >> >>> Leonid, did you run headless regression tests with your fix, btw? >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 07/12/12 12:58, Leonid Romanov wrote: >>>> Perhaps Anthony might be able to answer your question: he has tinkered >>>> a lot with headless related stuff. >>>> David, are you implying that in the current form my fix is no-go? >>>> >>>> On 12.07.2012, at 5:15, David Holmes wrote: >>>> >>>>> On 11/07/2012 11:46 PM, Leonid Romanov wrote: >>>>>> Hi, >>>>>> Please review a fix for 7181027: [macosx] Unable to use headless >>>>>> mode. The problem here is that for headless mode >>>>>> "java.awt.graphicsenv" system property should be >>>>>> CGraphicsEnvironment because the way GraphicsEnvironment.createGE() >>>>>> method works: it first instantiates GraphicsEnvironment instance and >>>>>> then wraps it with HeadlessGraphicsEnvironment if in headless mode. >>>>>> This means twe can't use java.awt.graphicsenv property to determine >>>>>> whether we are in headless mode or not. So, I've replaced it with a >>>>>> toolkit check: if it's HToolkit, then we are in headless. >>>>> >>>>> sun.awt.HToolkit was introduced for use by SE-Embedded's reduced >>>>> headless JRE. How did the OSX port end up using it ??? >>>>> >>>>> Headless handling on OSX should be like regular headless on Linux, >>>>> Solaris. >>>>> >>>>> David >>>>> >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Leonid. >>>>>> >>>> From anthony.petrov at oracle.com Fri Jul 13 06:22:34 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 13 Jul 2012 17:22:34 +0400 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <50001E27.2090601@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> <4FFF40F5.7090508@oracle.com> <50001B74.5070105@oracle.com> <50001E27.2090601@oracle.com> Message-ID: <5000211A.7010903@oracle.com> On 7/13/2012 5:09 PM, David Holmes wrote: > On 13/07/2012 10:58 PM, Anthony Petrov wrote: >> I dug into the code history a little. The following Mike's changeset is >> "to blame" for using HToolkit in headless mode on the Mac: >> >> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf >> >> I've looked through the LWCToolkit.m which implements native methods >> specific to the real, headful Mac toolkit, and actually all of the code >> seems to be related to headful behavior only. >> >> Note that in the headless mode the awt_LoadLibrary.c will still load the >> correct lwawt dynamic native library, so all the necessary steps to >> initialize the app from Mac OS X perspective will be performed anyway, >> and all the native methods required by CFontManager and other C* classes >> will be available also. >> >> So basically I don't really see a problem with using the HToolkit class >> for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will >> wrap the real toolkit instance into a HeadlessToolkit class anyway, so >> code that relies on instanceof checks against a toolkit instance should >> not be affected by this choice in any way. >> >> David, do you see any specific issues with using HToolkit on a desktop >> (Mac) system? > > No. I'm just wary of it. I'm curious what would have been done if this > HToolkit class had not existed? Either it would have been introduced, or the LWCToolkit/LWToolkit classes would have been made "more headless-aware," so to speak. I think Mike could shed some light on his decision. Anyway, to conclude the reviewing thread, given that we don't (currently) see any problems with using HToolkit on the Mac, and the fact that it's already been used in headless mode on the Mac for a while, I'm fine with the fix proposed by Leonid. -- best regards, Anthony > > David > ----- > >> -- >> best regards, >> Anthony >> >> On 7/13/2012 1:26 AM, David Holmes wrote: >>> On 12/07/2012 10:33 PM, Anthony Petrov wrote: >>>> The logic is all in src/solaris/native/java/lang/java_props_macosx.c. >>>> The getPreferredToolkit() returns the HToolkit constant when the >>>> headless mode is needed on the Mac. And the GetJavaProperties() will >>>> then choose the sun.awt.HToolkit as the toolkit. Interesting. >>> >>> Interesting indeed. But my concerns remain. HToolkit was not intended >>> for general use. OSX seems to be handling headless mode in a >>> completely different way to Solaris/linux. >>> >>> Of course it may be that on OSX you run into the same conditions when >>> headless that required the introduction of HToolkit. But somebody >>> should have made a very conscious decision to do that. >>> >>>> But it all seems to work fine in headless mode on the Mac, right? >>> >>> You mean apart from this bug? ;-) I see a few bugs involving headless >>> on OSX. >>> >>> Cheers, >>> David >>> >>>> Leonid, did you run headless regression tests with your fix, btw? >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 07/12/12 12:58, Leonid Romanov wrote: >>>>> Perhaps Anthony might be able to answer your question: he has tinkered >>>>> a lot with headless related stuff. >>>>> David, are you implying that in the current form my fix is no-go? >>>>> >>>>> On 12.07.2012, at 5:15, David Holmes wrote: >>>>> >>>>>> On 11/07/2012 11:46 PM, Leonid Romanov wrote: >>>>>>> Hi, >>>>>>> Please review a fix for 7181027: [macosx] Unable to use headless >>>>>>> mode. The problem here is that for headless mode >>>>>>> "java.awt.graphicsenv" system property should be >>>>>>> CGraphicsEnvironment because the way GraphicsEnvironment.createGE() >>>>>>> method works: it first instantiates GraphicsEnvironment instance and >>>>>>> then wraps it with HeadlessGraphicsEnvironment if in headless mode. >>>>>>> This means twe can't use java.awt.graphicsenv property to determine >>>>>>> whether we are in headless mode or not. So, I've replaced it with a >>>>>>> toolkit check: if it's HToolkit, then we are in headless. >>>>>> >>>>>> sun.awt.HToolkit was introduced for use by SE-Embedded's reduced >>>>>> headless JRE. How did the OSX port end up using it ??? >>>>>> >>>>>> Headless handling on OSX should be like regular headless on Linux, >>>>>> Solaris. >>>>>> >>>>>> David >>>>>> >>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181027 >>>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7181027/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Leonid. >>>>>>> >>>>> From oleg.pekhovskiy at oracle.com Fri Jul 13 06:47:00 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 13 Jul 2012 17:47:00 +0400 Subject: [8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater Message-ID: <500026D4.5050803@oracle.com> Hi guys, please review that 100%-forward-port from 7u6: http://cr.openjdk.java.net/~bagiras/8/7177040.1 Thanks, Oleg From anthony.petrov at oracle.com Fri Jul 13 06:54:33 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 13 Jul 2012 17:54:33 +0400 Subject: [8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <500026D4.5050803@oracle.com> References: <500026D4.5050803@oracle.com> Message-ID: <50002899.5050804@oracle.com> Looks fine. -- best regards, Anthony On 7/13/2012 5:47 PM, Oleg Pekhovskiy wrote: > Hi guys, > > please review that 100%-forward-port from 7u6: > http://cr.openjdk.java.net/~bagiras/8/7177040.1 > > Thanks, > Oleg From swingler at apple.com Fri Jul 13 07:23:15 2012 From: swingler at apple.com (Mike Swingler) Date: Fri, 13 Jul 2012 07:23:15 -0700 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <5000211A.7010903@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> <4FFF40F5.7090508@oracle.com> <50001B74.5070105@oracle.com> <50001E27.2090601@oracle.com> <5000211A.7010903@oracle.com> Message-ID: <6228EDFA-1B87-4758-A11C-9E45A9B0C272@apple.com> On Jul 13, 2012, at 6:22 AM, Anthony Petrov wrote: > On 7/13/2012 5:09 PM, David Holmes wrote: > >> On 13/07/2012 10:58 PM, Anthony Petrov wrote: >> >>> I dug into the code history a little. The following Mike's changeset is >>> "to blame" for using HToolkit in headless mode on the Mac: >>> >>> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf >>> >>> I've looked through the LWCToolkit.m which implements native methods >>> specific to the real, headful Mac toolkit, and actually all of the code >>> seems to be related to headful behavior only. >>> >>> Note that in the headless mode the awt_LoadLibrary.c will still load the >>> correct lwawt dynamic native library, so all the necessary steps to >>> initialize the app from Mac OS X perspective will be performed anyway, >>> and all the native methods required by CFontManager and other C* classes >>> will be available also. >>> >>> So basically I don't really see a problem with using the HToolkit class >>> for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will >>> wrap the real toolkit instance into a HeadlessToolkit class anyway, so >>> code that relies on instanceof checks against a toolkit instance should >>> not be affected by this choice in any way. >>> >>> David, do you see any specific issues with using HToolkit on a desktop >>> (Mac) system? >> >> No. I'm just wary of it. I'm curious what would have been done if this HToolkit class had not existed? > > Either it would have been introduced, or the LWCToolkit/LWToolkit classes would have been made "more headless-aware," so to speak. I think Mike could shed some light on his decision. I was looking for a way to ensure that once the choice to be headless was made, there would be no way to undo it. We've had problems in Java SE 6 and prior where the old CToolkit was "mostly headless", but could still try to make contact to the window server for somethings (edge cases in fonts, IIRC). This would "mostly work" for a while under an SSH session, but would die some hours later after Mach bootstrap session expired, and lead to diagnosing some fairly frustrating bugs. With HToolkit, the boot comes down immediately about what you can and cannot do - and the implementation looked simple enough, I didn't see much risk. It was there, it worked, I went with it. > Anyway, to conclude the reviewing thread, given that we don't (currently) see any problems with using HToolkit on the Mac, and the fact that it's already been used in headless mode on the Mac for a while, I'm fine with the fix proposed by Leonid. I personally don't see why HToolkit couldn't be used unilaterally for headless mode on all platforms. Wouldn't any breakage show an improper layering violation that should not have been allowed to occur in the first place? Regards, Mike Swingler Apple Inc. From oleg.pekhovskiy at oracle.com Fri Jul 13 07:32:06 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 13 Jul 2012 18:32:06 +0400 Subject: [8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <50002899.5050804@oracle.com> References: <500026D4.5050803@oracle.com> <50002899.5050804@oracle.com> Message-ID: <50003166.4040609@oracle.com> Thanks for the review, Anthony! Oleg. 13.07.2012 17:54, Anthony Petrov wrote: > Looks fine. > > -- > best regards, > Anthony > > On 7/13/2012 5:47 PM, Oleg Pekhovskiy wrote: >> Hi guys, >> >> please review that 100%-forward-port from 7u6: >> http://cr.openjdk.java.net/~bagiras/8/7177040.1 >> >> Thanks, >> Oleg From david.holmes at oracle.com Fri Jul 13 17:40:46 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 14 Jul 2012 10:40:46 +1000 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <6228EDFA-1B87-4758-A11C-9E45A9B0C272@apple.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> <4FFF40F5.7090508@oracle.com> <50001B74.5070105@oracle.com> <50001E27.2090601@oracle.com> <5000211A.7010903@oracle.com> <6228EDFA-1B87-4758-A11C-9E45A9B0C272@apple.com> Message-ID: <5000C00E.3030209@oracle.com> On 14/07/2012 12:23 AM, Mike Swingler wrote: > On Jul 13, 2012, at 6:22 AM, Anthony Petrov wrote: >> On 7/13/2012 5:09 PM, David Holmes wrote: >>> On 13/07/2012 10:58 PM, Anthony Petrov wrote: >>> >>>> I dug into the code history a little. The following Mike's changeset is >>>> "to blame" for using HToolkit in headless mode on the Mac: >>>> >>>> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf >>>> >>>> I've looked through the LWCToolkit.m which implements native methods >>>> specific to the real, headful Mac toolkit, and actually all of the code >>>> seems to be related to headful behavior only. >>>> >>>> Note that in the headless mode the awt_LoadLibrary.c will still load the >>>> correct lwawt dynamic native library, so all the necessary steps to >>>> initialize the app from Mac OS X perspective will be performed anyway, >>>> and all the native methods required by CFontManager and other C* classes >>>> will be available also. >>>> >>>> So basically I don't really see a problem with using the HToolkit class >>>> for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will >>>> wrap the real toolkit instance into a HeadlessToolkit class anyway, so >>>> code that relies on instanceof checks against a toolkit instance should >>>> not be affected by this choice in any way. >>>> >>>> David, do you see any specific issues with using HToolkit on a desktop >>>> (Mac) system? >>> >>> No. I'm just wary of it. I'm curious what would have been done if this HToolkit class had not existed? >> >> Either it would have been introduced, or the LWCToolkit/LWToolkit classes would have been made "more headless-aware," so to speak. I think Mike could shed some light on his decision. > > I was looking for a way to ensure that once the choice to be headless was made, there would be no way to undo it. We've had problems in Java SE 6 and prior where the old CToolkit was "mostly headless", but could still try to make contact to the window server for somethings (edge cases in fonts, IIRC). This would "mostly work" for a while under an SSH session, but would die some hours later after Mach bootstrap session expired, and lead to diagnosing some fairly frustrating bugs. > > With HToolkit, the boot comes down immediately about what you can and cannot do - and the implementation looked simple enough, I didn't see much risk. It was there, it worked, I went with it. > >> Anyway, to conclude the reviewing thread, given that we don't (currently) see any problems with using HToolkit on the Mac, and the fact that it's already been used in headless mode on the Mac for a while, I'm fine with the fix proposed by Leonid. > > I personally don't see why HToolkit couldn't be used unilaterally for headless mode on all platforms. Wouldn't any breakage show an improper layering violation that should not have been allowed to occur in the first place? It was introduced for platforms with absolutely zero "graphics" related capabilities - not even libraries installed let alone hardware. The pre-existing "headless" toolkits still required some of this support for, as I recall, printing/font related things - which must still be supported even in headless mode. As long as this is passing the full set of TCK/JCK tests then it is usable. David ----- > Regards, > Mike Swingler > Apple Inc. > From swingler at apple.com Sat Jul 14 06:52:28 2012 From: swingler at apple.com (Mike Swingler) Date: Sat, 14 Jul 2012 06:52:28 -0700 Subject: [7u6] Review request for 7181027: [macosx] Unable to use headless mode In-Reply-To: <5000C00E.3030209@oracle.com> References: <5AC786A0-CB1E-4DB2-877C-61FC33A940F8@oracle.com> <4FFE2533.7020302@oracle.com> <72486124-CA37-4D77-A40F-5ED5AD8E5DB1@oracle.com> <4FFEC412.2060200@oracle.com> <4FFF40F5.7090508@oracle.com> <50001B74.5070105@oracle.com> <50001E27.2090601@oracle.com> <5000211A.7010903@oracle.com> <6228EDFA-1B87-4758-A11C-9E45A9B0C272@apple.com> <5000C00E.3030209@oracle.com> Message-ID: <54F9A10C-BFAE-4429-B7A0-035CDA1AF327@apple.com> On Jul 13, 2012, at 5:40 PM, David Holmes wrote: > On 14/07/2012 12:23 AM, Mike Swingler wrote: >> On Jul 13, 2012, at 6:22 AM, Anthony Petrov wrote: >>> On 7/13/2012 5:09 PM, David Holmes wrote: >>>> On 13/07/2012 10:58 PM, Anthony Petrov wrote: >>>> >>>>> I dug into the code history a little. The following Mike's changeset is >>>>> "to blame" for using HToolkit in headless mode on the Mac: >>>>> >>>>> http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/67591b2326bf >>>>> >>>>> I've looked through the LWCToolkit.m which implements native methods >>>>> specific to the real, headful Mac toolkit, and actually all of the code >>>>> seems to be related to headful behavior only. >>>>> >>>>> Note that in the headless mode the awt_LoadLibrary.c will still load the >>>>> correct lwawt dynamic native library, so all the necessary steps to >>>>> initialize the app from Mac OS X perspective will be performed anyway, >>>>> and all the native methods required by CFontManager and other C* classes >>>>> will be available also. >>>>> >>>>> So basically I don't really see a problem with using the HToolkit class >>>>> for headless mode on the Mac. Note that Toolkit.getDefaultToolkit() will >>>>> wrap the real toolkit instance into a HeadlessToolkit class anyway, so >>>>> code that relies on instanceof checks against a toolkit instance should >>>>> not be affected by this choice in any way. >>>>> >>>>> David, do you see any specific issues with using HToolkit on a desktop >>>>> (Mac) system? >>>> >>>> No. I'm just wary of it. I'm curious what would have been done if this HToolkit class had not existed? >>> >>> Either it would have been introduced, or the LWCToolkit/LWToolkit classes would have been made "more headless-aware," so to speak. I think Mike could shed some light on his decision. >> >> I was looking for a way to ensure that once the choice to be headless was made, there would be no way to undo it. We've had problems in Java SE 6 and prior where the old CToolkit was "mostly headless", but could still try to make contact to the window server for somethings (edge cases in fonts, IIRC). This would "mostly work" for a while under an SSH session, but would die some hours later after Mach bootstrap session expired, and lead to diagnosing some fairly frustrating bugs. >> >> With HToolkit, the boot comes down immediately about what you can and cannot do - and the implementation looked simple enough, I didn't see much risk. It was there, it worked, I went with it. >> >>> Anyway, to conclude the reviewing thread, given that we don't (currently) see any problems with using HToolkit on the Mac, and the fact that it's already been used in headless mode on the Mac for a while, I'm fine with the fix proposed by Leonid. >> >> I personally don't see why HToolkit couldn't be used unilaterally for headless mode on all platforms. Wouldn't any breakage show an improper layering violation that should not have been allowed to occur in the first place? > > It was introduced for platforms with absolutely zero "graphics" related capabilities - not even libraries installed let alone hardware. The pre-existing "headless" toolkits still required some of this support for, as I recall, printing/font related things - which must still be supported even in headless mode. As long as this is passing the full set of TCK/JCK tests then it is usable. In OS X, it is unsafe to communicate with any Cocoa code in a headless/server environment, so this is actually a good match for our usage. Any font usage or printing done in this mode would have to fall back to only font files and CUPS sockets, and not rely on the CoreText/CoreGraphics API. Trying to add font or printing in a server context might be a reason to sub-class or extend HToolkit - but I imagine some of that implementation would be common with the XToolkit, and that would be an interesting design discussion how to tease all that apart and recombine it in a modular way that would allow CToolkit to delegate to it without introducing a dependency on X11. Regards, Mike Swingler Apple Inc. From anton.tarasov at oracle.com Mon Jul 16 00:47:10 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 16 Jul 2012 11:47:10 +0400 Subject: [8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <500026D4.5050803@oracle.com> References: <500026D4.5050803@oracle.com> Message-ID: <5003C6FE.80805@oracle.com> Looks fine for me. Thanks, Anton. On 13.07.2012 17:47, Oleg Pekhovskiy wrote: > Hi guys, > > please review that 100%-forward-port from 7u6: > http://cr.openjdk.java.net/~bagiras/8/7177040.1 > > Thanks, > Oleg From pavel.porvatov at oracle.com Mon Jul 16 02:42:36 2012 From: pavel.porvatov at oracle.com (Pavel Porvatov) Date: Mon, 16 Jul 2012 13:42:36 +0400 Subject: [8] Review request for 7170657: [macosx] There seems to be no keyboard/mouse action to select non-contiguous items in List In-Reply-To: <4FFF00BD.8030804@oracle.com> References: <4FFEED0C.2010709@oracle.com> <4FFEFAAB.2040109@oracle.com> <4FFF00BD.8030804@oracle.com> Message-ID: <5003E20C.9010705@oracle.com> Hi Sergey, Looks good for me. Regards, Pavel > Hi, Pavel. > Thanks for review. See comments inline > 12.07.2012 20:26, Pavel Porvatov wrote: >> Hi Sergey, >> >> The fix looks good. Could you please remove unnecessary code from the >> test like: >> >> 1. @run main/othervm bug7170657 > done >> 2. The "FAILED" field: you can throw exception from the "fail" method > In this case we skip part of the test. Useful for debug. >> 3. What is the reason to use final here: "public final class"? > I do not think that someone will want to be inherited from it. I just > make all classes final by default. > > New version of the fix: > http://cr.openjdk.java.net/~serb/7170657/webrev.01/ >> >> Regards, Pavel >>> Hi Everyone, >>> Please review the fix. >>> Bug in SwingUtilities.convertMouseEvent().This method does not >>> convert extended state of the event. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7170657 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7170657/webrev.00 >>> >> > > From sergey.bylokhov at oracle.com Mon Jul 16 04:03:55 2012 From: sergey.bylokhov at oracle.com (sergey.bylokhov at oracle.com) Date: Mon, 16 Jul 2012 11:03:55 +0000 Subject: hg: jdk8/awt/jdk: 2 new changesets Message-ID: <20120716110445.6A5BC47082@hg.openjdk.java.net> Changeset: 4624486823a7 Author: serb Date: 2012-07-16 14:00 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4624486823a7 7181438: [OGL] Incorrect alpha used, during blit from SW to the texture. Reviewed-by: prr, campbell ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c + test/sun/java2d/OpenGL/bug7181438.java Changeset: c277657e5e10 Author: serb Date: 2012-07-16 14:04 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c277657e5e10 7170657: [macosx] There seems to be no keyboard/mouse action to select non-contiguous items in List Reviewed-by: rupashka ! src/share/classes/javax/swing/SwingUtilities.java + test/javax/swing/SwingUtilities/7170657/bug7170657.java From lana.steuck at oracle.com Mon Jul 16 15:43:40 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 16 Jul 2012 22:43:40 +0000 Subject: hg: jdk8/awt: 6 new changesets Message-ID: <20120716224341.DF621470A6@hg.openjdk.java.net> Changeset: 27fa766a2298 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/27fa766a2298 Added tag jdk8-b45 for changeset 633f2378c904 ! .hgtags Changeset: f6a685069274 Author: katleman Date: 2012-07-05 18:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/f6a685069274 Added tag jdk8-b46 for changeset 27fa766a2298 ! .hgtags Changeset: c8d320b48626 Author: erikj Date: 2012-07-03 16:11 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/c8d320b48626 7181504: Update of latest build-infra Makefiles Reviewed-by: ohair ! common/autoconf/autogen.sh ! common/autoconf/build-aux/config.guess ! common/autoconf/builddeps.conf.example ! common/autoconf/builddeps.m4 ! common/autoconf/configure ! common/autoconf/configure.ac - common/autoconf/cores.m4 ! common/autoconf/help.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/bin/compareimage.sh ! common/bin/diffexec.sh ! common/bin/diffjarzip.sh ! common/bin/difflib.sh ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk - common/makefiles/RMICompile.gmk Changeset: 3156dff953b1 Author: erikj Date: 2012-07-05 18:27 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/3156dff953b1 7182051: Update of latest build-infra Makefiles (missing files) Reviewed-by: ohair + common/autoconf/basics.m4 + common/autoconf/boot-jdk.m4 + common/autoconf/build-aux/autoconf-config.guess + common/autoconf/build-performance.m4 + common/autoconf/generated-configure.sh + common/autoconf/jdk-options.m4 + common/autoconf/libraries.m4 + common/autoconf/source-dirs.m4 + common/autoconf/spec.sh.in + common/autoconf/toolchain.m4 + common/bin/compare-objects.sh ! common/makefiles/IdlCompilation.gmk + common/makefiles/MakeHelpers.gmk ! common/makefiles/NativeCompilation.gmk + common/makefiles/RMICompilation.gmk Changeset: 1dcb4b7b9373 Author: katleman Date: 2012-07-11 16:00 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/1dcb4b7b9373 Merge - common/autoconf/cores.m4 - common/makefiles/RMICompile.gmk Changeset: aaae5471808d Author: katleman Date: 2012-07-12 16:47 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/aaae5471808d Added tag jdk8-b47 for changeset 1dcb4b7b9373 ! .hgtags From lana.steuck at oracle.com Mon Jul 16 15:43:40 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 16 Jul 2012 22:43:40 +0000 Subject: hg: jdk8/awt/corba: 6 new changesets Message-ID: <20120716224350.99C97470A7@hg.openjdk.java.net> Changeset: 30141e598d72 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/30141e598d72 Added tag jdk8-b45 for changeset 747dad9e9d37 ! .hgtags Changeset: cb31b67326bc Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/cb31b67326bc Added tag jdk8-b46 for changeset 30141e598d72 ! .hgtags Changeset: 47adb42076f1 Author: coffeys Date: 2012-06-27 21:09 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/47adb42076f1 7162902: Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8 Reviewed-by: lancea ! src/share/classes/com/sun/corba/se/impl/encoding/CachedCodeBase.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PIHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PINoOpHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/monitoring/MonitoringManagerFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/monitoring/MonitoringManagerImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolManagerImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/WorkQueueImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaMessageMediatorImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java ! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc ! src/share/classes/com/sun/corba/se/spi/monitoring/MonitoringManager.java ! src/share/classes/com/sun/corba/se/spi/monitoring/MonitoringManagerFactory.java ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java ! src/share/classes/com/sun/corba/se/spi/orbutil/threadpool/ThreadPool.java ! src/share/classes/com/sun/corba/se/spi/orbutil/threadpool/ThreadPoolManager.java ! src/share/classes/com/sun/corba/se/spi/protocol/PIHandler.java ! src/share/classes/com/sun/corba/se/spi/protocol/RequestDispatcherRegistry.java Changeset: 666efea2df67 Author: lana Date: 2012-07-03 18:23 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/666efea2df67 Merge Changeset: 21e46ea21c6a Author: lana Date: 2012-07-10 11:40 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/21e46ea21c6a Merge Changeset: 7e2b179a5b4d Author: katleman Date: 2012-07-12 16:47 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/7e2b179a5b4d Added tag jdk8-b47 for changeset 21e46ea21c6a ! .hgtags From lana.steuck at oracle.com Mon Jul 16 15:43:43 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 16 Jul 2012 22:43:43 +0000 Subject: hg: jdk8/awt/jaxws: 3 new changesets Message-ID: <20120716224355.EA7FD470A8@hg.openjdk.java.net> Changeset: ae368a83c240 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/ae368a83c240 Added tag jdk8-b45 for changeset e80ac58b5ba9 ! .hgtags Changeset: fe6a060afc40 Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/fe6a060afc40 Added tag jdk8-b46 for changeset ae368a83c240 ! .hgtags Changeset: efb564de8a8e Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/efb564de8a8e Added tag jdk8-b47 for changeset fe6a060afc40 ! .hgtags From lana.steuck at oracle.com Mon Jul 16 15:43:52 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 16 Jul 2012 22:43:52 +0000 Subject: hg: jdk8/awt/langtools: 5 new changesets Message-ID: <20120716224405.91DF5470A9@hg.openjdk.java.net> Changeset: 4ca599497172 Author: katleman Date: 2012-06-28 09:33 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/4ca599497172 Added tag jdk8-b45 for changeset e111e4587cca ! .hgtags Changeset: c7e62fc9df92 Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/c7e62fc9df92 Added tag jdk8-b46 for changeset 4ca599497172 ! .hgtags Changeset: 01d9911df25d Author: erikj Date: 2012-06-28 14:59 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/01d9911df25d 7180594: Fix GenStubs in langtools for build-infra builds Reviewed-by: ohair ! make/tools/genstubs/GenStubs.java Changeset: 7e6be2f239c9 Author: ohair Date: 2012-07-08 20:34 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/7e6be2f239c9 Merge Changeset: afb0a5231557 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/afb0a5231557 Added tag jdk8-b47 for changeset 7e6be2f239c9 ! .hgtags From lana.steuck at oracle.com Mon Jul 16 15:43:46 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 16 Jul 2012 22:43:46 +0000 Subject: hg: jdk8/awt/jaxp: 7 new changesets Message-ID: <20120716224409.48307470AA@hg.openjdk.java.net> Changeset: 300f45e99064 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/300f45e99064 Added tag jdk8-b45 for changeset 57476f66e13c ! .hgtags Changeset: bf27b857c6ee Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/bf27b857c6ee Added tag jdk8-b46 for changeset 300f45e99064 ! .hgtags Changeset: 7920ead2cc75 Author: joehw Date: 2012-06-26 15:28 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/7920ead2cc75 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException Summary: skip the added international character handling for general paths Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java Changeset: 219e720a1baa Author: lana Date: 2012-06-26 22:47 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/219e720a1baa Merge Changeset: 9cb8be5e6119 Author: lana Date: 2012-07-03 18:24 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/9cb8be5e6119 Merge Changeset: 404521944ac9 Author: lana Date: 2012-07-10 11:40 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/404521944ac9 Merge Changeset: 1c88da9a1365 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/1c88da9a1365 Added tag jdk8-b47 for changeset 404521944ac9 ! .hgtags From lana.steuck at oracle.com Mon Jul 16 15:43:52 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 16 Jul 2012 22:43:52 +0000 Subject: hg: jdk8/awt/hotspot: 35 new changesets Message-ID: <20120716224517.7D5CF470AB@hg.openjdk.java.net> Changeset: a8b9798c1d45 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/a8b9798c1d45 Added tag jdk8-b45 for changeset 9d5f20961bc5 ! .hgtags Changeset: 1c280e5b8d31 Author: amurillo Date: 2012-06-15 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/1c280e5b8d31 7175515: new hotspot build - hs24-b15 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e9140bf80b4a Author: coleenp Date: 2012-06-13 19:52 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e9140bf80b4a 7158800: Improve storage of symbol tables Summary: Use an alternate version of hashing algorithm for symbol string tables and after a certain bucket size to improve performance Reviewed-by: pbk, kamg, dlong, kvn, fparain + src/share/vm/classfile/altHashing.cpp + src/share/vm/classfile/altHashing.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp + test/runtime/7158800/BadUtf8.java + test/runtime/7158800/InternTest.java + test/runtime/7158800/badstrings.txt Changeset: b87e5a681416 Author: poonam Date: 2012-06-14 02:12 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/b87e5a681416 6310967: SA: jstack -m produce failures in output Summary: While looking for the sender frame check that the frame pointer should not be less than the stack pointer. Reviewed-by: dholmes, sla ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/sparc/LinuxSPARCCFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcCFrame.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java Changeset: e16bc4ad5f20 Author: poonam Date: 2012-06-14 22:55 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e16bc4ad5f20 Merge Changeset: 86e17e45019d Author: coleenp Date: 2012-06-15 07:51 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/86e17e45019d 7177307: fix fo CR7158800 doesn't contain Test7158800.sh Summary: forgot to hg add it Reviewed-by: pbk, kamg, dlong, kvn, fparain + test/runtime/7158800/Test7158800.sh Changeset: 58ad5f22317e Author: sla Date: 2012-06-18 11:33 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/58ad5f22317e Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/runtime/globals.hpp Changeset: d1b0644d6acf Author: dcubed Date: 2012-06-20 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d1b0644d6acf 7175255: symlinks are wrong, which caused jdk8-promote-2 to fail (client/64/64 directories in debuginfo zips) Summary: Fix bad paths in client/64 and server/64 debug info and symlink creation Reviewed-by: ohair, dholmes ! make/solaris/makefiles/add_gnu_debuglink.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/fix_empty_sec_hdr_flags.make Changeset: 7de1d3b57419 Author: dcubed Date: 2012-06-20 14:29 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7de1d3b57419 Merge ! make/solaris/makefiles/defs.make Changeset: cfa2c82f4c04 Author: minqi Date: 2012-06-22 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/cfa2c82f4c04 7175133: jinfo failed to get system properties after 6924259 Summary: String offset and count fields as fix of 6924259 were removed, and become optional. SA still use offset and count fields to read String contents and failed. Fix if they exist, use them other then use value field only to read, this keeps consistent with the changes in 6924259. Reviewed-by: dholmes, mikael Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java Changeset: d8a240abb23a Author: minqi Date: 2012-06-22 15:39 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d8a240abb23a 7177128: SA cannot get correct system properties after 7126277 Summary: Bug fix of 7126277 changed hashing algorithm and also changed key as final field, this led SA unable to set correct value for key. Solution by reading key/value and insert them into the new table. Reviewed-by: dholmes, mikael Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/ObjectReader.java Changeset: 588f559105c1 Author: sla Date: 2012-06-25 14:34 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/588f559105c1 7178846: IterateThroughHeap: heap_iteration_callback passes a negative size Summary: Missing cast caused integer overflow Reviewed-by: rbackman, dholmes ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 246d977b51f2 Author: coleenp Date: 2012-06-25 21:33 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/246d977b51f2 7178670: runtime/7158800/BadUtf8.java fails in SymbolTable::rehash_table Summary: Cannot delete _buckets and HashtableEntries in shared space (CDS) Reviewed-by: acorn, kvn, dlong, dcubed, kamg ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 36b2d4cfcf03 Author: coleenp Date: 2012-06-25 18:59 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/36b2d4cfcf03 Merge Changeset: 74533f63b116 Author: sla Date: 2012-06-27 15:23 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/74533f63b116 7178667: ALT_EXPORT_PATH does not export server jvm on macosx Summary: Missing .PHONY targets in makefile Reviewed-by: dholmes, dsamersoff ! make/bsd/makefiles/universal.gmk Changeset: f7baf26515fc Author: collins Date: 2012-06-19 21:16 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f7baf26515fc 7178113: build environment change Summary: Simple change to enable proper builds of arm target Reviewed-by: ohair, dholmes ! make/jprt.properties Changeset: 634b8615a6ba Author: jiangli Date: 2012-06-22 14:00 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/634b8615a6ba 7177409: Perf regression in JVM_GetClassDeclaredFields after generic signature changes. Summary: In fieldDescriptor::generic_signature() returns NULL immediately if the field has no generic signature. Reviewed-by: dholmes, coleenp, jcoomes ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflection.cpp Changeset: 06320b1578cb Author: dlong Date: 2012-06-25 15:34 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/06320b1578cb 7156729: PPC: R_PPC_REL24 relocation error related to some libraries built without -fPIC Summary: build powerpc with -fPIC Reviewed-by: mikael, vladidan, roland Contributed-by: dean.long at oracle.com ! make/pic.make Changeset: 7d5f65916db0 Author: bdelsart Date: 2012-06-28 04:21 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7d5f65916db0 Merge Changeset: 8c92982cbbc4 Author: kvn Date: 2012-06-15 01:25 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/8c92982cbbc4 7119644: Increase superword's vector size up to 256 bits Summary: Increase vector size up to 256-bits for YMM AVX registers on x86. Reviewed-by: never, twisti, roland ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/register_x86.cpp ! src/cpu/x86/vm/register_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vmreg_x86.cpp ! src/cpu/x86/vm/vmreg_x86.inline.hpp ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formsopt.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/code/vmreg.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/opcodes.cpp ! src/share/vm/opto/opcodes.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/7119644/TestBooleanVect.java + test/compiler/7119644/TestByteDoubleVect.java + test/compiler/7119644/TestByteFloatVect.java + test/compiler/7119644/TestByteIntVect.java + test/compiler/7119644/TestByteLongVect.java + test/compiler/7119644/TestByteShortVect.java + test/compiler/7119644/TestByteVect.java + test/compiler/7119644/TestCharShortVect.java + test/compiler/7119644/TestCharVect.java + test/compiler/7119644/TestDoubleVect.java + test/compiler/7119644/TestFloatDoubleVect.java + test/compiler/7119644/TestFloatVect.java + test/compiler/7119644/TestIntDoubleVect.java + test/compiler/7119644/TestIntFloatVect.java + test/compiler/7119644/TestIntLongVect.java + test/compiler/7119644/TestIntVect.java + test/compiler/7119644/TestLongDoubleVect.java + test/compiler/7119644/TestLongFloatVect.java + test/compiler/7119644/TestLongVect.java + test/compiler/7119644/TestShortDoubleVect.java + test/compiler/7119644/TestShortFloatVect.java + test/compiler/7119644/TestShortIntVect.java + test/compiler/7119644/TestShortLongVect.java + test/compiler/7119644/TestShortVect.java Changeset: eeb819cf36e5 Author: roland Date: 2012-06-18 09:52 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/eeb819cf36e5 7174363: Arrays.copyOfRange leads to VM crash with -Xcomp -server if executed by testing framework Summary: Arrays.copyOfRange(original, from, to) with from > original.length tries to do a copy with a negative length. Reviewed-by: kvn, twisti ! src/share/vm/opto/library_call.cpp + test/compiler/7174363/Test7174363.java Changeset: f8de958e5b2c Author: twisti Date: 2012-06-18 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/f8de958e5b2c 7176856: add the JRE name to the error log Reviewed-by: coleenp, jrose, kvn, twisti Contributed-by: Krystal Mok ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 765ee2d1674b Author: twisti Date: 2012-06-18 15:17 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/765ee2d1674b 7157365: jruby/bench.bench_timeout crashes with JVM internal error Reviewed-by: jrose, kvn ! src/share/vm/memory/universe.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/type.cpp Changeset: 6f8f439e247d Author: kvn Date: 2012-06-19 15:12 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/6f8f439e247d 7177923: SIGBUS on sparc in compiled code for java.util.Calendar.clear() Summary: disable vectorization of a memory access with more elements per vector than one which is used for alignment on sparc Reviewed-by: twisti ! src/cpu/x86/vm/x86.ad ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp Changeset: 40782a131183 Author: roland Date: 2012-06-21 09:52 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/40782a131183 7129715: MAC: SIGBUS in nsk stress test Summary: StackOverflowError may get lost on OSX. Reviewed-by: kvn, dcubed ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: 424142833d10 Author: kvn Date: 2012-06-22 10:40 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/424142833d10 7178280: Failed new vector regression tests Summary: When looking for the same value in an other register check that all parts of that register has the same value. Reviewed-by: johnc, twisti ! src/share/vm/opto/postaloc.cpp Changeset: 751bd303aa45 Author: kvn Date: 2012-06-26 09:06 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/751bd303aa45 7179138: Incorrect result with String concatenation optimization Summary: check for and skip diamond shaped NULL check code for the result of toString() Reviewed-by: twisti, roland ! src/share/vm/opto/stringopts.cpp + test/compiler/7179138/Test7179138_1.java + test/compiler/7179138/Test7179138_2.java Changeset: de2f17add1fb Author: kvn Date: 2012-06-28 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/de2f17add1fb Merge Changeset: 7994a5a35fcf Author: johnc Date: 2012-06-25 16:00 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/7994a5a35fcf 6921087: G1: remove per-GC-thread expansion tables from the fine-grain remembered sets Summary: Remove the per-thread expansion tables (PosParPRT) and associated expansion and compaction from the fine grain RSet entries. This code has been unused for a while. Reviewed-by: johnc, brutisso Contributed-by: Thomas Schatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp Changeset: 22de825d6faf Author: jcoomes Date: 2012-06-29 11:15 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/22de825d6faf Merge Changeset: 61a94c2da7c4 Author: coleenp Date: 2012-06-29 14:28 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/61a94c2da7c4 7179759: ENV: Nightly fails during jdk copiyng for solaris platforms after FDS unzipping Summary: libjvm_g_db.so and libjvm_g_dtrace.so links in .diz file still had 64 directory Reviewed-by: kamg, dholmes, sspitsyn ! make/solaris/makefiles/dtrace.make Changeset: 40e5a3f2907e Author: amurillo Date: 2012-06-29 17:04 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/40e5a3f2907e Merge Changeset: cf37a594c38d Author: amurillo Date: 2012-06-29 17:04 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/cf37a594c38d Added tag hs24-b15 for changeset 40e5a3f2907e ! .hgtags Changeset: 0c7bb1f4f9c8 Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/0c7bb1f4f9c8 Added tag jdk8-b46 for changeset cf37a594c38d ! .hgtags Changeset: fa0c28fabbb1 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/fa0c28fabbb1 Added tag jdk8-b47 for changeset 0c7bb1f4f9c8 ! .hgtags From lana.steuck at oracle.com Mon Jul 16 15:44:37 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 16 Jul 2012 22:44:37 +0000 Subject: hg: jdk8/awt/jdk: 30 new changesets Message-ID: <20120716225033.82C72470AC@hg.openjdk.java.net> Changeset: 8d2ed9d58453 Author: katleman Date: 2012-06-28 09:33 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8d2ed9d58453 Added tag jdk8-b45 for changeset b92353a01aa0 ! .hgtags Changeset: 9d1738ef61d6 Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9d1738ef61d6 Added tag jdk8-b46 for changeset 8d2ed9d58453 ! .hgtags Changeset: 9881db0a65bf Author: prr Date: 2012-06-26 09:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9881db0a65bf 7145771: [macosx] CreateFont/Register.java test fails because of cached results of getAllFonts() Reviewed-by: igor, flar ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java Changeset: c689cc1ef29a Author: prr Date: 2012-06-26 09:53 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c689cc1ef29a 7176447: Lunix/Solaris fontpath.c : double free(family) Reviewed-by: igor, flar ! src/solaris/native/sun/awt/fontpath.c Changeset: ad126e65ccc5 Author: prr Date: 2012-06-26 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ad126e65ccc5 7164282: check for NULL return from malloc is testing wrong variable name. Reviewed-by: igor, flar ! src/windows/native/sun/font/lcdglyph.c Changeset: c960cb8d0f8b Author: lana Date: 2012-06-27 18:39 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c960cb8d0f8b Merge Changeset: 8e6b8a676596 Author: lana Date: 2012-07-03 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8e6b8a676596 Merge Changeset: 8a284872ee2d Author: lana Date: 2012-07-03 20:56 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8a284872ee2d Merge Changeset: ff0da4ea08a2 Author: robm Date: 2012-06-26 13:27 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ff0da4ea08a2 4244896: (process) Provide System.getPid(), System.killProcess(String pid) Reviewed-by: alanb ! src/share/classes/java/lang/Process.java ! src/solaris/classes/java/lang/UNIXProcess.java.bsd ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! src/solaris/classes/java/lang/UNIXProcess.java.solaris ! src/solaris/native/java/lang/UNIXProcess_md.c ! src/windows/classes/java/lang/ProcessImpl.java ! src/windows/native/java/lang/ProcessImpl_md.c ! test/java/lang/ProcessBuilder/Basic.java + test/java/lang/ProcessBuilder/DestroyTest.java Changeset: 94b525ce3653 Author: dholmes Date: 2012-06-27 01:36 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/94b525ce3653 7161229: PriorityBlockingQueue keeps hard reference to last removed element Reviewed-by: dholmes, forax, alanb Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! test/java/util/concurrent/BlockingQueue/LastElement.java Changeset: 7e9a7400329b Author: lana Date: 2012-06-26 22:59 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7e9a7400329b Merge Changeset: 2bba577b8ab8 Author: lana Date: 2012-06-27 00:09 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2bba577b8ab8 Merge Changeset: 612e56cf284c Author: coffeys Date: 2012-06-27 21:10 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/612e56cf284c 6893617: JDK 6 CNCtx always uses the default ORB Reviewed-by: lancea ! src/share/classes/com/sun/jndi/cosnaming/CNCtx.java Changeset: 819258b5002e Author: sherman Date: 2012-06-28 22:44 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/819258b5002e 7175845: jar uf changes file permissions unexpectedly 7177216: native2ascii changes file permissions of input file Summary: undo the File.createTempFile change in jar and native2ascii Reviewed-by: asaha ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/native2ascii/Main.java + test/sun/tools/native2ascii/Permission.java + test/tools/jar/UpdateJar.java Changeset: 9e15068b6946 Author: jgish Date: 2012-06-29 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9e15068b6946 7100996: (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads Summary: add usage note to clarify thread safety Reviewed-by: briangoetz, mduigou Contributed-by: jim.gish at oracle.com ! src/share/classes/java/lang/StringBuffer.java Changeset: 9df29b658145 Author: smarks Date: 2012-06-29 16:16 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9df29b658145 7170938: (str) incorrect wording in doc for String.subSequence Reviewed-by: forax, mduigou Contributed-by: Joe Bowbeer ! src/share/classes/java/lang/String.java Changeset: ecc5dd3790a1 Author: robm Date: 2012-07-02 19:32 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ecc5dd3790a1 7174887: Deadlock in jndi ldap connection cleanup Reviewed-by: xuelei ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java Changeset: b2fc66012451 Author: smarks Date: 2012-07-02 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b2fc66012451 7176907: additional warnings cleanup in java.util, java.util.regexp, java.util.zip Reviewed-by: forax, khazra, smarks Contributed-by: Mani Sarkar ! src/share/classes/java/util/InvalidPropertiesFormatException.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/zip/GZIPInputStream.java Changeset: d375ea39ce9c Author: mullan Date: 2012-07-03 14:56 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d375ea39ce9c 7133344: Document the java.security.properties system property feature in the java.security file Reviewed-by: hawtin, mullan, weijun Contributed-by: jason.uh at oracle.com ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 8ccbd5aabeab Author: lana Date: 2012-07-03 18:24 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8ccbd5aabeab Merge Changeset: 3ae91286f313 Author: xuelei Date: 2012-07-03 20:29 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3ae91286f313 7180038: regression test failure, SSLEngineBadBufferArrayAccess.java Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java Changeset: d828938945af Author: lana Date: 2012-07-03 20:58 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d828938945af Merge Changeset: 9957b4759354 Author: lana Date: 2012-07-10 11:41 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9957b4759354 Merge Changeset: 6df318863178 Author: erikj Date: 2012-07-03 16:10 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6df318863178 7181504: Update of latest build-infra Makefiles Reviewed-by: ohair ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CopySamples.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataFontConfig.gmk ! makefiles/GendataHtml32dtd.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateData.gmk ! makefiles/GenerateJavaSources.gmk ! makefiles/GensrcBuffer.gmk ! makefiles/GensrcIcons.gmk + makefiles/GensrcJObjC.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk + makefiles/Import.gmk - makefiles/LegacyMakefiles.gmk ! makefiles/Makefile - makefiles/OldImages.gmk ! makefiles/Tools.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/mapfiles/libjava/mapfile-vers ! makefiles/mapfiles/libjfr/mapfile-vers ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-solaris - 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 Changeset: 8cb908672d9e Author: erikj Date: 2012-07-03 11:45 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8cb908672d9e 7181508: Remove GenerateNativeHeader on awt java file Reviewed-by: ohair ! src/share/classes/java/awt/image/DirectColorModel.java ! src/share/classes/sun/awt/CharsetString.java ! src/share/classes/sun/java2d/pipe/RegionIterator.java ! src/share/native/sun/awt/image/cvutils/img_globals.c Changeset: 6cd68b7bd962 Author: erikj Date: 2012-07-03 16:01 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6cd68b7bd962 7181501: Add some GenerateNativeHeader annotations and misc Mac adjustments to makefiles Reviewed-by: ohair ! src/macosx/native/jobjc/build.xml ! src/macosx/native/jobjc/src/core/PrimitiveCoder.hs ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/FrameworkClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Clazz.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/ComplexCoderDescriptor.java Changeset: 5b0f880eb154 Author: ohair Date: 2012-07-05 13:31 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5b0f880eb154 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 Changeset: 00b22b23269a Author: katleman Date: 2012-07-11 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/00b22b23269a 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 Changeset: 3e4ab821f461 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3e4ab821f461 Added tag jdk8-b47 for changeset 00b22b23269a ! .hgtags Changeset: 6d9ea8c91808 Author: lana Date: 2012-07-16 14:49 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6d9ea8c91808 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 From oleg.pekhovskiy at oracle.com Tue Jul 17 02:05:32 2012 From: oleg.pekhovskiy at oracle.com (oleg.pekhovskiy at oracle.com) Date: Tue, 17 Jul 2012 09:05:32 +0000 Subject: hg: jdk8/awt/jdk: 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater Message-ID: <20120717090624.AFA37470CC@hg.openjdk.java.net> Changeset: 08842f8ce960 Author: bagiras Date: 2012-07-17 12:59 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/08842f8ce960 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater Reviewed-by: anthony, ant ! src/share/classes/sun/awt/SunToolkit.java From alexandr.scherbatiy at oracle.com Tue Jul 17 07:34:00 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 17 Jul 2012 18:34:00 +0400 Subject: [8] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 Message-ID: <500577D8.9050609@oracle.com> Hi, Please review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.00/ There are 2 fixed problems: - GraphicsDevice can have display mode which has non zero refresh rate. In this case the getBestModeForParameters method from the CGraphicsDevice.m class should return appropriate display mode even if the requested refresh rate is zero. - The original DisplayMode should be restored after exiting from the Full Screen mode. Thanks, Alexandr. From alexander.zuev at oracle.com Tue Jul 17 09:48:14 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Tue, 17 Jul 2012 20:48:14 +0400 Subject: [8] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 In-Reply-To: <500577D8.9050609@oracle.com> References: <500577D8.9050609@oracle.com> Message-ID: <5005974E.3010908@oracle.com> Alexander, couple of notes: - where is the code that throws IllegalArgumentException in case of no matching display mode found? - similar way we have to add check that throws an exception when someone tries to set display mode when it's not allowed. - the check for dcSupported here: ! if (originalMode != null) { ! if (dcSupported) { ! setDisplayMode(originalMode); ! } ! originalMode = null; } + } is not needed - later we check for it when we assign originalMode so if originalMode is set to non-null value then resolution change is allowed. With best regards, Alex On 7/17/12 18:34, Alexander Scherbatiy wrote: > > Hi, > > Please review the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 > webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.00/ > > > There are 2 fixed problems: > - GraphicsDevice can have display mode which has non zero refresh rate. > In this case the getBestModeForParameters method from the > CGraphicsDevice.m class should > return appropriate display mode even if the requested refresh rate > is zero. > > - The original DisplayMode should be restored after exiting from the > Full Screen mode. > > > Thanks, > Alexandr. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120717/aaec68e0/attachment.html From alexandr.scherbatiy at oracle.com Wed Jul 18 03:53:46 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 18 Jul 2012 14:53:46 +0400 Subject: [8] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 In-Reply-To: <5005974E.3010908@oracle.com> References: <500577D8.9050609@oracle.com> <5005974E.3010908@oracle.com> Message-ID: <500695BA.4010309@oracle.com> Could you review the updated version of the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.02/ - IllegalArgumentException now is thrown in case if matching display mode is not found - Extra display change support is removed Thanks, Alexandr. On 7/17/2012 8:48 PM, Alexander Zuev wrote: > Alexander, > > couple of notes: > > - where is the code that throws IllegalArgumentException in case of > no matching display mode found? > - similar way we have to add check that throws an exception when > someone tries to set display mode > when it's not allowed. > - the check for dcSupported here: > ! if (originalMode != null) { > ! if (dcSupported) { > ! setDisplayMode(originalMode); > ! } > ! originalMode = null; > } > + } > > is not needed - later we check for it when we assign originalMode so > if originalMode is set to non-null value then > resolution change is allowed. > > With best regards, > Alex > > > On 7/17/12 18:34, Alexander Scherbatiy wrote: >> >> Hi, >> >> Please review the fix: >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 >> webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.00/ >> >> >> There are 2 fixed problems: >> - GraphicsDevice can have display mode which has non zero refresh rate. >> In this case the getBestModeForParameters method from the >> CGraphicsDevice.m class should >> return appropriate display mode even if the requested refresh rate >> is zero. >> >> - The original DisplayMode should be restored after exiting from the >> Full Screen mode. >> >> >> Thanks, >> Alexandr. >> > > From alexander.zuev at oracle.com Wed Jul 18 05:14:33 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 18 Jul 2012 16:14:33 +0400 Subject: [8] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 In-Reply-To: <500695BA.4010309@oracle.com> References: <500577D8.9050609@oracle.com> <5005974E.3010908@oracle.com> <500695BA.4010309@oracle.com> Message-ID: <5006A8A9.4030501@oracle.com> Looks good to me. On 7/18/12 14:53, Alexander Scherbatiy wrote: > > > Could you review the updated version of the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 > webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.02/ > > - IllegalArgumentException now is thrown in case if matching display > mode is not found > - Extra display change support is removed > > Thanks, > Alexandr. > > > On 7/17/2012 8:48 PM, Alexander Zuev wrote: >> Alexander, >> >> couple of notes: >> >> - where is the code that throws IllegalArgumentException in case of >> no matching display mode found? >> - similar way we have to add check that throws an exception when >> someone tries to set display mode >> when it's not allowed. >> - the check for dcSupported here: >> ! if (originalMode != null) { >> ! if (dcSupported) { >> ! setDisplayMode(originalMode); >> ! } >> ! originalMode = null; >> } >> + } >> >> is not needed - later we check for it when we assign originalMode so >> if originalMode is set to non-null value then >> resolution change is allowed. >> >> With best regards, >> Alex >> >> >> On 7/17/12 18:34, Alexander Scherbatiy wrote: >>> >>> Hi, >>> >>> Please review the fix: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 >>> webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.00/ >>> >>> >>> There are 2 fixed problems: >>> - GraphicsDevice can have display mode which has non zero refresh rate. >>> In this case the getBestModeForParameters method from the >>> CGraphicsDevice.m class should >>> return appropriate display mode even if the requested refresh rate >>> is zero. >>> >>> - The original DisplayMode should be restored after exiting from the >>> Full Screen mode. >>> >>> >>> Thanks, >>> Alexandr. >>> >> >> > From andrew.brygin at oracle.com Wed Jul 18 04:26:26 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Wed, 18 Jul 2012 15:26:26 +0400 Subject: [8] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 In-Reply-To: <500695BA.4010309@oracle.com> References: <500577D8.9050609@oracle.com> <5005974E.3010908@oracle.com> <500695BA.4010309@oracle.com> Message-ID: <50069D62.2040402@oracle.com> Hello Alexandr, the fix looks fine to me. Thanks, Andrew On 18.07.2012 14:53, Alexander Scherbatiy wrote: > > > Could you review the updated version of the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 > webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.02/ > > - IllegalArgumentException now is thrown in case if matching display > mode is not found > - Extra display change support is removed > > Thanks, > Alexandr. > > > On 7/17/2012 8:48 PM, Alexander Zuev wrote: >> Alexander, >> >> couple of notes: >> >> - where is the code that throws IllegalArgumentException in case of >> no matching display mode found? >> - similar way we have to add check that throws an exception when >> someone tries to set display mode >> when it's not allowed. >> - the check for dcSupported here: >> ! if (originalMode != null) { >> ! if (dcSupported) { >> ! setDisplayMode(originalMode); >> ! } >> ! originalMode = null; >> } >> + } >> >> is not needed - later we check for it when we assign originalMode so >> if originalMode is set to non-null value then >> resolution change is allowed. >> >> With best regards, >> Alex >> >> >> On 7/17/12 18:34, Alexander Scherbatiy wrote: >>> >>> Hi, >>> >>> Please review the fix: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 >>> webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev.00/ >>> >>> >>> There are 2 fixed problems: >>> - GraphicsDevice can have display mode which has non zero refresh rate. >>> In this case the getBestModeForParameters method from the >>> CGraphicsDevice.m class should >>> return appropriate display mode even if the requested refresh rate >>> is zero. >>> >>> - The original DisplayMode should be restored after exiting from the >>> Full Screen mode. >>> >>> >>> Thanks, >>> Alexandr. >>> >> >> > From alexandr.scherbatiy at oracle.com Wed Jul 18 05:31:16 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 18 Jul 2012 16:31:16 +0400 Subject: [7u6] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 Message-ID: <5006AC94.3010706@oracle.com> Please review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev7u6.00/ This is a backported fix from the JDK 8 to JDK 7u6. There are 3 fixed problems: - GraphicsDevice can have display mode which has non zero refresh rate. In this case the getBestModeForParameters method from the CGraphicsDevice.m class should return appropriate display mode even if the requested refresh rate is zero. - The original DisplayMode should be restored after exiting from the Full Screen mode. - IllegalArgumentException should be thrown in case if matching display mode is not found Thanks, Alexandr. From andrew.brygin at oracle.com Wed Jul 18 06:12:22 2012 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Wed, 18 Jul 2012 17:12:22 +0400 Subject: [7u6] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 In-Reply-To: <5006AC94.3010706@oracle.com> References: <5006AC94.3010706@oracle.com> Message-ID: <5006B636.3050003@oracle.com> Hello Alexander, the fix looks fine to me. Thanks, Andrew On 18.07.2012 16:31, Alexander Scherbatiy wrote: > > Please review the fix: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 > webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev7u6.00/ > > > This is a backported fix from the JDK 8 to JDK 7u6. > > There are 3 fixed problems: > - GraphicsDevice can have display mode which has non zero refresh rate. > In this case the getBestModeForParameters method from the > CGraphicsDevice.m class should > return appropriate display mode even if the requested refresh rate > is zero. > > - The original DisplayMode should be restored after exiting from the > Full Screen mode. > > - IllegalArgumentException should be thrown in case if matching > display mode is not found > > > Thanks, > Alexandr. > From alexander.zuev at oracle.com Wed Jul 18 06:42:07 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 18 Jul 2012 17:42:07 +0400 Subject: [7u6] Review request for 7182902 [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 In-Reply-To: <5006AC94.3010706@oracle.com> References: <5006AC94.3010706@oracle.com> Message-ID: <5006BD2F.9050203@oracle.com> Looks fine to me. On 7/18/12 16:31, Alexander Scherbatiy wrote: > > Please review the fix: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182902 > webrev: http://cr.openjdk.java.net/~alexsch/7182902/webrev7u6.00/ > > > This is a backported fix from the JDK 8 to JDK 7u6. > > There are 3 fixed problems: > - GraphicsDevice can have display mode which has non zero refresh rate. > In this case the getBestModeForParameters method from the > CGraphicsDevice.m class should > return appropriate display mode even if the requested refresh rate > is zero. > > - The original DisplayMode should be restored after exiting from the > Full Screen mode. > > - IllegalArgumentException should be thrown in case if matching > display mode is not found > > > Thanks, > Alexandr. > From alexandr.scherbatiy at oracle.com Wed Jul 18 07:21:57 2012 From: alexandr.scherbatiy at oracle.com (alexandr.scherbatiy at oracle.com) Date: Wed, 18 Jul 2012 14:21:57 +0000 Subject: hg: jdk8/awt/jdk: 7182902: [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 Message-ID: <20120718142217.6F46747103@hg.openjdk.java.net> Changeset: 8a90db6c4d77 Author: alexsch Date: 2012-07-18 18:25 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8a90db6c4d77 7182902: [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 Reviewed-by: bae, kizune ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/native/sun/awt/CGraphicsDevice.m From Sergey.Bylokhov at oracle.com Thu Jul 19 07:53:27 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 19 Jul 2012 18:53:27 +0400 Subject: [7u6] Review request for 7184401: JDk7u6 Missing main menu bar in Netbeans after fix for 7162144 Message-ID: <50081F67.4090800@oracle.com> Hi Everyone, Please review the fix. This is rollback of 7162144. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184401 Webrev can be found at: http://cr.openjdk.java.net/~serb/7184401/webrev.00 -- Best regards, Sergey. From pavel.porvatov at oracle.com Thu Jul 19 08:12:13 2012 From: pavel.porvatov at oracle.com (pavel.porvatov at oracle.com) Date: Thu, 19 Jul 2012 15:12:13 +0000 Subject: hg: jdk8/awt/jdk: 7124330: [macosx] javax.swing.JComboBox throws unexpected ClassCastException Message-ID: <20120719151238.5EDB047142@hg.openjdk.java.net> Changeset: 28665fa73b4a Author: rupashka Date: 2012-07-19 19:09 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/28665fa73b4a 7124330: [macosx] javax.swing.JComboBox throws unexpected ClassCastException Reviewed-by: kizune ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java From alexander.zuev at oracle.com Thu Jul 19 08:45:45 2012 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Thu, 19 Jul 2012 15:45:45 +0000 Subject: hg: jdk8/awt/jdk: 7181027: [macosx] Unable to use headless mode Message-ID: <20120719154555.7101447143@hg.openjdk.java.net> Changeset: b1c5e4a843f3 Author: leonidr Date: 2012-07-19 19:41 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b1c5e4a843f3 7181027: [macosx] Unable to use headless mode Reviewed-by: anthony ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/solaris/native/java/lang/java_props_md.c From Sergey.Bylokhov at oracle.com Fri Jul 20 04:24:59 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 20 Jul 2012 15:24:59 +0400 Subject: [7u6] Review request for 7184401: JDk7u6 Missing main menu bar in Netbeans after fix for 7162144 In-Reply-To: <50081F67.4090800@oracle.com> References: <50081F67.4090800@oracle.com> Message-ID: <5009400B.4090209@oracle.com> Does anybody have a chance to review it? Thanks. 19.07.2012 18:53, Sergey Bylokhov wrote: > Hi Everyone, > Please review the fix. This is rollback of 7162144. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184401 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/7184401/webrev.00 > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Fri Jul 20 06:05:49 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 20 Jul 2012 17:05:49 +0400 Subject: [8] Review request for 7184365 closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails Message-ID: <500957AD.4010604@oracle.com> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184365 webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.00/ The failed test expects that TextListener is not invoked after changing empty text to empty for the TextArea and is invoked for the TextField. After switching the EDIT control to RICHEDIT on windows for the TextField the TextListener listener is not invoked for both TextField and TextArea in this case. To be consistent with other platforms the fix: - Moves the checking for new empty text from the LWTextAreaPeer to LWTextComponentPeer on Mac OS X - Adds the empty text checking to the XTextFieldPeer (the XTextAreaPeer class has already has one) on Linux Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Fri Jul 20 06:28:45 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 20 Jul 2012 17:28:45 +0400 Subject: [8] Review request for 7184365 closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails In-Reply-To: <500957AD.4010604@oracle.com> References: <500957AD.4010604@oracle.com> Message-ID: <50095D0D.4070009@oracle.com> Hi, Alexander. Can we remove these checks from the peers and move them to TextComponent.setText()? 20.07.2012 17:05, Alexander Scherbatiy wrote: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184365 > webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.00/ > > > The failed test expects that TextListener is not invoked after > changing empty text to empty for the TextArea > and is invoked for the TextField. > > After switching the EDIT control to RICHEDIT on windows for the > TextField the TextListener listener is not invoked for both TextField > and TextArea in this case. > > To be consistent with other platforms the fix: > - Moves the checking for new empty text from the LWTextAreaPeer to > LWTextComponentPeer on Mac OS X > - Adds the empty text checking to the XTextFieldPeer (the > XTextAreaPeer class has already has one) on Linux > > Thanks, > Alexandr. > -- Best regards, Sergey. From artem.ananiev at oracle.com Fri Jul 20 08:56:55 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 20 Jul 2012 19:56:55 +0400 Subject: [7u6] Review request for 7184401: JDk7u6 Missing main menu bar in Netbeans after fix for 7162144 In-Reply-To: <5009400B.4090209@oracle.com> References: <50081F67.4090800@oracle.com> <5009400B.4090209@oracle.com> Message-ID: <50097FC7.7030607@oracle.com> Sergey, the "fix" looks good. Thanks, Artem On 7/20/2012 3:24 PM, Sergey Bylokhov wrote: > Does anybody have a chance to review it? > Thanks. > > 19.07.2012 18:53, Sergey Bylokhov wrote: >> Hi Everyone, >> Please review the fix. This is rollback of 7162144. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184401 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/7184401/webrev.00 >> > > From Sergey.Bylokhov at oracle.com Fri Jul 20 10:05:33 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 20 Jul 2012 21:05:33 +0400 Subject: [7u6] Review request for 7184401: JDk7u6 Missing main menu bar in Netbeans after fix for 7162144 In-Reply-To: <50097FC7.7030607@oracle.com> References: <50081F67.4090800@oracle.com> <5009400B.4090209@oracle.com> <50097FC7.7030607@oracle.com> Message-ID: <50098FDD.3010502@oracle.com> I need one more reviewer. Artem thanks. 20.07.2012 19:56, Artem Ananiev wrote: > Sergey, > > the "fix" looks good. > > Thanks, > > Artem > > On 7/20/2012 3:24 PM, Sergey Bylokhov wrote: >> Does anybody have a chance to review it? >> Thanks. >> >> 19.07.2012 18:53, Sergey Bylokhov wrote: >>> Hi Everyone, >>> Please review the fix. This is rollback of 7162144. >>> >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184401 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/7184401/webrev.00 >>> >> >> -- Best regards, Sergey. From philip.race at oracle.com Fri Jul 20 10:15:00 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 20 Jul 2012 10:15:00 -0700 Subject: [7u6] Review request for 7184401: JDk7u6 Missing main menu bar in Netbeans after fix for 7162144 In-Reply-To: <50098FDD.3010502@oracle.com> References: <50081F67.4090800@oracle.com> <5009400B.4090209@oracle.com> <50097FC7.7030607@oracle.com> <50098FDD.3010502@oracle.com> Message-ID: <50099214.3090407@oracle.com> Looks ok to me .. -phil. On 7/20/2012 10:05 AM, Sergey Bylokhov wrote: > I need one more reviewer. > > Artem thanks. > > 20.07.2012 19:56, Artem Ananiev wrote: >> Sergey, >> >> the "fix" looks good. >> >> Thanks, >> >> Artem >> >> On 7/20/2012 3:24 PM, Sergey Bylokhov wrote: >>> Does anybody have a chance to review it? >>> Thanks. >>> >>> 19.07.2012 18:53, Sergey Bylokhov wrote: >>>> Hi Everyone, >>>> Please review the fix. This is rollback of 7162144. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184401 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/7184401/webrev.00 >>>> >>> >>> > > From Sergey.Bylokhov at oracle.com Fri Jul 20 10:18:46 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 20 Jul 2012 21:18:46 +0400 Subject: [7u6] Review request for 7184401: JDk7u6 Missing main menu bar in Netbeans after fix for 7162144 In-Reply-To: <50099214.3090407@oracle.com> References: <50081F67.4090800@oracle.com> <5009400B.4090209@oracle.com> <50097FC7.7030607@oracle.com> <50098FDD.3010502@oracle.com> <50099214.3090407@oracle.com> Message-ID: <500992F6.2020708@oracle.com> Thanks! Phil 20.07.2012 21:15, Phil Race wrote: > Looks ok to me .. > > -phil. > > On 7/20/2012 10:05 AM, Sergey Bylokhov wrote: >> I need one more reviewer. >> >> Artem thanks. >> >> 20.07.2012 19:56, Artem Ananiev wrote: >>> Sergey, >>> >>> the "fix" looks good. >>> >>> Thanks, >>> >>> Artem >>> >>> On 7/20/2012 3:24 PM, Sergey Bylokhov wrote: >>>> Does anybody have a chance to review it? >>>> Thanks. >>>> >>>> 19.07.2012 18:53, Sergey Bylokhov wrote: >>>>> Hi Everyone, >>>>> Please review the fix. This is rollback of 7162144. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184401 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/7184401/webrev.00 >>>>> >>>> >>>> >> >> > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Mon Jul 23 03:14:38 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 23 Jul 2012 14:14:38 +0400 Subject: [8] Review request for 7185512 The printout doesn't match image on screen. Message-ID: <500D240E.8070907@oracle.com> Please review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185512 webrev: http://cr.openjdk.java.net/~alexsch/7185512/webrev.00/ After switching the EDIT control to RICHEDIT for the TextField component the WM_PRINTCLIENT message should also be handled in the same way as it is done for the TextArea. The WM_PRINTCLIENT message handling is moved to the AwtTextComponent class in the fix. Thanks, Alexandr. From Sergey.Bylokhov at oracle.com Mon Jul 23 03:29:44 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Jul 2012 14:29:44 +0400 Subject: [8] Review request for 7185512 The printout doesn't match image on screen. In-Reply-To: <500D240E.8070907@oracle.com> References: <500D240E.8070907@oracle.com> Message-ID: <500D2798.8010709@oracle.com> Hi, Alexander. Does we get correct text in the textfield in the testcase from the CR(printAll)? 23.07.2012 14:14, Alexander Scherbatiy wrote: > Please review the fix: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185512 > webrev: http://cr.openjdk.java.net/~alexsch/7185512/webrev.00/ > > After switching the EDIT control to RICHEDIT for the TextField > component the WM_PRINTCLIENT message should also be handled in the > same way as it is done for the TextArea. > > The WM_PRINTCLIENT message handling is moved to the AwtTextComponent > class in the fix. > > Thanks, > Alexandr. > -- Best regards, Sergey. From artem.ananiev at oracle.com Mon Jul 23 03:41:33 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 23 Jul 2012 14:41:33 +0400 Subject: [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) In-Reply-To: <500D14E2.6010107@oracle.com> References: <500D14E2.6010107@oracle.com> Message-ID: <500D2A5D.4020602@oracle.com> Hi, Alex, (cross-posting to awt-dev) I see several other native methods in CDataTransferer, e.g. formatForIndex(). Could you confirm, they cannot be called in the headless mode, so there is no need to protect them with headless check, please? Could you also file a SubCR against JDK8 with the idea we discussed offline: create a new CHeadlessDataTransferer class to use in the headless mode instead of CDataTransferer + headless checks, please? Thanks, Artem On 7/23/2012 1:09 PM, Alexander Zuev wrote: > Hello, > > please review my fix 7184951: [macosx] Exception at > java.awt.datatransfer on headless mode (only in GUI session) > CR description can be found here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 > > Webrev with the proposed change can be seen here: > http://cr.openjdk.java.net/~kizune/7184951/webrev.00 > > The problem here lays somewhere deep in the Toolkit life cycle on > Mac OS X - at the time we initialize datatransfer the > Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later > when we trying to use it it returns HeadlessToolkit. That's definitely > wrong but at this stage it's too risky to fiddle with the life cycle > itself so this is a hotfix that deals with the fallout of the actual > error. The fix for jdk8 should be different. > > With best regards, > Alex From alexander.zuev at oracle.com Mon Jul 23 03:53:09 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 23 Jul 2012 14:53:09 +0400 Subject: [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) In-Reply-To: <500D2A5D.4020602@oracle.com> References: <500D14E2.6010107@oracle.com> <500D2A5D.4020602@oracle.com> Message-ID: <500D2D15.9070404@oracle.com> Artem, these native methods should not be called according to the logic of the class so we shouldn't safeguard them. I will create the sub-cr against the jdk8. WBR, Alex On 7/23/12 14:41, Artem Ananiev wrote: > Hi, Alex, > > (cross-posting to awt-dev) > > I see several other native methods in CDataTransferer, e.g. > formatForIndex(). Could you confirm, they cannot be called in the > headless mode, so there is no need to protect them with headless > check, please? > > Could you also file a SubCR against JDK8 with the idea we discussed > offline: create a new CHeadlessDataTransferer class to use in the > headless mode instead of CDataTransferer + headless checks, please? > > Thanks, > > Artem > > On 7/23/2012 1:09 PM, Alexander Zuev wrote: >> Hello, >> >> please review my fix 7184951: [macosx] Exception at >> java.awt.datatransfer on headless mode (only in GUI session) >> CR description can be found here: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 >> >> Webrev with the proposed change can be seen here: >> http://cr.openjdk.java.net/~kizune/7184951/webrev.00 >> >> The problem here lays somewhere deep in the Toolkit life cycle on >> Mac OS X - at the time we initialize datatransfer the >> Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later >> when we trying to use it it returns HeadlessToolkit. That's definitely >> wrong but at this stage it's too risky to fiddle with the life cycle >> itself so this is a hotfix that deals with the fallout of the actual >> error. The fix for jdk8 should be different. >> >> With best regards, >> Alex From alexandr.scherbatiy at oracle.com Mon Jul 23 05:57:46 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 23 Jul 2012 16:57:46 +0400 Subject: [8] Review request for 7185512 The printout doesn't match image on screen. In-Reply-To: <500D2798.8010709@oracle.com> References: <500D240E.8070907@oracle.com> <500D2798.8010709@oracle.com> Message-ID: <500D4A4A.9070703@oracle.com> On 7/23/2012 2:29 PM, Sergey Bylokhov wrote: > Hi, Alexander. > Does we get correct text in the textfield in the testcase from the > CR(printAll)? I think it can be treated as a separated issue that the RICHEDIT control with the current settings in the AwtTextField class does not show text after CR symbol. It does not relate to the printing functionality. Thanks, Alexandr. > > 23.07.2012 14:14, Alexander Scherbatiy wrote: >> Please review the fix: >> >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185512 >> webrev: http://cr.openjdk.java.net/~alexsch/7185512/webrev.00/ >> >> After switching the EDIT control to RICHEDIT for the TextField >> component the WM_PRINTCLIENT message should also be handled in the >> same way as it is done for the TextArea. >> >> The WM_PRINTCLIENT message handling is moved to the AwtTextComponent >> class in the fix. >> >> Thanks, >> Alexandr. >> > > From oleg.pekhovskiy at oracle.com Mon Jul 23 06:08:08 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Mon, 23 Jul 2012 17:08:08 +0400 Subject: [8] Review request for 7185512 The printout doesn't match image on screen. In-Reply-To: <500D240E.8070907@oracle.com> References: <500D240E.8070907@oracle.com> Message-ID: <500D4CB8.8070701@oracle.com> Looks good to me. Thanks, Oleg 7/23/2012 2:14 PM, Alexander Scherbatiy wrote: > Please review the fix: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185512 > webrev: http://cr.openjdk.java.net/~alexsch/7185512/webrev.00/ > > After switching the EDIT control to RICHEDIT for the TextField > component the WM_PRINTCLIENT message should also be handled in the > same way as it is done for the TextArea. > > The WM_PRINTCLIENT message handling is moved to the AwtTextComponent > class in the fix. > > Thanks, > Alexandr. > From artem.ananiev at oracle.com Mon Jul 23 06:19:45 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 23 Jul 2012 17:19:45 +0400 Subject: [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) In-Reply-To: <500D2D15.9070404@oracle.com> References: <500D14E2.6010107@oracle.com> <500D2A5D.4020602@oracle.com> <500D2D15.9070404@oracle.com> Message-ID: <500D4F71.6080902@oracle.com> On 7/23/2012 2:53 PM, Alexander Zuev wrote: > Artem, > > these native methods should not be called according to the logic of the > class so we shouldn't safeguard them. Could you elaborate on that, please? > I will create the sub-cr against the jdk8. Thanks! Artem > WBR, > Alex > > > > On 7/23/12 14:41, Artem Ananiev wrote: >> Hi, Alex, >> >> (cross-posting to awt-dev) >> >> I see several other native methods in CDataTransferer, e.g. >> formatForIndex(). Could you confirm, they cannot be called in the >> headless mode, so there is no need to protect them with headless >> check, please? >> >> Could you also file a SubCR against JDK8 with the idea we discussed >> offline: create a new CHeadlessDataTransferer class to use in the >> headless mode instead of CDataTransferer + headless checks, please? >> >> Thanks, >> >> Artem >> >> On 7/23/2012 1:09 PM, Alexander Zuev wrote: >>> Hello, >>> >>> please review my fix 7184951: [macosx] Exception at >>> java.awt.datatransfer on headless mode (only in GUI session) >>> CR description can be found here: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 >>> >>> Webrev with the proposed change can be seen here: >>> http://cr.openjdk.java.net/~kizune/7184951/webrev.00 >>> >>> The problem here lays somewhere deep in the Toolkit life cycle on >>> Mac OS X - at the time we initialize datatransfer the >>> Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later >>> when we trying to use it it returns HeadlessToolkit. That's definitely >>> wrong but at this stage it's too risky to fiddle with the life cycle >>> itself so this is a hotfix that deals with the fallout of the actual >>> error. The fix for jdk8 should be different. >>> >>> With best regards, >>> Alex > > From artem.ananiev at oracle.com Mon Jul 23 06:22:48 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 23 Jul 2012 17:22:48 +0400 Subject: [8] Review request for 7185512 The printout doesn't match image on screen. In-Reply-To: <500D4A4A.9070703@oracle.com> References: <500D240E.8070907@oracle.com> <500D2798.8010709@oracle.com> <500D4A4A.9070703@oracle.com> Message-ID: <500D5028.4050505@oracle.com> On 7/23/2012 4:57 PM, Alexander Scherbatiy wrote: > On 7/23/2012 2:29 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Does we get correct text in the textfield in the testcase from the >> CR(printAll)? > I think it can be treated as a separated issue that the RICHEDIT control > with the current settings in the AwtTextField class does not show text > after CR symbol. > It does not relate to the printing functionality. Agree. It looks like a minor issue, which can be addressed in JDK8 time frame. Could you file the bug, please? Thanks, Artem > Thanks, > Alexandr. > >> >> 23.07.2012 14:14, Alexander Scherbatiy wrote: >>> Please review the fix: >>> >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185512 >>> webrev: http://cr.openjdk.java.net/~alexsch/7185512/webrev.00/ >>> >>> After switching the EDIT control to RICHEDIT for the TextField >>> component the WM_PRINTCLIENT message should also be handled in the >>> same way as it is done for the TextArea. >>> >>> The WM_PRINTCLIENT message handling is moved to the AwtTextComponent >>> class in the fix. >>> >>> Thanks, >>> Alexandr. >>> >> >> > From artem.ananiev at oracle.com Mon Jul 23 06:25:25 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 23 Jul 2012 17:25:25 +0400 Subject: [8] Review request for 7185512 The printout doesn't match image on screen. In-Reply-To: <500D240E.8070907@oracle.com> References: <500D240E.8070907@oracle.com> Message-ID: <500D50C5.4000306@oracle.com> Hi, Alexandr, the fix looks fine. Did you investigate if there are other WM_* handled which were present in AwtTextArea, but not in AwtTextField? Such handlers are possible candidates for promoting to AwtTextComponent as well (of course, it should be addressed in a separate CR, if found). Thanks, Artem On 7/23/2012 2:14 PM, Alexander Scherbatiy wrote: > Please review the fix: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185512 > webrev: http://cr.openjdk.java.net/~alexsch/7185512/webrev.00/ > > After switching the EDIT control to RICHEDIT for the TextField component > the WM_PRINTCLIENT message should also be handled in the same way as it > is done for the TextArea. > > The WM_PRINTCLIENT message handling is moved to the AwtTextComponent > class in the fix. > > Thanks, > Alexandr. > From alexander.zuev at oracle.com Mon Jul 23 06:28:10 2012 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Mon, 23 Jul 2012 17:28:10 +0400 Subject: [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) In-Reply-To: <500D4F71.6080902@oracle.com> References: <500D14E2.6010107@oracle.com> <500D2A5D.4020602@oracle.com> <500D2D15.9070404@oracle.com> <500D4F71.6080902@oracle.com> Message-ID: <500D516A.1060001@oracle.com> On 7/23/12 17:19, Artem Ananiev wrote: > > On 7/23/2012 2:53 PM, Alexander Zuev wrote: >> Artem, >> >> these native methods should not be called according to the logic of the >> class so we shouldn't safeguard them. > > Could you elaborate on that, please? Sure. The only native method that is not related to drag and drop functionality (which can not be instantiated in headless mode anyways) is private native String formatForIndex(long index); It is being called from the protected method getNativeForFormat(long format) which, in turn, being called by the drag-related methods or from public getters that check the index to be in the valid borders. Since we do not register any native-backed flavors in the set this native method will not be called in headless mode. > >> I will create the sub-cr against the jdk8. > > Thanks! > > Artem > >> WBR, >> Alex >> >> >> >> On 7/23/12 14:41, Artem Ananiev wrote: >>> Hi, Alex, >>> >>> (cross-posting to awt-dev) >>> >>> I see several other native methods in CDataTransferer, e.g. >>> formatForIndex(). Could you confirm, they cannot be called in the >>> headless mode, so there is no need to protect them with headless >>> check, please? >>> >>> Could you also file a SubCR against JDK8 with the idea we discussed >>> offline: create a new CHeadlessDataTransferer class to use in the >>> headless mode instead of CDataTransferer + headless checks, please? >>> >>> Thanks, >>> >>> Artem >>> >>> On 7/23/2012 1:09 PM, Alexander Zuev wrote: >>>> Hello, >>>> >>>> please review my fix 7184951: [macosx] Exception at >>>> java.awt.datatransfer on headless mode (only in GUI session) >>>> CR description can be found here: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 >>>> >>>> Webrev with the proposed change can be seen here: >>>> http://cr.openjdk.java.net/~kizune/7184951/webrev.00 >>>> >>>> The problem here lays somewhere deep in the Toolkit life cycle on >>>> Mac OS X - at the time we initialize datatransfer the >>>> Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later >>>> when we trying to use it it returns HeadlessToolkit. That's definitely >>>> wrong but at this stage it's too risky to fiddle with the life cycle >>>> itself so this is a hotfix that deals with the fallout of the actual >>>> error. The fix for jdk8 should be different. >>>> >>>> With best regards, >>>> Alex >> >> From alexandr.scherbatiy at oracle.com Mon Jul 23 06:31:42 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 23 Jul 2012 17:31:42 +0400 Subject: [8] Review request for 7185512 The printout doesn't match image on screen. In-Reply-To: <500D5028.4050505@oracle.com> References: <500D240E.8070907@oracle.com> <500D2798.8010709@oracle.com> <500D4A4A.9070703@oracle.com> <500D5028.4050505@oracle.com> Message-ID: <500D523E.5050403@oracle.com> On 7/23/2012 5:22 PM, Artem Ananiev wrote: > > On 7/23/2012 4:57 PM, Alexander Scherbatiy wrote: >> On 7/23/2012 2:29 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> Does we get correct text in the textfield in the testcase from the >>> CR(printAll)? >> I think it can be treated as a separated issue that the RICHEDIT control >> with the current settings in the AwtTextField class does not show text >> after CR symbol. >> It does not relate to the printing functionality. > > Agree. It looks like a minor issue, which can be addressed in JDK8 > time frame. Could you file the bug, please? I have created the issue: 7186036 TextField class does not show text after CR on Windows http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7186036 Thanks, Alexandr. > > Thanks, > > Artem > >> Thanks, >> Alexandr. >> >>> >>> 23.07.2012 14:14, Alexander Scherbatiy wrote: >>>> Please review the fix: >>>> >>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185512 >>>> webrev: http://cr.openjdk.java.net/~alexsch/7185512/webrev.00/ >>>> >>>> After switching the EDIT control to RICHEDIT for the TextField >>>> component the WM_PRINTCLIENT message should also be handled in the >>>> same way as it is done for the TextArea. >>>> >>>> The WM_PRINTCLIENT message handling is moved to the AwtTextComponent >>>> class in the fix. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >>> >> From alexandr.scherbatiy at oracle.com Mon Jul 23 06:44:21 2012 From: alexandr.scherbatiy at oracle.com (alexandr.scherbatiy at oracle.com) Date: Mon, 23 Jul 2012 13:44:21 +0000 Subject: hg: jdk8/awt/jdk: 7185512: The printout doesn't match image on screen. Message-ID: <20120723134500.1C7BD4719F@hg.openjdk.java.net> Changeset: f04d8dee2da9 Author: alexsch Date: 2012-07-23 17:41 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f04d8dee2da9 7185512: The printout doesn't match image on screen. Reviewed-by: serb, bagiras ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h From Sergey.Bylokhov at oracle.com Mon Jul 23 06:49:03 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Jul 2012 17:49:03 +0400 Subject: [8] Review request for 7185512 The printout doesn't match image on screen. In-Reply-To: <500D4A4A.9070703@oracle.com> References: <500D240E.8070907@oracle.com> <500D2798.8010709@oracle.com> <500D4A4A.9070703@oracle.com> Message-ID: <500D564F.2080702@oracle.com> Fix looks good. 23.07.2012 16:57, Alexander Scherbatiy wrote: > On 7/23/2012 2:29 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Does we get correct text in the textfield in the testcase from the >> CR(printAll)? > I think it can be treated as a separated issue that the RICHEDIT > control with the current settings in the AwtTextField class does not > show text after CR symbol. > It does not relate to the printing functionality. > > Thanks, > Alexandr. > >> >> 23.07.2012 14:14, Alexander Scherbatiy wrote: >>> Please review the fix: >>> >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185512 >>> webrev: http://cr.openjdk.java.net/~alexsch/7185512/webrev.00/ >>> >>> After switching the EDIT control to RICHEDIT for the TextField >>> component the WM_PRINTCLIENT message should also be handled in the >>> same way as it is done for the TextArea. >>> >>> The WM_PRINTCLIENT message handling is moved to the AwtTextComponent >>> class in the fix. >>> >>> Thanks, >>> Alexandr. >>> >> >> > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Mon Jul 23 06:49:40 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 23 Jul 2012 17:49:40 +0400 Subject: [7u6] Review request for 7185512 The printout doesn't match image on screen. Message-ID: <500D5674.4080406@oracle.com> Please review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185512 webrev: http://cr.openjdk.java.net/~alexsch/7185512/webrev.00/ This is a backported fix from the JDK 8 to JDK 7u6. The JDK 8 patch does not require changes. After switching the EDIT control to RICHEDIT for the TextField component the WM_PRINTCLIENT message should also be handled in the same way as it is done for the TextArea. The WM_PRINTCLIENT message handling is moved to the AwtTextComponent class in the fix. Thanks, Alexandr. From oleg.pekhovskiy at oracle.com Mon Jul 23 06:58:52 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Mon, 23 Jul 2012 17:58:52 +0400 Subject: [7u6] Review request for 7185512 The printout doesn't match image on screen. In-Reply-To: <500D5674.4080406@oracle.com> References: <500D5674.4080406@oracle.com> Message-ID: <500D589C.6000706@oracle.com> Looks good to me. Thanks, Oleg 7/23/2012 5:49 PM, Alexander Scherbatiy wrote: > > Please review the fix: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185512 > webrev: http://cr.openjdk.java.net/~alexsch/7185512/webrev.00/ > > This is a backported fix from the JDK 8 to JDK 7u6. > The JDK 8 patch does not require changes. > > After switching the EDIT control to RICHEDIT for the TextField > component the WM_PRINTCLIENT message should also be handled in the > same way as it is done for the TextArea. > > The WM_PRINTCLIENT message handling is moved to the AwtTextComponent > class in the fix. > > > Thanks, > Alexandr. > From Sergey.Bylokhov at oracle.com Mon Jul 23 07:53:12 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Jul 2012 18:53:12 +0400 Subject: [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) In-Reply-To: <500D516A.1060001@oracle.com> References: <500D14E2.6010107@oracle.com> <500D2A5D.4020602@oracle.com> <500D2D15.9070404@oracle.com> <500D4F71.6080902@oracle.com> <500D516A.1060001@oracle.com> Message-ID: <500D6558.3000301@oracle.com> Hi, Alexander. Fix looks good 23.07.2012 17:28, Alexander Zuev wrote: > On 7/23/12 17:19, Artem Ananiev wrote: >> >> On 7/23/2012 2:53 PM, Alexander Zuev wrote: >>> Artem, >>> >>> these native methods should not be called according to the logic of the >>> class so we shouldn't safeguard them. >> >> Could you elaborate on that, please? > Sure. The only native method that is not related to drag and drop > functionality > (which can not be instantiated in headless mode anyways) is private > native String formatForIndex(long index); > It is being called from the protected method getNativeForFormat(long > format) which, in turn, being called > by the drag-related methods or from public getters that check the > index to be in the valid borders. > Since we do not register any native-backed flavors in the set this > native method will not be called in headless mode. >> >>> I will create the sub-cr against the jdk8. >> >> Thanks! >> >> Artem >> >>> WBR, >>> Alex >>> >>> >>> >>> On 7/23/12 14:41, Artem Ananiev wrote: >>>> Hi, Alex, >>>> >>>> (cross-posting to awt-dev) >>>> >>>> I see several other native methods in CDataTransferer, e.g. >>>> formatForIndex(). Could you confirm, they cannot be called in the >>>> headless mode, so there is no need to protect them with headless >>>> check, please? >>>> >>>> Could you also file a SubCR against JDK8 with the idea we discussed >>>> offline: create a new CHeadlessDataTransferer class to use in the >>>> headless mode instead of CDataTransferer + headless checks, please? >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 7/23/2012 1:09 PM, Alexander Zuev wrote: >>>>> Hello, >>>>> >>>>> please review my fix 7184951: [macosx] Exception at >>>>> java.awt.datatransfer on headless mode (only in GUI session) >>>>> CR description can be found here: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 >>>>> >>>>> Webrev with the proposed change can be seen here: >>>>> http://cr.openjdk.java.net/~kizune/7184951/webrev.00 >>>>> >>>>> The problem here lays somewhere deep in the Toolkit life cycle on >>>>> Mac OS X - at the time we initialize datatransfer the >>>>> Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later >>>>> when we trying to use it it returns HeadlessToolkit. That's >>>>> definitely >>>>> wrong but at this stage it's too risky to fiddle with the life cycle >>>>> itself so this is a hotfix that deals with the fallout of the actual >>>>> error. The fix for jdk8 should be different. >>>>> >>>>> With best regards, >>>>> Alex >>> >>> > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Jul 23 08:14:02 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Jul 2012 19:14:02 +0400 Subject: [7u6] Review request for 7185512 The printout doesn't match image on screen. In-Reply-To: <500D5674.4080406@oracle.com> References: <500D5674.4080406@oracle.com> Message-ID: <500D6A3A.2070606@oracle.com> Hi, Alexander. Fix looks good, 23.07.2012 17:49, Alexander Scherbatiy wrote: > > Please review the fix: > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7185512 > webrev: http://cr.openjdk.java.net/~alexsch/7185512/webrev.00/ > > This is a backported fix from the JDK 8 to JDK 7u6. > The JDK 8 patch does not require changes. > > After switching the EDIT control to RICHEDIT for the TextField > component the WM_PRINTCLIENT message should also be handled in the > same way as it is done for the TextArea. > > The WM_PRINTCLIENT message handling is moved to the AwtTextComponent > class in the fix. > > > Thanks, > Alexandr. > -- Best regards, Sergey. From artem.ananiev at oracle.com Mon Jul 23 08:27:45 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 23 Jul 2012 19:27:45 +0400 Subject: [7u6] Please review my fix for 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) In-Reply-To: <500D516A.1060001@oracle.com> References: <500D14E2.6010107@oracle.com> <500D2A5D.4020602@oracle.com> <500D2D15.9070404@oracle.com> <500D4F71.6080902@oracle.com> <500D516A.1060001@oracle.com> Message-ID: <500D6D71.5070709@oracle.com> On 7/23/2012 5:28 PM, Alexander Zuev wrote: > On 7/23/12 17:19, Artem Ananiev wrote: >> >> On 7/23/2012 2:53 PM, Alexander Zuev wrote: >>> Artem, >>> >>> these native methods should not be called according to the logic of the >>> class so we shouldn't safeguard them. >> >> Could you elaborate on that, please? > Sure. The only native method that is not related to drag and drop > functionality > (which can not be instantiated in headless mode anyways) is private > native String formatForIndex(long index); > It is being called from the protected method getNativeForFormat(long > format) which, in turn, being called > by the drag-related methods or from public getters that check the index > to be in the valid borders. > Since we do not register any native-backed flavors in the set this > native method will not be called in headless mode. OK, fine. Thanks for the confirmation. Looks good. Artem >>> I will create the sub-cr against the jdk8. >> >> Thanks! >> >> Artem >> >>> WBR, >>> Alex >>> >>> >>> >>> On 7/23/12 14:41, Artem Ananiev wrote: >>>> Hi, Alex, >>>> >>>> (cross-posting to awt-dev) >>>> >>>> I see several other native methods in CDataTransferer, e.g. >>>> formatForIndex(). Could you confirm, they cannot be called in the >>>> headless mode, so there is no need to protect them with headless >>>> check, please? >>>> >>>> Could you also file a SubCR against JDK8 with the idea we discussed >>>> offline: create a new CHeadlessDataTransferer class to use in the >>>> headless mode instead of CDataTransferer + headless checks, please? >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 7/23/2012 1:09 PM, Alexander Zuev wrote: >>>>> Hello, >>>>> >>>>> please review my fix 7184951: [macosx] Exception at >>>>> java.awt.datatransfer on headless mode (only in GUI session) >>>>> CR description can be found here: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184951 >>>>> >>>>> Webrev with the proposed change can be seen here: >>>>> http://cr.openjdk.java.net/~kizune/7184951/webrev.00 >>>>> >>>>> The problem here lays somewhere deep in the Toolkit life cycle on >>>>> Mac OS X - at the time we initialize datatransfer the >>>>> Toolgit.getDefaultToolkit() returns an LWCToolkit instance and later >>>>> when we trying to use it it returns HeadlessToolkit. That's definitely >>>>> wrong but at this stage it's too risky to fiddle with the life cycle >>>>> itself so this is a hotfix that deals with the fallout of the actual >>>>> error. The fix for jdk8 should be different. >>>>> >>>>> With best regards, >>>>> Alex >>> >>> > > From oleg.pekhovskiy at oracle.com Mon Jul 23 08:34:27 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Mon, 23 Jul 2012 19:34:27 +0400 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater Message-ID: <500D6F03.9000708@oracle.com> Hi! Please review this back-port being already pushed to jdk8 but deferred for 7u6. Bug: http://bugs.sun.com/view_bug.do?bug_id=7177040 Webrev: http://cr.openjdk.java.net/~bagiras/7u8/7177040.1 Review thread for 7u6: http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003106.html Reviewers 7u6 & 8: Anthony Petrov, Anton Tarasov Thanks, Oleg From anton.tarasov at oracle.com Mon Jul 23 23:10:02 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 24 Jul 2012 10:10:02 +0400 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <500D6F03.9000708@oracle.com> References: <500D6F03.9000708@oracle.com> Message-ID: <500E3C3A.2010100@oracle.com> Looks fine. Thanks, Anton. On 23.07.2012 19:34, Oleg Pekhovskiy wrote: > Hi! > > Please review this back-port being already pushed to jdk8 but deferred for 7u6. > > Bug: > http://bugs.sun.com/view_bug.do?bug_id=7177040 > > Webrev: > http://cr.openjdk.java.net/~bagiras/7u8/7177040.1 > > Review thread for 7u6: > http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003106.html > > Reviewers 7u6 & 8: > Anthony Petrov, Anton Tarasov > > Thanks, > Oleg From artem.ananiev at oracle.com Tue Jul 24 03:35:34 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 24 Jul 2012 14:35:34 +0400 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <500D6F03.9000708@oracle.com> References: <500D6F03.9000708@oracle.com> Message-ID: <500E7A76.6010306@oracle.com> Hi, Oleg, as we've already discussed offline, this area should be improved in JDK8, but in 7u8 the proposed fix is enough. Thanks, Artem On 7/23/2012 7:34 PM, Oleg Pekhovskiy wrote: > Hi! > > Please review this back-port being already pushed to jdk8 but deferred > for 7u6. > > Bug: > http://bugs.sun.com/view_bug.do?bug_id=7177040 > > Webrev: > http://cr.openjdk.java.net/~bagiras/7u8/7177040.1 > > Review thread for 7u6: > http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003106.html > > Reviewers 7u6 & 8: > Anthony Petrov, Anton Tarasov > > Thanks, > Oleg From peter.levart at gmail.com Tue Jul 24 04:42:08 2012 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 24 Jul 2012 13:42:08 +0200 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <500D6F03.9000708@oracle.com> References: <500D6F03.9000708@oracle.com> Message-ID: Hi Oleg, This is just cosmetics, but: SunToolkit: public synchronized boolean noEvents() { return queueHead == null && !isFlushing; } ... a thread calling noEvents could see occasional "spikes" of false return even though there is no flushing being performed (when other thread is calling flush on an empty PostEventQueue). Improved flush method would look like this: public void flush() { EventQueueItem tempQueue; synchronized (this) { tempQueue = queueHead; queueHead = queueTail = null; isFlushing = *(tempQueue != null)*; } try { while (tempQueue != null) { eventQueue.postEvent(tempQueue.event); tempQueue = tempQueue.next; } } finally { isFlushing = false; } } Regards, Peter 2012/7/23 Oleg Pekhovskiy > Hi! > > Please review this back-port being already pushed to jdk8 but deferred for > 7u6. > > Bug: > http://bugs.sun.com/view_bug.**do?bug_id=7177040 > > Webrev: > http://cr.openjdk.java.net/~**bagiras/7u8/7177040.1 > > Review thread for 7u6: > http://mail.openjdk.java.net/**pipermail/awt-dev/2012-July/**003106.html > > Reviewers 7u6 & 8: > Anthony Petrov, Anton Tarasov > > Thanks, > Oleg > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120724/3f2fc01b/attachment.html From alexandr.scherbatiy at oracle.com Tue Jul 24 05:17:27 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 24 Jul 2012 16:17:27 +0400 Subject: [8] Review request for 7184365 closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails In-Reply-To: <50095D0D.4070009@oracle.com> References: <500957AD.4010604@oracle.com> <50095D0D.4070009@oracle.com> Message-ID: <500E9257.6060806@oracle.com> On 7/20/2012 5:28 PM, Sergey Bylokhov wrote: > Hi, Alexander. > Can we remove these checks from the peers and move them to > TextComponent.setText()? I see. Could you review the updated fix? The empty text check is removed from the LWTextAreaPeer an XTextAreaPeer and moved to the TextComponent. webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.01/ Thanks, Alexandr. > > 20.07.2012 17:05, Alexander Scherbatiy wrote: >> >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184365 >> webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.00/ >> >> >> The failed test expects that TextListener is not invoked after >> changing empty text to empty for the TextArea >> and is invoked for the TextField. >> >> After switching the EDIT control to RICHEDIT on windows for the >> TextField the TextListener listener is not invoked for both TextField >> and TextArea in this case. >> >> To be consistent with other platforms the fix: >> - Moves the checking for new empty text from the LWTextAreaPeer to >> LWTextComponentPeer on Mac OS X >> - Adds the empty text checking to the XTextFieldPeer (the >> XTextAreaPeer class has already has one) on Linux >> >> Thanks, >> Alexandr. >> > > From alexandr.scherbatiy at oracle.com Tue Jul 24 05:27:04 2012 From: alexandr.scherbatiy at oracle.com (alexandr.scherbatiy at oracle.com) Date: Tue, 24 Jul 2012 12:27:04 +0000 Subject: hg: jdk8/awt/jdk: 7129800: [macosx] Regression test OverrideRedirectWindowActivationTest fails due to timing issue Message-ID: <20120724122744.460B5471D2@hg.openjdk.java.net> Changeset: 8a5a71e853ed Author: alexsch Date: 2012-07-24 16:26 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8a5a71e853ed 7129800: [macosx] Regression test OverrideRedirectWindowActivationTest fails due to timing issue Reviewed-by: rupashka + test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java From Sergey.Bylokhov at oracle.com Tue Jul 24 05:32:38 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Jul 2012 16:32:38 +0400 Subject: [8] Review request for 7184365 closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails In-Reply-To: <500E9257.6060806@oracle.com> References: <500957AD.4010604@oracle.com> <50095D0D.4070009@oracle.com> <500E9257.6060806@oracle.com> Message-ID: <500E95E6.5010901@oracle.com> Hi, Alexander. A few comments: - LWTextComponentPeer.setText can be final now. - Behavior of TextComponent.setText(null) && getText() were changed for null values if peer does not exists. 24.07.2012 16:17, Alexander Scherbatiy wrote: > On 7/20/2012 5:28 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Can we remove these checks from the peers and move them to >> TextComponent.setText()? > > I see. Could you review the updated fix? > The empty text check is removed from the LWTextAreaPeer an > XTextAreaPeer and moved to the TextComponent. > > webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.01/ > > Thanks, > Alexandr. > >> >> 20.07.2012 17:05, Alexander Scherbatiy wrote: >>> >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184365 >>> webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.00/ >>> >>> >>> The failed test expects that TextListener is not invoked after >>> changing empty text to empty for the TextArea >>> and is invoked for the TextField. >>> >>> After switching the EDIT control to RICHEDIT on windows for the >>> TextField the TextListener listener is not invoked for both >>> TextField and TextArea in this case. >>> >>> To be consistent with other platforms the fix: >>> - Moves the checking for new empty text from the LWTextAreaPeer to >>> LWTextComponentPeer on Mac OS X >>> - Adds the empty text checking to the XTextFieldPeer (the >>> XTextAreaPeer class has already has one) on Linux >>> >>> Thanks, >>> Alexandr. >>> >> >> > -- Best regards, Sergey. From oleg.pekhovskiy at oracle.com Tue Jul 24 06:32:52 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Tue, 24 Jul 2012 17:32:52 +0400 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: References: <500D6F03.9000708@oracle.com> Message-ID: <500EA404.705@oracle.com> Hi Peter, so obvious, thank you! Oleg. 7/24/2012 3:42 PM, Peter Levart wrote: > Hi Oleg, > > This is just cosmetics, but: > > SunToolkit: > public synchronized boolean noEvents() { > return queueHead == null && !isFlushing; > } > > ... a thread calling noEvents could see occasional "spikes" of false > return even though there is no flushing being performed (when other > thread is calling flush on an empty PostEventQueue). > > Improved flush method would look like this: > > public void flush() { > EventQueueItem tempQueue; > synchronized (this) { > tempQueue = queueHead; > queueHead = queueTail = null; > isFlushing =*/(tempQueue != null)/*; > } > try { > while (tempQueue != null) { > eventQueue.postEvent(tempQueue.event); > tempQueue = tempQueue.next; > } > } > finally { > isFlushing = false; > } > } > > Regards, Peter > > 2012/7/23 Oleg Pekhovskiy > > > Hi! > > Please review this back-port being already pushed to jdk8 but > deferred for 7u6. > > Bug: > http://bugs.sun.com/view_bug.do?bug_id=7177040 > > Webrev: > http://cr.openjdk.java.net/~bagiras/7u8/7177040.1 > > > Review thread for 7u6: > http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003106.html > > Reviewers 7u6 & 8: > Anthony Petrov, Anton Tarasov > > Thanks, > Oleg > > From peter.levart at gmail.com Tue Jul 24 07:32:13 2012 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 24 Jul 2012 16:32:13 +0200 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <500EA404.705@oracle.com> References: <500D6F03.9000708@oracle.com> <500EA404.705@oracle.com> Message-ID: Ok, now to get rid of flushLock in SunToolkit so that flushPendingEvents is written as plain: public static void flushPendingEvents() { AppContext appContext = AppContext.getAppContext(); PostEventQueue postEventQueue = (PostEventQueue)appContext.get(POST_EVENT_QUEUE_KEY); if (postEventQueue != null) { postEventQueue.flush(); } } ... you could merge the recursion prevention functionality into the PostEventQueue in a manner similar to this: class PostEventQueue { private EventQueueItem queueHead = null; private EventQueueItem queueTail = null; private final EventQueue eventQueue; // For the recursion prevention and noEvents() status private Thread flushingThread = null; PostEventQueue(EventQueue eq) { eventQueue = eq; } public synchronized boolean noEvents() { return queueHead == null && flushingThread == null; } public void flush() { EventQueueItem tempQueue; synchronized (this) { while (flushingThread != null && flushingThread != Thread.currentThread()) try { wait(); } catch (InterruptedException e) { // what can we do? Thread.currentThread().interrupt(); return; } // prevent recursion if (flushingThread == Thread.currentThread()) return; tempQueue = queueHead; queueHead = queueTail = null; // queue was empty if (tempQueue == null) return; flushingThread = Thread.currentThread(); notify(); } try { while (tempQueue != null) { eventQueue.postEvent(tempQueue.event); tempQueue = tempQueue.next; } } finally { synchronized (this) { flushingThread = null; notify(); } } } /* * Enqueue an AWTEvent to be posted to the Java EventQueue. */ void postEvent(AWTEvent event) { EventQueueItem item = new EventQueueItem(event); synchronized (this) { if (queueHead == null) { queueHead = queueTail = item; } else { queueTail.next = item; queueTail = item; } } SunToolkit.wakeupEventQueue(eventQueue, event.getSource() == AWTAutoShutdown.getInstance()); } } // class PostEventQueue What do you think? Regards, Peter 2012/7/24 Oleg Pekhovskiy > Hi Peter, > > so obvious, thank you! > > Oleg. > > > 7/24/2012 3:42 PM, Peter Levart wrote: > >> Hi Oleg, >> >> This is just cosmetics, but: >> >> SunToolkit: >> public synchronized boolean noEvents() { >> return queueHead == null && !isFlushing; >> } >> >> ... a thread calling noEvents could see occasional "spikes" of false >> return even though there is no flushing being performed (when other thread >> is calling flush on an empty PostEventQueue). >> >> Improved flush method would look like this: >> >> public void flush() { >> EventQueueItem tempQueue; >> synchronized (this) { >> tempQueue = queueHead; >> queueHead = queueTail = null; >> isFlushing =*/(tempQueue != null)/*; >> >> } >> try { >> while (tempQueue != null) { >> eventQueue.postEvent(**tempQueue.event); >> tempQueue = tempQueue.next; >> } >> } >> finally { >> isFlushing = false; >> } >> } >> >> Regards, Peter >> >> 2012/7/23 Oleg Pekhovskiy > oleg.pekhovskiy@**oracle.com >> >> >> >> Hi! >> >> Please review this back-port being already pushed to jdk8 but >> deferred for 7u6. >> >> Bug: >> http://bugs.sun.com/view_bug.**do?bug_id=7177040 >> >> Webrev: >> http://cr.openjdk.java.net/~**bagiras/7u8/7177040.1 >> >> > >> >> >> Review thread for 7u6: >> http://mail.openjdk.java.net/**pipermail/awt-dev/2012-July/** >> 003106.html >> >> Reviewers 7u6 & 8: >> Anthony Petrov, Anton Tarasov >> >> Thanks, >> Oleg >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120724/335cc090/attachment.html From peter.levart at gmail.com Tue Jul 24 07:53:55 2012 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 24 Jul 2012 16:53:55 +0200 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: References: <500D6F03.9000708@oracle.com> <500EA404.705@oracle.com> Message-ID: Hi Oleg, Here's even better flush() method. It completes the flush even if interrupted while waiting and then sets the interrupted status just before exit... public void flush() { boolean interrupted = false; try { EventQueueItem tempQueue; synchronized (this) { while (flushingThread != null && flushingThread != Thread.currentThread()) { try { wait(); } catch (InterruptedException e) { interrupted = true; } } // prevent recursion if (flushingThread == Thread.currentThread()) return; tempQueue = queueHead; queueHead = queueTail = null; // queue was empty if (tempQueue == null) return; flushingThread = Thread.currentThread(); notify(); } try { while (tempQueue != null) { eventQueue.postEvent(tempQueue.event); tempQueue = tempQueue.next; } } finally { synchronized (this) { flushingThread = null; notify(); } } } finally { if (interrupted) Thread.currentThread().interrupt(); } } Regards, Peter 2012/7/24 Peter Levart > Ok, now to get rid of flushLock in SunToolkit so that flushPendingEvents > is written as plain: > > public static void flushPendingEvents() { > AppContext appContext = AppContext.getAppContext(); > PostEventQueue postEventQueue = > (PostEventQueue)appContext.get(POST_EVENT_QUEUE_KEY); > if (postEventQueue != null) { > postEventQueue.flush(); > } > } > > ... you could merge the recursion prevention functionality into the > PostEventQueue in a manner similar to this: > > class PostEventQueue { > private EventQueueItem queueHead = null; > private EventQueueItem queueTail = null; > private final EventQueue eventQueue; > > // For the recursion prevention and noEvents() status > private Thread flushingThread = null; > > PostEventQueue(EventQueue eq) { > eventQueue = eq; > } > > public synchronized boolean noEvents() { > return queueHead == null && flushingThread == null; > } > > public void flush() { > EventQueueItem tempQueue; > synchronized (this) { > while (flushingThread != null && flushingThread != > Thread.currentThread()) try { > wait(); > } > catch (InterruptedException e) { // what can we do? > Thread.currentThread().interrupt(); > return; > } > > // prevent recursion > if (flushingThread == Thread.currentThread()) return; > > tempQueue = queueHead; > queueHead = queueTail = null; > > // queue was empty > if (tempQueue == null) return; > > flushingThread = Thread.currentThread(); > notify(); > } > try { > while (tempQueue != null) { > eventQueue.postEvent(tempQueue.event); > tempQueue = tempQueue.next; > } > } > finally { > synchronized (this) { > flushingThread = null; > notify(); > } > } > } > > /* > * Enqueue an AWTEvent to be posted to the Java EventQueue. > */ > void postEvent(AWTEvent event) { > EventQueueItem item = new EventQueueItem(event); > > synchronized (this) { > if (queueHead == null) { > queueHead = queueTail = item; > } else { > queueTail.next = item; > queueTail = item; > } > } > SunToolkit.wakeupEventQueue(eventQueue, event.getSource() == > AWTAutoShutdown.getInstance()); > } > } // class PostEventQueue > > > What do you think? > > Regards, Peter > > > 2012/7/24 Oleg Pekhovskiy > >> Hi Peter, >> >> so obvious, thank you! >> >> Oleg. >> >> >> 7/24/2012 3:42 PM, Peter Levart wrote: >> >>> Hi Oleg, >>> >>> This is just cosmetics, but: >>> >>> SunToolkit: >>> public synchronized boolean noEvents() { >>> return queueHead == null && !isFlushing; >>> } >>> >>> ... a thread calling noEvents could see occasional "spikes" of false >>> return even though there is no flushing being performed (when other thread >>> is calling flush on an empty PostEventQueue). >>> >>> Improved flush method would look like this: >>> >>> public void flush() { >>> EventQueueItem tempQueue; >>> synchronized (this) { >>> tempQueue = queueHead; >>> queueHead = queueTail = null; >>> isFlushing =*/(tempQueue != null)/*; >>> >>> } >>> try { >>> while (tempQueue != null) { >>> eventQueue.postEvent(**tempQueue.event); >>> tempQueue = tempQueue.next; >>> } >>> } >>> finally { >>> isFlushing = false; >>> } >>> } >>> >>> Regards, Peter >>> >>> 2012/7/23 Oleg Pekhovskiy >> oleg.pekhovskiy@**oracle.com >> >>> >>> >>> Hi! >>> >>> Please review this back-port being already pushed to jdk8 but >>> deferred for 7u6. >>> >>> Bug: >>> http://bugs.sun.com/view_bug.**do?bug_id=7177040 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~**bagiras/7u8/7177040.1 >>> >>> > >>> >>> >>> Review thread for 7u6: >>> http://mail.openjdk.java.net/**pipermail/awt-dev/2012-July/** >>> 003106.html >>> >>> Reviewers 7u6 & 8: >>> Anthony Petrov, Anton Tarasov >>> >>> Thanks, >>> Oleg >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120724/3680914e/attachment.html From artem.ananiev at oracle.com Tue Jul 24 08:03:57 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 24 Jul 2012 19:03:57 +0400 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: References: <500D6F03.9000708@oracle.com> <500EA404.705@oracle.com> Message-ID: <500EB95D.4090004@oracle.com> Hi, Peter, 7177040 is about deadlock between EventQueue and PostEventQueue, it's not considered to simplify SunToolkit.flushPendingEvents(). Please, expect flushLock changes in JDK8 as a part of the fix for 7186109. Thanks, Artem On 7/24/2012 6:32 PM, Peter Levart wrote: > Ok, now to get rid of flushLock in SunToolkit so that flushPendingEvents > is written as plain: > > public static void flushPendingEvents() { > AppContext appContext = AppContext.getAppContext(); > PostEventQueue postEventQueue = > (PostEventQueue)appContext.get(POST_EVENT_QUEUE_KEY); > if (postEventQueue != null) { > postEventQueue.flush(); > } > } > > ... you could merge the recursion prevention functionality into the > PostEventQueue in a manner similar to this: > > class PostEventQueue { > private EventQueueItem queueHead = null; > private EventQueueItem queueTail = null; > private final EventQueue eventQueue; > > // For the recursion prevention and noEvents() status > private Thread flushingThread = null; > > PostEventQueue(EventQueue eq) { > eventQueue = eq; > } > > public synchronized boolean noEvents() { > return queueHead == null && flushingThread == null; > } > > public void flush() { > EventQueueItem tempQueue; > synchronized (this) { > while (flushingThread != null && flushingThread != > Thread.currentThread()) try { > wait(); > } > catch (InterruptedException e) { // what can we do? > Thread.currentThread().interrupt(); > return; > } > > // prevent recursion > if (flushingThread == Thread.currentThread()) return; > > tempQueue = queueHead; > queueHead = queueTail = null; > > // queue was empty > if (tempQueue == null) return; > > flushingThread = Thread.currentThread(); > notify(); > } > try { > while (tempQueue != null) { > eventQueue.postEvent(tempQueue.event); > tempQueue = tempQueue.next; > } > } > finally { > synchronized (this) { > flushingThread = null; > notify(); > } > } > } > > /* > * Enqueue an AWTEvent to be posted to the Java EventQueue. > */ > void postEvent(AWTEvent event) { > EventQueueItem item = new EventQueueItem(event); > > synchronized (this) { > if (queueHead == null) { > queueHead = queueTail = item; > } else { > queueTail.next = item; > queueTail = item; > } > } > SunToolkit.wakeupEventQueue(eventQueue, event.getSource() == > AWTAutoShutdown.getInstance()); > } > } // class PostEventQueue > > > What do you think? > > Regards, Peter > > > 2012/7/24 Oleg Pekhovskiy > > > Hi Peter, > > so obvious, thank you! > > Oleg. > > > 7/24/2012 3:42 PM, Peter Levart wrote: > > Hi Oleg, > > This is just cosmetics, but: > > SunToolkit: > public synchronized boolean noEvents() { > return queueHead == null && !isFlushing; > } > > ... a thread calling noEvents could see occasional "spikes" of > false return even though there is no flushing being performed > (when other thread is calling flush on an empty PostEventQueue). > > Improved flush method would look like this: > > public void flush() { > EventQueueItem tempQueue; > synchronized (this) { > tempQueue = queueHead; > queueHead = queueTail = null; > isFlushing =*/(tempQueue != null)/*; > > } > try { > while (tempQueue != null) { > eventQueue.postEvent(__tempQueue.event); > tempQueue = tempQueue.next; > } > } > finally { > isFlushing = false; > } > } > > Regards, Peter > > 2012/7/23 Oleg Pekhovskiy > >> > > > Hi! > > Please review this back-port being already pushed to jdk8 but > deferred for 7u6. > > Bug: > http://bugs.sun.com/view_bug.__do?bug_id=7177040 > > > Webrev: > http://cr.openjdk.java.net/~__bagiras/7u8/7177040.1 > > > > > > Review thread for 7u6: > http://mail.openjdk.java.net/__pipermail/awt-dev/2012-July/__003106.html > > > Reviewers 7u6 & 8: > Anthony Petrov, Anton Tarasov > > Thanks, > Oleg > > > > From denis.fokin at oracle.com Tue Jul 24 08:18:30 2012 From: denis.fokin at oracle.com (Denis S. Fokin) Date: Tue, 24 Jul 2012 19:18:30 +0400 Subject: [8] Review request for 7149068 java/awt/Window/Grab/GrabTest.java failed Message-ID: <500EBCC6.7040209@oracle.com> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149068 webrev: http://cr.openjdk.java.net/~denis/7149068/webrev There are a timing issue and a problem with usage of Util.clickOnTitle() method. It is specified in the comments for the method that windows should have enough width. The test was introduced in jdk7u and it is absent in the jdk8 forest, so the webrev contains no diffs only a new version of the test. I have run the test with Jtreg suite. The test passes. Thank you, Denis. From peter.levart at gmail.com Tue Jul 24 08:19:56 2012 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 24 Jul 2012 17:19:56 +0200 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <500EB95D.4090004@oracle.com> References: <500D6F03.9000708@oracle.com> <500EA404.705@oracle.com> <500EB95D.4090004@oracle.com> Message-ID: Ok, JDK8 then. But what do you think about the proposed way to simplify SunToolkit.flushPendingEvents(**)? Do you think it's wise to merge the recursion prevention with synchronization in PostEventQueue so that SunToolkit static methods are just a facade? Regards, Peter 2012/7/24 Artem Ananiev > Hi, Peter, > > 7177040 is about deadlock between EventQueue and PostEventQueue, it's not > considered to simplify SunToolkit.flushPendingEvents(**). Please, expect > flushLock changes in JDK8 as a part of the fix for 7186109. > > Thanks, > > Artem > > > On 7/24/2012 6:32 PM, Peter Levart wrote: > >> Ok, now to get rid of flushLock in SunToolkit so that flushPendingEvents >> is written as plain: >> >> public static void flushPendingEvents() { >> AppContext appContext = AppContext.getAppContext(); >> PostEventQueue postEventQueue = >> (PostEventQueue)appContext.**get(POST_EVENT_QUEUE_KEY); >> if (postEventQueue != null) { >> postEventQueue.flush(); >> } >> } >> >> ... you could merge the recursion prevention functionality into the >> PostEventQueue in a manner similar to this: >> >> class PostEventQueue { >> private EventQueueItem queueHead = null; >> private EventQueueItem queueTail = null; >> private final EventQueue eventQueue; >> >> // For the recursion prevention and noEvents() status >> private Thread flushingThread = null; >> >> PostEventQueue(EventQueue eq) { >> eventQueue = eq; >> } >> >> public synchronized boolean noEvents() { >> return queueHead == null && flushingThread == null; >> } >> >> public void flush() { >> EventQueueItem tempQueue; >> synchronized (this) { >> while (flushingThread != null && flushingThread != >> Thread.currentThread()) try { >> wait(); >> } >> catch (InterruptedException e) { // what can we do? >> Thread.currentThread().**interrupt(); >> return; >> } >> >> // prevent recursion >> if (flushingThread == Thread.currentThread()) return; >> >> tempQueue = queueHead; >> queueHead = queueTail = null; >> >> // queue was empty >> if (tempQueue == null) return; >> >> flushingThread = Thread.currentThread(); >> notify(); >> } >> try { >> while (tempQueue != null) { >> eventQueue.postEvent(**tempQueue.event); >> tempQueue = tempQueue.next; >> } >> } >> finally { >> synchronized (this) { >> flushingThread = null; >> notify(); >> } >> } >> } >> >> /* >> * Enqueue an AWTEvent to be posted to the Java EventQueue. >> */ >> void postEvent(AWTEvent event) { >> EventQueueItem item = new EventQueueItem(event); >> >> synchronized (this) { >> if (queueHead == null) { >> queueHead = queueTail = item; >> } else { >> queueTail.next = item; >> queueTail = item; >> } >> } >> SunToolkit.wakeupEventQueue(**eventQueue, event.getSource() == >> AWTAutoShutdown.getInstance())**; >> } >> } // class PostEventQueue >> >> >> What do you think? >> >> Regards, Peter >> >> >> 2012/7/24 Oleg Pekhovskiy > >> >> >> >> Hi Peter, >> >> so obvious, thank you! >> >> Oleg. >> >> >> 7/24/2012 3:42 PM, Peter Levart wrote: >> >> Hi Oleg, >> >> This is just cosmetics, but: >> >> SunToolkit: >> public synchronized boolean noEvents() { >> return queueHead == null && !isFlushing; >> } >> >> ... a thread calling noEvents could see occasional "spikes" of >> false return even though there is no flushing being performed >> (when other thread is calling flush on an empty PostEventQueue). >> >> Improved flush method would look like this: >> >> public void flush() { >> EventQueueItem tempQueue; >> synchronized (this) { >> tempQueue = queueHead; >> queueHead = queueTail = null; >> isFlushing =*/(tempQueue != null)/*; >> >> } >> try { >> while (tempQueue != null) { >> eventQueue.postEvent(__**tempQueue.event); >> >> tempQueue = tempQueue.next; >> } >> } >> finally { >> isFlushing = false; >> } >> } >> >> Regards, Peter >> >> 2012/7/23 Oleg Pekhovskiy > >> > >> >> >> >> >>> >> >> >> Hi! >> >> Please review this back-port being already pushed to jdk8 but >> deferred for 7u6. >> >> Bug: >> http://bugs.sun.com/view_bug._**_do?bug_id=7177040 >> >> > >> >> Webrev: >> http://cr.openjdk.java.net/~__**bagiras/7u8/7177040.1 >> >> > >> > >> >> >> >> >> >> Review thread for 7u6: >> http://mail.openjdk.java.net/_**_pipermail/awt-dev/2012-July/_** >> _003106.html >> >> > 003106.html >> > >> >> Reviewers 7u6 & 8: >> Anthony Petrov, Anton Tarasov >> >> Thanks, >> Oleg >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120724/bc2b1519/attachment.html From omajid at redhat.com Tue Jul 24 09:44:06 2012 From: omajid at redhat.com (Omair Majid) Date: Tue, 24 Jul 2012 12:44:06 -0400 Subject: JAWT Breakage in OpenJDK 7/8 Message-ID: <500ED0D6.2080908@redhat.com> Hi, I recently discovered that a number of applications making use of JAWT [1] are broken on OpenJDK 7 and 8, while they were working with OpenJDK6. The docs for JAWT state [1]: """ The final step ? the most interesting one ? is to write the native rendering method, with an interface that conforms to the header file that javah generated, and build it as a standard shared library (called myRenderingLib in the above example) by linking it, for the Solaris operating environment, against the jre/lib/sparc/libjawt.so library. """ In other words, JAWT expects third-party native libraries to be linked against libjawt.so. However, nowhere on that page does it say that something like System.loadLibrary("jawt") is needed. In practice, this means that most existing applications rely on libjawt.so being magically found and loaded by the JVM. In OpenJDK6, LD_LIBRARY_PATH was set to a value such that the linker could resolve libjawt.so when a library depending on it was loaded. LD_LIBRARY_PATH was removed for OpenJDK7 [2]. So a number of existing applications fail to work with OpenJDK7 because they can not load libjawt.so. Some applications have been patched to load libjawt.so manually [3], but others haven't (or cant be). The most backwards-compatible fix is to undo the effects of the LD_LIBRARY_PATH change - by setting RUNPATH of the launcher, for example. The build-dev folks suggested that I only do that as a last resort [4]. An alternate fix seems to be to always load libjawt when awt starts up. There might be a small window of time where a third-party library fails to link against libjawt.so but this can happen only if awt has not started up. I would think such a case would not work with OpenJDK6 too since libjawt.so will not be able to resolve the dependency on libxawt.so. libxawt.so is only loaded after awt is started up, and can not be resolved through LD_LIBRARY_PATH. The attached patches for OpenJDK8 and OpenJDK7 attempt this approach. Does anyone have any thoughts or comments? I suspect something like this might be needed for Windows too, but I don't have access to a windows box to verify it. As an aside, should the docs for JAWT [1] be updated? Thanks, Omair [1] http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html [2] https://blogs.oracle.com/darcy/entry/purging_ld_library_path [3] http://java-game-lib.svn.sourceforge.net/viewvc/java-game-lib/trunk/LWJGL/src/java/org/lwjgl/LinuxSysImplementation.java?r1=3418&r2=3604 [4] http://mail.openjdk.java.net/pipermail/build-dev/2012-July/006492.html -------------- next part -------------- A non-text attachment was scrubbed... Name: jawt-jdk7-01.patch Type: text/x-patch Size: 769 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120724/a2509337/jawt-jdk7-01.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: jawt-jdk8-01.patch Type: text/x-patch Size: 608 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120724/a2509337/jawt-jdk8-01.patch From tim_english at hotmail.com Tue Jul 24 14:31:36 2012 From: tim_english at hotmail.com (Tim English) Date: Tue, 24 Jul 2012 16:31:36 -0500 Subject: 7171412: awt Choice doesn't fire ItemStateChange when selecting item after select() call Message-ID: 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/20120724/39b67d27/attachment.html From artem.ananiev at oracle.com Wed Jul 25 02:33:45 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 25 Jul 2012 13:33:45 +0400 Subject: JAWT Breakage in OpenJDK 7/8 In-Reply-To: <500ED0D6.2080908@redhat.com> References: <500ED0D6.2080908@redhat.com> Message-ID: <500FBD79.5050601@oracle.com> 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. That's why I vote for just updating JAWT documentation to include System.loadLibrary() call in the application code. Thanks, Artem On 7/24/2012 8:44 PM, Omair Majid wrote: > Hi, > > I recently discovered that a number of applications making use of JAWT > [1] are broken on OpenJDK 7 and 8, while they were working with OpenJDK6. > > The docs for JAWT state [1]: > """ > The final step ? the most interesting one ? is to write the native > rendering method, with an interface that conforms to the header file > that javah generated, and build it as a standard shared library (called > myRenderingLib in the above example) by linking it, for the Solaris > operating environment, against the jre/lib/sparc/libjawt.so library. > """ > > In other words, JAWT expects third-party native libraries to be linked > against libjawt.so. However, nowhere on that page does it say that > something like System.loadLibrary("jawt") is needed. In practice, this > means that most existing applications rely on libjawt.so being magically > found and loaded by the JVM. In OpenJDK6, LD_LIBRARY_PATH was set to a > value such that the linker could resolve libjawt.so when a library > depending on it was loaded. LD_LIBRARY_PATH was removed for OpenJDK7 > [2]. So a number of existing applications fail to work with OpenJDK7 > because they can not load libjawt.so. Some applications have been > patched to load libjawt.so manually [3], but others haven't (or cant be). > > The most backwards-compatible fix is to undo the effects of the > LD_LIBRARY_PATH change - by setting RUNPATH of the launcher, for > example. The build-dev folks suggested that I only do that as a last > resort [4]. > > An alternate fix seems to be to always load libjawt when awt starts up. > There might be a small window of time where a third-party library fails > to link against libjawt.so but this can happen only if awt has not > started up. I would think such a case would not work with OpenJDK6 too > since libjawt.so will not be able to resolve the dependency on > libxawt.so. libxawt.so is only loaded after awt is started up, and can > not be resolved through LD_LIBRARY_PATH. > > The attached patches for OpenJDK8 and OpenJDK7 attempt this approach. > Does anyone have any thoughts or comments? > > I suspect something like this might be needed for Windows too, but I > don't have access to a windows box to verify it. > > As an aside, should the docs for JAWT [1] be updated? > > Thanks, > Omair > > [1] > http://download.java.net/jdk8/docs/technotes/guides/awt/AWT_Native_Interface.html > [2] https://blogs.oracle.com/darcy/entry/purging_ld_library_path > [3] > http://java-game-lib.svn.sourceforge.net/viewvc/java-game-lib/trunk/LWJGL/src/java/org/lwjgl/LinuxSysImplementation.java?r1=3418&r2=3604 > [4] http://mail.openjdk.java.net/pipermail/build-dev/2012-July/006492.html From pavel.porvatov at oracle.com Wed Jul 25 02:45:04 2012 From: pavel.porvatov at oracle.com (pavel.porvatov at oracle.com) Date: Wed, 25 Jul 2012 09:45:04 +0000 Subject: hg: jdk8/awt/jdk: 7167780: Hang javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests Message-ID: <20120725094622.C382F471F4@hg.openjdk.java.net> Changeset: 3502753a9d66 Author: rupashka Date: 2012-07-25 13:41 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3502753a9d66 7167780: Hang javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests Reviewed-by: alexsch ! src/share/classes/javax/swing/TimerQueue.java From alexandr.scherbatiy at oracle.com Wed Jul 25 07:50:46 2012 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 25 Jul 2012 18:50:46 +0400 Subject: [8] Review request for 7184365 closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails In-Reply-To: <500E95E6.5010901@oracle.com> References: <500957AD.4010604@oracle.com> <50095D0D.4070009@oracle.com> <500E9257.6060806@oracle.com> <500E95E6.5010901@oracle.com> Message-ID: <501007C6.4060308@oracle.com> On 7/24/2012 4:32 PM, Sergey Bylokhov wrote: > Hi, Alexander. > A few comments: > - LWTextComponentPeer.setText can be final now. > - Behavior of TextComponent.setText(null) && getText() were changed > for null values if peer does not exists. Could you review the updated version where the problems listed above are fixed: webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.02/ Thanks, Alexandr. > > 24.07.2012 16:17, Alexander Scherbatiy wrote: >> On 7/20/2012 5:28 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> Can we remove these checks from the peers and move them to >>> TextComponent.setText()? >> >> I see. Could you review the updated fix? >> The empty text check is removed from the LWTextAreaPeer an >> XTextAreaPeer and moved to the TextComponent. >> >> webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.01/ >> >> Thanks, >> Alexandr. >> >>> >>> 20.07.2012 17:05, Alexander Scherbatiy wrote: >>>> >>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184365 >>>> webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.00/ >>>> >>>> >>>> The failed test expects that TextListener is not invoked after >>>> changing empty text to empty for the TextArea >>>> and is invoked for the TextField. >>>> >>>> After switching the EDIT control to RICHEDIT on windows for the >>>> TextField the TextListener listener is not invoked for both >>>> TextField and TextArea in this case. >>>> >>>> To be consistent with other platforms the fix: >>>> - Moves the checking for new empty text from the LWTextAreaPeer to >>>> LWTextComponentPeer on Mac OS X >>>> - Adds the empty text checking to the XTextFieldPeer (the >>>> XTextAreaPeer class has already has one) on Linux >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >>> >> > > From sergey.malenkov at oracle.com Wed Jul 25 08:17:35 2012 From: sergey.malenkov at oracle.com (sergey.malenkov at oracle.com) Date: Wed, 25 Jul 2012 15:17:35 +0000 Subject: hg: jdk8/awt/jdk: 4650871: Classes in sunw.* should be removed from workspace and rt.jar Message-ID: <20120725151752.E0079471F7@hg.openjdk.java.net> Changeset: 1a410846d85b Author: malenkov Date: 2012-07-25 19:14 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1a410846d85b 4650871: Classes in sunw.* should be removed from workspace and rt.jar Reviewed-by: art, rupashka ! make/Makefile ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk - make/sunw/Makefile ! makefiles/CreateJars.gmk ! makefiles/docs/CORE_PKGS.gmk ! src/share/classes/sun/misc/MetaIndex.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java From omajid at redhat.com Wed Jul 25 07:40:52 2012 From: omajid at redhat.com (Omair Majid) Date: Wed, 25 Jul 2012 10:40:52 -0400 Subject: JAWT Breakage in OpenJDK 7/8 In-Reply-To: <500FBD79.5050601@oracle.com> References: <500ED0D6.2080908@redhat.com> <500FBD79.5050601@oracle.com> Message-ID: <50100574.9020607@redhat.com> 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. > 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 :( Thanks, Omair From david.holmes at oracle.com Thu Jul 26 05:08:56 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Jul 2012 22:08:56 +1000 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: References: <500D6F03.9000708@oracle.com> Message-ID: <50113358.7080305@oracle.com> This fix still makes me uncomfortable because flush() is not thread-safe any more. If two threads can flush() then the first can clear the isFlushing state (in the finally block) that has been set by the second (in the synchronized block). David On 24/07/2012 9:42 PM, Peter Levart wrote: > Hi Oleg, > > This is just cosmetics, but: > > SunToolkit: > public synchronized boolean noEvents() { > return queueHead == null && !isFlushing; > } > > ... a thread calling noEvents could see occasional "spikes" of false > return even though there is no flushing being performed (when other > thread is calling flush on an empty PostEventQueue). > > Improved flush method would look like this: > > public void flush() { > EventQueueItem tempQueue; > synchronized (this) { > tempQueue = queueHead; > queueHead = queueTail = null; > isFlushing =*/(tempQueue != null)/*; > > } > try { > while (tempQueue != null) { > eventQueue.postEvent(tempQueue.event); > tempQueue = tempQueue.next; > } > } > finally { > isFlushing = false; > } > } > > > Regards, Peter > > 2012/7/23 Oleg Pekhovskiy > > > Hi! > > Please review this back-port being already pushed to jdk8 but > deferred for 7u6. > > Bug: > http://bugs.sun.com/view_bug.__do?bug_id=7177040 > > > Webrev: > http://cr.openjdk.java.net/~__bagiras/7u8/7177040.1 > > > Review thread for 7u6: > http://mail.openjdk.java.net/__pipermail/awt-dev/2012-July/__003106.html > > > Reviewers 7u6 & 8: > Anthony Petrov, Anton Tarasov > > Thanks, > Oleg > > From leonid.romanov at oracle.com Thu Jul 26 06:24:22 2012 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Thu, 26 Jul 2012 17:24:22 +0400 Subject: [8] Review request for 7159381: [macosx] Dock Icon defaults to Generic Java Application Category Message-ID: <70556E1E-06E7-4D9D-A8AA-11BE1A78DA41@oracle.com> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20120726/b8908be9/attachment.html From oleg.pekhovskiy at oracle.com Thu Jul 26 06:59:47 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 26 Jul 2012 17:59:47 +0400 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <50113358.7080305@oracle.com> References: <500D6F03.9000708@oracle.com> <50113358.7080305@oracle.com> Message-ID: <50114D53.4030001@oracle.com> Hi David, it's thread-safe indirectly. SunToolkit.flushPendingEvents() & SunToolkitSubclass.flushPendingEvents() are the only methods that call PostEventQueue.flush(). They both have flushLock synchronization object that guarantees synchronized call of PostEventQueue.flush(). Thanks, Oleg 7/26/2012 4:08 PM, David Holmes wrote: > This fix still makes me uncomfortable because flush() is not > thread-safe any more. If two threads can flush() then the first can > clear the isFlushing state (in the finally block) that has been set by > the second (in the synchronized block). > > David > > On 24/07/2012 9:42 PM, Peter Levart wrote: >> Hi Oleg, >> >> This is just cosmetics, but: >> >> SunToolkit: >> public synchronized boolean noEvents() { >> return queueHead == null && !isFlushing; >> } >> >> ... a thread calling noEvents could see occasional "spikes" of false >> return even though there is no flushing being performed (when other >> thread is calling flush on an empty PostEventQueue). >> >> Improved flush method would look like this: >> >> public void flush() { >> EventQueueItem tempQueue; >> synchronized (this) { >> tempQueue = queueHead; >> queueHead = queueTail = null; >> isFlushing =*/(tempQueue != null)/*; >> >> } >> try { >> while (tempQueue != null) { >> eventQueue.postEvent(tempQueue.event); >> tempQueue = tempQueue.next; >> } >> } >> finally { >> isFlushing = false; >> } >> } >> >> >> Regards, Peter >> >> 2012/7/23 Oleg Pekhovskiy > > >> >> Hi! >> >> Please review this back-port being already pushed to jdk8 but >> deferred for 7u6. >> >> Bug: >> http://bugs.sun.com/view_bug.__do?bug_id=7177040 >> >> >> Webrev: >> http://cr.openjdk.java.net/~__bagiras/7u8/7177040.1 >> >> >> Review thread for 7u6: >> >> http://mail.openjdk.java.net/__pipermail/awt-dev/2012-July/__003106.html >> >> >> Reviewers 7u6 & 8: >> Anthony Petrov, Anton Tarasov >> >> Thanks, >> Oleg >> >> From oleg.pekhovskiy at oracle.com Thu Jul 26 07:02:36 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Thu, 26 Jul 2012 18:02:36 +0400 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <50113358.7080305@oracle.com> References: <500D6F03.9000708@oracle.com> <50113358.7080305@oracle.com> Message-ID: <50114DFC.3090408@oracle.com> Hi David, it's thread-safe indirectly. SunToolkit.flushPendingEvents() & SunToolkitSubclass.flushPendingEvents() are the only methods that call PostEventQueue.flush(). They both have flushLock synchronization object that guarantees synchronized call of PostEventQueue.flush(). Thanks, Oleg 7/26/2012 4:08 PM, David Holmes wrote: > This fix still makes me uncomfortable because flush() is not > thread-safe any more. If two threads can flush() then the first can > clear the isFlushing state (in the finally block) that has been set by > the second (in the synchronized block). > > David > > On 24/07/2012 9:42 PM, Peter Levart wrote: >> Hi Oleg, >> >> This is just cosmetics, but: >> >> SunToolkit: >> public synchronized boolean noEvents() { >> return queueHead == null && !isFlushing; >> } >> >> ... a thread calling noEvents could see occasional "spikes" of false >> return even though there is no flushing being performed (when other >> thread is calling flush on an empty PostEventQueue). >> >> Improved flush method would look like this: >> >> public void flush() { >> EventQueueItem tempQueue; >> synchronized (this) { >> tempQueue = queueHead; >> queueHead = queueTail = null; >> isFlushing =*/(tempQueue != null)/*; >> >> } >> try { >> while (tempQueue != null) { >> eventQueue.postEvent(tempQueue.event); >> tempQueue = tempQueue.next; >> } >> } >> finally { >> isFlushing = false; >> } >> } >> >> >> Regards, Peter >> >> 2012/7/23 Oleg Pekhovskiy > > >> >> Hi! >> >> Please review this back-port being already pushed to jdk8 but >> deferred for 7u6. >> >> Bug: >> http://bugs.sun.com/view_bug.__do?bug_id=7177040 >> >> >> Webrev: >> http://cr.openjdk.java.net/~__bagiras/7u8/7177040.1 >> >> >> Review thread for 7u6: >> >> http://mail.openjdk.java.net/__pipermail/awt-dev/2012-July/__003106.html >> >> >> Reviewers 7u6 & 8: >> Anthony Petrov, Anton Tarasov >> >> Thanks, >> Oleg >> >> From david.holmes at oracle.com Thu Jul 26 07:21:03 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Jul 2012 00:21:03 +1000 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <50114D53.4030001@oracle.com> References: <500D6F03.9000708@oracle.com> <50113358.7080305@oracle.com> <50114D53.4030001@oracle.com> Message-ID: <5011524F.1010304@oracle.com> On 26/07/2012 11:59 PM, Oleg Pekhovskiy wrote: > it's thread-safe indirectly. SunToolkit.flushPendingEvents() & > SunToolkitSubclass.flushPendingEvents() are the only methods that call > PostEventQueue.flush(). > They both have flushLock synchronization object that guarantees > synchronized call of PostEventQueue.flush(). Yes but it is that undocumented indirection that concerns me. If someone decides to remove those outer locks they may not realize there is a lurking race here. David > Thanks, > Oleg > > 7/26/2012 4:08 PM, David Holmes wrote: >> This fix still makes me uncomfortable because flush() is not >> thread-safe any more. If two threads can flush() then the first can >> clear the isFlushing state (in the finally block) that has been set by >> the second (in the synchronized block). >> >> David >> >> On 24/07/2012 9:42 PM, Peter Levart wrote: >>> Hi Oleg, >>> >>> This is just cosmetics, but: >>> >>> SunToolkit: >>> public synchronized boolean noEvents() { >>> return queueHead == null && !isFlushing; >>> } >>> >>> ... a thread calling noEvents could see occasional "spikes" of false >>> return even though there is no flushing being performed (when other >>> thread is calling flush on an empty PostEventQueue). >>> >>> Improved flush method would look like this: >>> >>> public void flush() { >>> EventQueueItem tempQueue; >>> synchronized (this) { >>> tempQueue = queueHead; >>> queueHead = queueTail = null; >>> isFlushing =*/(tempQueue != null)/*; >>> >>> } >>> try { >>> while (tempQueue != null) { >>> eventQueue.postEvent(tempQueue.event); >>> tempQueue = tempQueue.next; >>> } >>> } >>> finally { >>> isFlushing = false; >>> } >>> } >>> >>> >>> Regards, Peter >>> >>> 2012/7/23 Oleg Pekhovskiy >> > >>> >>> Hi! >>> >>> Please review this back-port being already pushed to jdk8 but >>> deferred for 7u6. >>> >>> Bug: >>> http://bugs.sun.com/view_bug.__do?bug_id=7177040 >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~__bagiras/7u8/7177040.1 >>> >>> >>> Review thread for 7u6: >>> http://mail.openjdk.java.net/__pipermail/awt-dev/2012-July/__003106.html >>> >>> >>> Reviewers 7u6 & 8: >>> Anthony Petrov, Anton Tarasov >>> >>> Thanks, >>> Oleg >>> >>> > From peter.levart at gmail.com Fri Jul 27 01:46:26 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 27 Jul 2012 10:46:26 +0200 Subject: [7u8] Review request for 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater In-Reply-To: <5011524F.1010304@oracle.com> References: <500D6F03.9000708@oracle.com> <50114D53.4030001@oracle.com> <5011524F.1010304@oracle.com> Message-ID: <2120359.9uvSuLZQ6W@cube.localdomain> That's why I thought that fixing 7177040 and 7186109 (the last one by removing flushLock in SunToolkit and moving synchronization/recursion prevention into PostEventQueue) in one go would be worth considering... Regards, Peter On Friday, July 27, 2012 12:21:03 AM David Holmes wrote: > On 26/07/2012 11:59 PM, Oleg Pekhovskiy wrote: > > it's thread-safe indirectly. SunToolkit.flushPendingEvents() & > > SunToolkitSubclass.flushPendingEvents() are the only methods that call > > PostEventQueue.flush(). > > They both have flushLock synchronization object that guarantees > > synchronized call of PostEventQueue.flush(). > > Yes but it is that undocumented indirection that concerns me. If someone > decides to remove those outer locks they may not realize there is a > lurking race here. > > David > > > Thanks, > > Oleg > > > > 7/26/2012 4:08 PM, David Holmes wrote: > >> This fix still makes me uncomfortable because flush() is not > >> thread-safe any more. If two threads can flush() then the first can > >> clear the isFlushing state (in the finally block) that has been set by > >> the second (in the synchronized block). > >> > >> David > >> > >> On 24/07/2012 9:42 PM, Peter Levart wrote: > >>> Hi Oleg, > >>> > >>> This is just cosmetics, but: > >>> > >>> SunToolkit: > >>> public synchronized boolean noEvents() { > >>> return queueHead == null && !isFlushing; > >>> } > >>> > >>> ... a thread calling noEvents could see occasional "spikes" of false > >>> return even though there is no flushing being performed (when other > >>> thread is calling flush on an empty PostEventQueue). > >>> > >>> Improved flush method would look like this: > >>> > >>> public void flush() { > >>> EventQueueItem tempQueue; > >>> synchronized (this) { > >>> tempQueue = queueHead; > >>> queueHead = queueTail = null; > >>> isFlushing =*/(tempQueue != null)/*; > >>> > >>> } > >>> try { > >>> while (tempQueue != null) { > >>> eventQueue.postEvent(tempQueue.event); > >>> tempQueue = tempQueue.next; > >>> } > >>> } > >>> finally { > >>> isFlushing = false; > >>> } > >>> } > >>> > >>> > >>> Regards, Peter > >>> > >>> 2012/7/23 Oleg Pekhovskiy >>> > > >>> > >>> Hi! > >>> > >>> Please review this back-port being already pushed to jdk8 but > >>> deferred for 7u6. > >>> > >>> Bug: > >>> http://bugs.sun.com/view_bug.__do?bug_id=7177040 > >>> > >>> > >>> Webrev: > >>> http://cr.openjdk.java.net/~__bagiras/7u8/7177040.1 > >>> > >>> > >>> Review thread for 7u6: > >>> http://mail.openjdk.java.net/__pipermail/awt-dev/2012-July/__003106.html > >>> > >>> > >>> Reviewers 7u6 & 8: > >>> Anthony Petrov, Anton Tarasov > >>> > >>> Thanks, > >>> Oleg From denis.fokin at oracle.com Fri Jul 27 05:02:48 2012 From: denis.fokin at oracle.com (Denis S. Fokin) Date: Fri, 27 Jul 2012 16:02:48 +0400 Subject: [8] Review request for 7149068 java/awt/Window/Grab/GrabTest.java failed Message-ID: <50128368.4020603@oracle.com> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149068 webrev: http://cr.openjdk.java.net/~denis/7149068/webrev There is a timing issue and a problem with usage of Util.clickOnTitle() method. It is specified in the comments for the method that windows should have enough width. The test was introduced in jdk7u and it is absent in the jdk8 forest, so the webrev contains no diffs only a new version of the test. I have run the test with Jtreg suite. The test passes. Thank you, Denis. From anton.tarasov at oracle.com Fri Jul 27 05:36:56 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 27 Jul 2012 16:36:56 +0400 Subject: [8] Review request for 7149068 java/awt/Window/Grab/GrabTest.java failed In-Reply-To: <50128368.4020603@oracle.com> References: <50128368.4020603@oracle.com> Message-ID: <50128B68.6090309@oracle.com> Looks fine for me. Thanks, Anton. On 27.07.2012 16:02, Denis S. Fokin wrote: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149068 > webrev: http://cr.openjdk.java.net/~denis/7149068/webrev > > There is a timing issue and a problem with usage of Util.clickOnTitle() method. It is specified > in the comments for the method that windows should have enough width. The test was introduced in > jdk7u and it is absent in the jdk8 forest, so the webrev contains no diffs only a new version of > the test. > > I have run the test with Jtreg suite. The test passes. > > Thank you, > Denis. From oleg.pekhovskiy at oracle.com Fri Jul 27 06:20:13 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 27 Jul 2012 17:20:13 +0400 Subject: [8] Review request for 7184365 closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails In-Reply-To: <500E9257.6060806@oracle.com> References: <500957AD.4010604@oracle.com> <50095D0D.4070009@oracle.com> <500E9257.6060806@oracle.com> Message-ID: <5012958D.1050807@oracle.com> Looks fine to me. Thanks, Oleg 7/24/2012 4:17 PM, Alexander Scherbatiy wrote: > On 7/20/2012 5:28 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Can we remove these checks from the peers and move them to >> TextComponent.setText()? > > I see. Could you review the updated fix? > The empty text check is removed from the LWTextAreaPeer an > XTextAreaPeer and moved to the TextComponent. > > webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.01/ > > Thanks, > Alexandr. > >> >> 20.07.2012 17:05, Alexander Scherbatiy wrote: >>> >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184365 >>> webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.00/ >>> >>> >>> The failed test expects that TextListener is not invoked after >>> changing empty text to empty for the TextArea >>> and is invoked for the TextField. >>> >>> After switching the EDIT control to RICHEDIT on windows for the >>> TextField the TextListener listener is not invoked for both >>> TextField and TextArea in this case. >>> >>> To be consistent with other platforms the fix: >>> - Moves the checking for new empty text from the LWTextAreaPeer to >>> LWTextComponentPeer on Mac OS X >>> - Adds the empty text checking to the XTextFieldPeer (the >>> XTextAreaPeer class has already has one) on Linux >>> >>> Thanks, >>> Alexandr. >>> >> >> > From denis.fokin at oracle.com Fri Jul 27 06:37:57 2012 From: denis.fokin at oracle.com (Denis S. Fokin) Date: Fri, 27 Jul 2012 17:37:57 +0400 Subject: [8] Review request for 7149068 java/awt/Window/Grab/GrabTest.java failed In-Reply-To: <50128B68.6090309@oracle.com> References: <50128368.4020603@oracle.com> <50128B68.6090309@oracle.com> Message-ID: <501299B5.7090100@oracle.com> Hi Anton, could you take another look? I have slightly improved the test. http://cr.openjdk.java.net/~denis/7149068/webrev.01/ Instead of setSize() I use setBunds() to be consistent with positioning of other windows. 68 f.setBounds(0, 0, 300, 300); I have also changed this line. Now we are clicking at one pixel below the frame bottom (previously it was 300 pixels below). 178 robot.mouseMove(loc.x + 100, loc.y + f.getSize().height + 1); Thank you, Denis. On 7/27/2012 4:36 PM, Anton V. Tarasov wrote: > Looks fine for me. > > Thanks, > Anton. > > On 27.07.2012 16:02, Denis S. Fokin wrote: >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149068 >> webrev: http://cr.openjdk.java.net/~denis/7149068/webrev >> >> There is a timing issue and a problem with usage of >> Util.clickOnTitle() method. It is specified in the comments for the >> method that windows should have enough width. The test was introduced >> in jdk7u and it is absent in the jdk8 forest, so the webrev contains >> no diffs only a new version of the test. >> >> I have run the test with Jtreg suite. The test passes. >> >> Thank you, >> Denis. > From anton.tarasov at oracle.com Fri Jul 27 07:04:24 2012 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 27 Jul 2012 18:04:24 +0400 Subject: [8] Review request for 7149068 java/awt/Window/Grab/GrabTest.java failed In-Reply-To: <501299B5.7090100@oracle.com> References: <50128368.4020603@oracle.com> <50128B68.6090309@oracle.com> <501299B5.7090100@oracle.com> Message-ID: <50129FE8.3000607@oracle.com> On 27.07.2012 17:37, Denis S. Fokin wrote: > Hi Anton, > could you take another look? > > I have slightly improved the test. > > http://cr.openjdk.java.net/~denis/7149068/webrev.01/ > > Instead of setSize() I use setBunds() to be consistent with positioning of other windows. > > 68 f.setBounds(0, 0, 300, 300); Ok. > > I have also changed this line. Now we are clicking at one pixel below the frame bottom (previously > it was 300 pixels below). > > 178 robot.mouseMove(loc.x + 100, loc.y + f.getSize().height + 1); Ok. Thanks, Anton. > > Thank you, > Denis. > > On 7/27/2012 4:36 PM, Anton V. Tarasov wrote: >> Looks fine for me. >> >> Thanks, >> Anton. >> >> On 27.07.2012 16:02, Denis S. Fokin wrote: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149068 >>> webrev: http://cr.openjdk.java.net/~denis/7149068/webrev >>> >>> There is a timing issue and a problem with usage of >>> Util.clickOnTitle() method. It is specified in the comments for the >>> method that windows should have enough width. The test was introduced >>> in jdk7u and it is absent in the jdk8 forest, so the webrev contains >>> no diffs only a new version of the test. >>> >>> I have run the test with Jtreg suite. The test passes. >>> >>> Thank you, >>> Denis. >> > From Sergey.Bylokhov at oracle.com Fri Jul 27 07:32:39 2012 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 27 Jul 2012 18:32:39 +0400 Subject: [8] Review request for 7184365 closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails In-Reply-To: <501007C6.4060308@oracle.com> References: <500957AD.4010604@oracle.com> <50095D0D.4070009@oracle.com> <500E9257.6060806@oracle.com> <500E95E6.5010901@oracle.com> <501007C6.4060308@oracle.com> Message-ID: <5012A687.4060006@oracle.com> Hi, Alexander. Fix looks good. 25.07.2012 18:50, Alexander Scherbatiy wrote: > On 7/24/2012 4:32 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> A few comments: >> - LWTextComponentPeer.setText can be final now. >> - Behavior of TextComponent.setText(null) && getText() were changed >> for null values if peer does not exists. > > Could you review the updated version where the problems listed > above are fixed: > webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.02/ > > Thanks, > Alexandr. > >> >> 24.07.2012 16:17, Alexander Scherbatiy wrote: >>> On 7/20/2012 5:28 PM, Sergey Bylokhov wrote: >>>> Hi, Alexander. >>>> Can we remove these checks from the peers and move them to >>>> TextComponent.setText()? >>> >>> I see. Could you review the updated fix? >>> The empty text check is removed from the LWTextAreaPeer an >>> XTextAreaPeer and moved to the TextComponent. >>> >>> webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.01/ >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> 20.07.2012 17:05, Alexander Scherbatiy wrote: >>>>> >>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184365 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/7184365/webrev.00/ >>>>> >>>>> >>>>> The failed test expects that TextListener is not invoked after >>>>> changing empty text to empty for the TextArea >>>>> and is invoked for the TextField. >>>>> >>>>> After switching the EDIT control to RICHEDIT on windows for the >>>>> TextField the TextListener listener is not invoked for both >>>>> TextField and TextArea in this case. >>>>> >>>>> To be consistent with other platforms the fix: >>>>> - Moves the checking for new empty text from the LWTextAreaPeer to >>>>> LWTextComponentPeer on Mac OS X >>>>> - Adds the empty text checking to the XTextFieldPeer (the >>>>> XTextAreaPeer class has already has one) on Linux >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From artem.ananiev at oracle.com Fri Jul 27 08:28:30 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 27 Jul 2012 19:28:30 +0400 Subject: [8] Review request for 7149068 java/awt/Window/Grab/GrabTest.java failed In-Reply-To: <501299B5.7090100@oracle.com> References: <50128368.4020603@oracle.com> <50128B68.6090309@oracle.com> <501299B5.7090100@oracle.com> Message-ID: <5012B39E.60102@oracle.com> Looks fine. Thanks, Artem On 7/27/2012 5:37 PM, Denis S. Fokin wrote: > Hi Anton, > could you take another look? > > I have slightly improved the test. > > http://cr.openjdk.java.net/~denis/7149068/webrev.01/ > > Instead of setSize() I use setBunds() to be consistent with positioning > of other windows. > > 68 f.setBounds(0, 0, 300, 300); > > I have also changed this line. Now we are clicking at one pixel below > the frame bottom (previously it was 300 pixels below). > > 178 robot.mouseMove(loc.x + 100, loc.y + f.getSize().height + 1); > > Thank you, > Denis. > > On 7/27/2012 4:36 PM, Anton V. Tarasov wrote: >> Looks fine for me. >> >> Thanks, >> Anton. >> >> On 27.07.2012 16:02, Denis S. Fokin wrote: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149068 >>> webrev: http://cr.openjdk.java.net/~denis/7149068/webrev >>> >>> There is a timing issue and a problem with usage of >>> Util.clickOnTitle() method. It is specified in the comments for the >>> method that windows should have enough width. The test was introduced >>> in jdk7u and it is absent in the jdk8 forest, so the webrev contains >>> no diffs only a new version of the test. >>> >>> I have run the test with Jtreg suite. The test passes. >>> >>> Thank you, >>> Denis. >> > From denis.fokin at oracle.com Fri Jul 27 08:42:35 2012 From: denis.fokin at oracle.com (denis.fokin at oracle.com) Date: Fri, 27 Jul 2012 15:42:35 +0000 Subject: hg: jdk8/awt/jdk: 7149068: java/awt/Window/Grab/GrabTest.java failed Message-ID: <20120727154320.837F447259@hg.openjdk.java.net> Changeset: 80b1ecc79852 Author: denis Date: 2012-07-27 19:41 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/80b1ecc79852 7149068: java/awt/Window/Grab/GrabTest.java failed Reviewed-by: art, ant + test/java/awt/Window/Grab/GrabTest.java From denis.fokin at oracle.com Fri Jul 27 09:13:16 2012 From: denis.fokin at oracle.com (Denis S. Fokin) Date: Fri, 27 Jul 2012 20:13:16 +0400 Subject: [7u8] Review request for 7149068 java/awt/Window/Grab/GrabTest.java failed Message-ID: <5012BE1C.3050103@oracle.com> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149068 webrev: http://cr.openjdk.java.net/~denis/7149068/webrev.7u8/ This is a direct backport of CR 7149068 into the jdk7u8 from the jdk8 release. I have run the test with Jtreg suite. The test passes. Thank you, Denis. From oleg.pekhovskiy at oracle.com Fri Jul 27 09:26:21 2012 From: oleg.pekhovskiy at oracle.com (Oleg Pekhovskiy) Date: Fri, 27 Jul 2012 20:26:21 +0400 Subject: [7u8] Review request for 7149068 java/awt/Window/Grab/GrabTest.java failed In-Reply-To: <5012BE1C.3050103@oracle.com> References: <5012BE1C.3050103@oracle.com> Message-ID: <5012C12D.6040204@oracle.com> Looks fine to me. Thanks, Oleg 7/27/2012 8:13 PM, Denis S. Fokin wrote: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7149068 > webrev: http://cr.openjdk.java.net/~denis/7149068/webrev.7u8/ > > This is a direct backport of CR 7149068 into the jdk7u8 from the jdk8 > release. > > I have run the test with Jtreg suite. The test passes. > > Thank you, > Denis. From lana.steuck at oracle.com Sat Jul 28 00:25:36 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 07:25:36 +0000 Subject: hg: jdk8/awt: 8 new changesets Message-ID: <20120728072537.EE32747282@hg.openjdk.java.net> Changeset: ba77d95ed219 Author: ohair Date: 2012-07-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/ba77d95ed219 7184406: Adjust get_source/hgforest script to allow for trailing // characters Reviewed-by: tbell ! make/scripts/hgforest.sh Changeset: 3f6c72d1c2a6 Author: katleman Date: 2012-07-18 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/3f6c72d1c2a6 Merge Changeset: 969c75896558 Author: cl Date: 2012-07-23 12:37 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/969c75896558 Added tag jdk8-b48 for changeset 3f6c72d1c2a6 ! .hgtags Changeset: 0562a97bd601 Author: vinnie Date: 2012-07-16 22:41 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/rev/0562a97bd601 6880559: Enable PKCS11 64-bit windows builds Reviewed-by: valeriep ! THIRD_PARTY_README Changeset: c88aceaf2f3f Author: lana Date: 2012-07-16 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/c88aceaf2f3f Merge - common/autoconf/cores.m4 - common/makefiles/RMICompile.gmk Changeset: 36998bc84cff Author: lana Date: 2012-07-18 16:08 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/36998bc84cff Merge Changeset: c97b99424815 Author: lana Date: 2012-07-24 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/c97b99424815 Merge Changeset: 2fd67618b9a3 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/rev/2fd67618b9a3 Added tag jdk8-b49 for changeset c97b99424815 ! .hgtags From lana.steuck at oracle.com Sat Jul 28 00:25:35 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 07:25:35 +0000 Subject: hg: jdk8/awt/corba: 2 new changesets Message-ID: <20120728072541.8433047283@hg.openjdk.java.net> Changeset: fe44e58a6bdb Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/fe44e58a6bdb Added tag jdk8-b48 for changeset 7e2b179a5b4d ! .hgtags Changeset: d20d9eb9f093 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/corba/rev/d20d9eb9f093 Added tag jdk8-b49 for changeset fe44e58a6bdb ! .hgtags From lana.steuck at oracle.com Sat Jul 28 00:25:40 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 07:25:40 +0000 Subject: hg: jdk8/awt/jaxws: 2 new changesets Message-ID: <20120728072552.90DDD47284@hg.openjdk.java.net> Changeset: b48865af8ac5 Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/b48865af8ac5 Added tag jdk8-b48 for changeset efb564de8a8e ! .hgtags Changeset: bdab72e87b83 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxws/rev/bdab72e87b83 Added tag jdk8-b49 for changeset b48865af8ac5 ! .hgtags From lana.steuck at oracle.com Sat Jul 28 00:25:47 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 07:25:47 +0000 Subject: hg: jdk8/awt/langtools: 5 new changesets Message-ID: <20120728072602.2137F47285@hg.openjdk.java.net> Changeset: 9ee07e5dc0e2 Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/9ee07e5dc0e2 Added tag jdk8-b48 for changeset afb0a5231557 ! .hgtags Changeset: 934a89402f85 Author: mcimadamore Date: 2012-07-13 12:58 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/934a89402f85 7181578: javac reports uninitialized variable with nested try...finally blocks Summary: regression introduced in refactoring of Flow.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/DefiniteAssignment/T7181578.java Changeset: 1f8fc9e50a1f Author: lana Date: 2012-07-16 17:05 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/1f8fc9e50a1f Merge Changeset: c72c164ced67 Author: lana Date: 2012-07-24 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/c72c164ced67 Merge Changeset: b2d8a270f5f2 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/langtools/rev/b2d8a270f5f2 Added tag jdk8-b49 for changeset c72c164ced67 ! .hgtags From lana.steuck at oracle.com Sat Jul 28 00:25:39 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 07:25:39 +0000 Subject: hg: jdk8/awt/jaxp: 5 new changesets Message-ID: <20120728072602.3D27C47286@hg.openjdk.java.net> Changeset: a7e6e1048e4c Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/a7e6e1048e4c Added tag jdk8-b48 for changeset 1c88da9a1365 ! .hgtags Changeset: 6e444b892c99 Author: joehw Date: 2012-07-12 21:06 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/6e444b892c99 7183760: DocumentBuilder.parse(String uri) is not IPv6 enabled Summary: removing the hack of using escapeNonUSAscii. this is the same patch as 7166896 for 7u8. Reviewed-by: psandoz, lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java Changeset: df4092828362 Author: lana Date: 2012-07-16 17:02 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/df4092828362 Merge Changeset: f81e981eca7b Author: lana Date: 2012-07-24 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/f81e981eca7b Merge Changeset: 2791ec55f66b Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jaxp/rev/2791ec55f66b Added tag jdk8-b49 for changeset f81e981eca7b ! .hgtags From lana.steuck at oracle.com Sat Jul 28 00:26:00 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 07:26:00 +0000 Subject: hg: jdk8/awt/hotspot: 18 new changesets Message-ID: <20120728072643.C1EEE47287@hg.openjdk.java.net> Changeset: bcffa4c5eef6 Author: amurillo Date: 2012-06-29 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/bcffa4c5eef6 7180882: new hotspot build - hs24-b16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3759236eea14 Author: kamg Date: 2012-07-02 10:54 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3759236eea14 7167142: Consider a warning when finding a .hotspotrc or .hotspot_compiler file that isn't used Summary: Send warnings to output stream Reviewed-by: dholmes, fparain ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp Changeset: d2a62e0f25eb Author: zgu Date: 2012-06-28 17:03 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d2a62e0f25eb 6995781: Native Memory Tracking (Phase 1) 7151532: DCmd for hotspot native memory tracking Summary: Implementation of native memory tracking phase 1, which tracks VM native memory usage, and related DCmd Reviewed-by: acorn, coleenp, fparain ! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtableEntry.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableBucket.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java ! make/bsd/makefiles/jvmg.make ! make/linux/makefiles/jvmg.make ! make/solaris/makefiles/jvmg.make ! make/windows/makefiles/debug.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/dtrace/hs_private.d ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/c1/c1_CFGPrinter.cpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaAssertions.cpp ! src/share/vm/classfile/javaAssertions.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/classfile/resolutionErrors.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/survRateGroup.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/cSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/cSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/collectorCounters.cpp ! src/share/vm/gc_implementation/shared/collectorCounters.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcPolicyCounters.hpp ! src/share/vm/gc_implementation/shared/gcStats.hpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_implementation/shared/spaceDecorator.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/interpreter/oopMapCache.hpp ! src/share/vm/libadt/set.cpp ! src/share/vm/libadt/vectset.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/freeBlockDictionary.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/generationSpec.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/memRegion.hpp ! src/share/vm/memory/permGen.hpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/restore.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEnvThreadState.cpp ! src/share/vm/prims/jvmtiEnvThreadState.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiExtensions.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRawMonitor.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/prims/jvmtiUtil.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/monitorChunk.cpp ! src/share/vm/runtime/monitorChunk.hpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubCodeGenerator.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/unhandledOops.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vframe_hp.cpp ! src/share/vm/runtime/vframe_hp.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticArgument.hpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/gcNotifier.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.hpp ! src/share/vm/services/management.cpp + src/share/vm/services/memBaseline.cpp + src/share/vm/services/memBaseline.hpp + src/share/vm/services/memPtr.cpp + src/share/vm/services/memPtr.hpp + src/share/vm/services/memPtrArray.hpp + src/share/vm/services/memRecorder.cpp + src/share/vm/services/memRecorder.hpp + src/share/vm/services/memReporter.cpp + src/share/vm/services/memReporter.hpp + src/share/vm/services/memSnapshot.cpp + src/share/vm/services/memSnapshot.hpp + src/share/vm/services/memTrackWorker.cpp + src/share/vm/services/memTrackWorker.hpp + src/share/vm/services/memTracker.cpp + src/share/vm/services/memTracker.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp + src/share/vm/services/nmtDCmd.cpp + src/share/vm/services/nmtDCmd.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp ! src/share/vm/utilities/histogram.cpp ! src/share/vm/utilities/histogram.hpp ! src/share/vm/utilities/intHisto.cpp ! src/share/vm/utilities/intHisto.hpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/numberSeq.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/stack.hpp ! src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/xmlstream.cpp Changeset: 24b9c7f4cae6 Author: coleenp Date: 2012-07-02 13:11 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/24b9c7f4cae6 Merge ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/memory/universe.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 3f1ab0c19c30 Author: dholmes Date: 2012-07-03 01:41 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/3f1ab0c19c30 7179383: MaxDirectMemorySize argument parsing is broken for values >2G Summary: change hotspot flag to be unsigned Reviewed-by: dholmes, sla, fparain, brutisso Contributed-by: Chris Dennis ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 65906dc96aa1 Author: mikael Date: 2012-07-03 17:35 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/65906dc96aa1 7129724: MAC: Core file location is wrong in crash report Summary: Updated core path location to reflect macosx default Reviewed-by: dholmes, kamg ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/os.hpp Changeset: ace99a6ffc83 Author: coleenp Date: 2012-07-04 15:55 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ace99a6ffc83 7181200: JVM new hashing code breaks SA in product mode Summary: Made new_hash() overloaded rather than a virtual function so SA code doesn't need to be changed. Reviewed-by: kvn, acorn, dholmes, fparain ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 5a1f452f8f90 Author: sla Date: 2012-06-28 11:37 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/5a1f452f8f90 7178703: Fix handling of quoted arguments and better error messages in dcmd Reviewed-by: coleenp, mgronlun, rbackman ! src/share/vm/prims/whitebox.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! test/serviceability/ParserTest.java Changeset: 04ade88d9712 Author: fparain Date: 2012-07-09 01:28 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/04ade88d9712 6294277: java -Xdebug crashes on SourceDebugExtension attribute larger than 64K Reviewed-by: sspitsyn, dholmes, coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp + test/runtime/6294277/SourceDebugExtension.java + test/runtime/6294277/Test6294277.sh Changeset: 90d5a592ea8f Author: coleenp Date: 2012-07-12 14:26 -0400 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/90d5a592ea8f Merge ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp Changeset: d50605d9417e Author: roland Date: 2012-07-02 09:58 +0200 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/d50605d9417e 7177917: Failed test java/lang/Math/PowTests.java Summary: When c2 intrinsifies pow/exp, it should never inline the java implementations. Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp + test/compiler/7177917/Test7177917.java Changeset: 70862d781d01 Author: kvn Date: 2012-07-02 12:59 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/70862d781d01 7180769: assert(tboth->klass_is_exact()) failed: klass should be exact Summary: Use class exactness as part of the condition for class compare optimization instead of assert. Reviewed-by: twisti, roland ! src/share/vm/opto/parse2.cpp Changeset: ae9241bbce4a Author: kvn Date: 2012-07-11 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ae9241bbce4a 7181658: CTW: assert(t->meet(t0) == t) failed: Not monotonic Summary: Use uncast node equivalence checks in CmpUNode::sub. Reviewed-by: kvn, twisti Contributed-by: vladimir.x.ivanov at oracle.com ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp Changeset: cc787232c4c5 Author: kvn Date: 2012-07-12 14:19 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/cc787232c4c5 Merge Changeset: 66b0450071c1 Author: amurillo Date: 2012-07-13 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/66b0450071c1 Merge Changeset: 1e26f61bbb52 Author: amurillo Date: 2012-07-13 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/1e26f61bbb52 Added tag hs24-b16 for changeset 66b0450071c1 ! .hgtags Changeset: e3619706a725 Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/e3619706a725 Added tag jdk8-b48 for changeset 1e26f61bbb52 ! .hgtags Changeset: ea926f2921d6 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/hotspot/rev/ea926f2921d6 Added tag jdk8-b49 for changeset e3619706a725 ! .hgtags From lana.steuck at oracle.com Sat Jul 28 00:26:37 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 07:26:37 +0000 Subject: hg: jdk8/awt/jdk: 26 new changesets Message-ID: <20120728073123.67F854728A@hg.openjdk.java.net> Changeset: 09a79167142c Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/09a79167142c Added tag jdk8-b48 for changeset 3e4ab821f461 ! .hgtags Changeset: a18a547546a4 Author: prr Date: 2012-07-12 16:24 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/a18a547546a4 7183458: Metrics of space character in algorithmically emboldened font have changed in JDK 7. Reviewed-by: igor, jgodinez + test/java/awt/FontMetrics/StyledSpaceAdvance.java Changeset: 9f21c95bfbc1 Author: lana Date: 2012-07-16 16:49 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9f21c95bfbc1 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 Changeset: ab0b2720a756 Author: prr Date: 2012-07-17 16:35 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ab0b2720a756 7183251: Netbeans editor renders text wrong on JDK 7u6 build 17 Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/SunLayoutEngine.java Changeset: 86ca943c120b Author: lana Date: 2012-07-18 16:07 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/86ca943c120b Merge Changeset: 97eb7a4b1fdd Author: smarks Date: 2012-07-05 15:12 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/97eb7a4b1fdd 6948101: java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently Reviewed-by: dholmes, smarks Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/rmi/transport/pinLastArguments/PinLastArguments.java Changeset: 4ad204cc7433 Author: smarks Date: 2012-07-05 15:13 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4ad204cc7433 7123972: test/java/lang/annotation/loaderLeak/Main.java fails intermittently Reviewed-by: dholmes, smarks Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/lang/annotation/loaderLeak/Main.java Changeset: 15a6b0bceb1e Author: zhouyx Date: 2012-07-06 10:36 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/15a6b0bceb1e 7181353: Update error message to distinguish native OOM and java OOM in net Reviewed-by: chegar ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c Changeset: 516e0c884af2 Author: robm Date: 2012-07-09 22:26 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/516e0c884af2 7179305: (fs) Method name sun.nio.fs.UnixPath.getPathForExecptionMessage is misspelled Reviewed-by: dholmes, chegar ! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxWatchService.java ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/solaris/classes/sun/nio/fs/UnixCopyFile.java ! src/solaris/classes/sun/nio/fs/UnixException.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixPath.java Changeset: 79b63e8eceda Author: weijun Date: 2012-07-11 17:10 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/79b63e8eceda 6966259: Make PrincipalName and Realm immutable Reviewed-by: xuelei ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbAppMessage.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/KrbCred.java ! src/share/classes/sun/security/krb5/KrbException.java ! src/share/classes/sun/security/krb5/KrbKdcRep.java ! src/share/classes/sun/security/krb5/KrbPriv.java ! src/share/classes/sun/security/krb5/KrbSafe.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/RealmException.java - src/share/classes/sun/security/krb5/ServiceName.java ! src/share/classes/sun/security/krb5/internal/ASRep.java ! src/share/classes/sun/security/krb5/internal/Authenticator.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/EncASRepPart.java ! src/share/classes/sun/security/krb5/internal/EncKDCRepPart.java ! src/share/classes/sun/security/krb5/internal/EncTGSRepPart.java ! src/share/classes/sun/security/krb5/internal/EncTicketPart.java ! src/share/classes/sun/security/krb5/internal/KDCRep.java ! src/share/classes/sun/security/krb5/internal/KDCReqBody.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java ! src/share/classes/sun/security/krb5/internal/TGSRep.java ! src/share/classes/sun/security/krb5/internal/Ticket.java ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java ! src/share/classes/sun/security/krb5/internal/ccache/CredentialsCache.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/ccache/MemoryCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! src/windows/classes/sun/security/krb5/internal/tools/KinitOptions.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! src/windows/native/sun/security/krb5/NativeCreds.c - test/sun/security/krb5/ServiceNameClone.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/name/Constructors.java + test/sun/security/krb5/name/empty.conf + test/sun/security/krb5/name/krb5.conf Changeset: e9461aeff91f Author: khazra Date: 2012-07-13 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e9461aeff91f 7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node Summary: Change native code to convey to Java code whether a new node was added Reviewed-by: alanb, chegar ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/native/java/util/MacOSXPreferencesFile.m + test/java/util/prefs/AddNodeChangeListener.java Changeset: 9e5150e8bcf5 Author: ksrini Date: 2012-07-14 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/9e5150e8bcf5 7184145: (pack200) pack200 --repack throws NullPointerException when JAR file specified without path Reviewed-by: alanb, sherman ! src/share/classes/com/sun/java/util/jar/pack/Driver.java + test/tools/pack200/RepackTest.java Changeset: 5cee646eaaa7 Author: vinnie Date: 2012-07-16 22:38 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5cee646eaaa7 6880559: Enable PKCS11 64-bit windows builds Reviewed-by: valeriep ! THIRD_PARTY_README ! make/sun/security/Makefile ! test/sun/security/pkcs11/PKCS11Test.java + test/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.chk + test/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/nss3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nss3.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/nssckbi.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.chk + test/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.chk + test/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/sqlite3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.lib + test/sun/security/pkcs11/nss/lib/windows-i586/freebl3.chk + test/sun/security/pkcs11/nss/lib/windows-i586/freebl3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nss3.lib + test/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.chk + test/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.lib + test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.chk + test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/sqlite3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/ssl3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/ssl3.lib + test/sun/security/pkcs11/nss/src/MD5SUMS + test/sun/security/pkcs11/nss/src/SHA1SUMS + test/sun/security/pkcs11/nss/src/nss-3.13.1.tar.gz Changeset: 1469be7182b4 Author: khazra Date: 2012-07-16 16:30 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1469be7182b4 7177045: Rework the TestProviderLeak.java regression test, it is too fragile to low memory errors. Summary: Increase Xmx to 20 MB and add mechanisms to eat up most of the JVM free memory. Reviewed-by: wetmore Contributed-by: dan.xu at oracle.com ! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java Changeset: e2d265c9b592 Author: weijun Date: 2012-07-17 11:28 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e2d265c9b592 7183203: ShortRSAKeynnn.sh tests intermittent failure Reviewed-by: xuelei ! test/sun/security/mscapi/ShortRSAKey1024.sh - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 2a39c98c1241 Author: weijun Date: 2012-07-17 11:57 +0800 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2a39c98c1241 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified Reviewed-by: mullan ! test/sun/security/util/Oid/S11N.sh Changeset: 7b5e4a64368a Author: lana Date: 2012-07-16 17:04 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7b5e4a64368a 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 Changeset: c7e3106e455a Author: lana Date: 2012-07-16 22:05 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c7e3106e455a Merge - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: b6f78869c66d Author: dmocek Date: 2012-07-17 11:01 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b6f78869c66d 7142596: RMI JPRT tests are failing Summary: Changed RMI tests to use random port numbers for the RMI Registry and RMID so the tests can be run concurrently without test failures due to tests using the same port numbers. Reviewed-by: smarks, alanb Contributed-by: olivier.lagneau at oracle.com ! test/ProblemList.txt ! test/TEST.ROOT ! test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java ! test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java ! test/java/rmi/Naming/LookupNameWithColon.java ! test/java/rmi/Naming/RmiIsNoScheme.java ! test/java/rmi/Naming/UnderscoreHost.java ! test/java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java ! test/java/rmi/activation/Activatable/checkActivateRef/security.policy ! test/java/rmi/activation/Activatable/checkAnnotations/security.policy ! test/java/rmi/activation/Activatable/checkImplClassLoader/security.policy ! test/java/rmi/activation/Activatable/checkRegisterInLog/security.policy ! test/java/rmi/activation/Activatable/createPrivateActivable/security.policy ! test/java/rmi/activation/Activatable/downloadParameterClass/security.policy ! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/security.policy ! test/java/rmi/activation/Activatable/extLoadedImpl/security.policy ! test/java/rmi/activation/Activatable/forceLogSnapshot/security.policy ! test/java/rmi/activation/Activatable/inactiveGroup/security.policy ! test/java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.java ! test/java/rmi/activation/Activatable/nestedActivate/security.policy ! test/java/rmi/activation/Activatable/nonExistentActivatable/security.policy ! test/java/rmi/activation/Activatable/restartCrashedService/security.policy ! test/java/rmi/activation/Activatable/restartLatecomer/security.policy ! test/java/rmi/activation/Activatable/restartService/security.policy ! test/java/rmi/activation/Activatable/shutdownGracefully/security.policy ! test/java/rmi/activation/Activatable/unregisterInactive/security.policy ! test/java/rmi/activation/ActivateFailedException/activateFails/security.policy ! test/java/rmi/activation/ActivationSystem/activeGroup/security.policy ! test/java/rmi/activation/ActivationSystem/modifyDescriptor/security.policy ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/security.policy ! test/java/rmi/activation/CommandEnvironment/SetChildEnv.java ! test/java/rmi/activation/CommandEnvironment/security.policy ! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/activation/rmidViaInheritedChannel/rmid.security.policy ! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java ! test/java/rmi/registry/emptyName/EmptyName.java ! test/java/rmi/registry/interfaceHash/InterfaceHash.java ! test/java/rmi/registry/multipleRegistries/MultipleRegistries.java ! test/java/rmi/registry/readTest/readTest.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/registry/reexport/Reexport.java ! test/java/rmi/reliability/juicer/AppleUserImpl.java ! test/java/rmi/reliability/juicer/ApplicationServer.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/EchoImpl.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/security.policy ! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/HelloImpl.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/security.policy ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/EchoImpl.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/security.policy ! test/java/rmi/server/RemoteServer/AddrInUse.java ! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/KeepAliveDuringCall.java ! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/ShutdownImpl.java ! test/java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java ! test/java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java ! test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java ! test/java/rmi/server/Unreferenced/leaseCheckInterval/SelfTerminator.java ! test/java/rmi/server/Unreferenced/unreferencedContext/UnreferencedContext.java ! test/java/rmi/server/useCustomRef/UseCustomRef.java ! test/java/rmi/server/useCustomRef/security.policy ! test/java/rmi/testlibrary/ActivationLibrary.java ! test/java/rmi/testlibrary/RMID.java ! test/java/rmi/testlibrary/RegistryRunner.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/java/rmi/testlibrary/TestLibrary.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/checkFQDN/CheckFQDNClient.java ! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java ! test/java/rmi/transport/checkLeaseInfoLeak/LeaseLeakClient.java ! test/java/rmi/transport/checkLeaseInfoLeak/security.policy ! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java ! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java ! test/java/rmi/transport/dgcDeadLock/TestImpl.java ! test/java/rmi/transport/handshakeFailure/HandshakeFailure.java ! test/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java ! test/java/rmi/transport/httpSocket/HttpSocketTest.java ! test/java/rmi/transport/httpSocket/security.policy ! test/java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java ! test/java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java ! test/java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java ! test/sun/rmi/rmic/newrmic/equivalence/AppleUserImpl.java ! test/sun/rmi/rmic/newrmic/equivalence/run.sh ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java ! test/sun/rmi/transport/proxy/EagerHttpFallback.java ! test/sun/rmi/transport/tcp/DeadCachedConnection.java Changeset: c76ad79a5a2f Author: sherman Date: 2012-07-17 19:57 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c76ad79a5a2f 7183053: Optimize DoubleByte charset for String.getBytes()/new String(byte[]) Summary: DoubleByte implements sun/nio.cs/ArrayDe/Encoder interface Reviewed-by: alanb ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java ! test/sun/nio/cs/StrCodingBenchmark.java + test/sun/nio/cs/StrCodingBenchmarkDB.java ! test/sun/nio/cs/TestStringCoding.java Changeset: 89129c0737f1 Author: dmocek Date: 2012-07-18 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/89129c0737f1 7184943: fix failing test com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java 7184946: fix failing test com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java Reviewed-by: smarks ! test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java ! test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java Changeset: 7bd32bfc0539 Author: michaelm Date: 2012-07-18 18:46 +0100 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7bd32bfc0539 7183292: HttpURLConnection.getHeaderFields() throws IllegalArgumentException: Illegal cookie name Reviewed-by: khazra, chegar ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java + test/java/net/HttpCookie/IllegalCookieNameTest.java Changeset: 255c2c63697e Author: lana Date: 2012-07-18 16:09 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/255c2c63697e Merge - 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: 51707c3b75c0 Author: lana Date: 2012-07-24 11:06 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/51707c3b75c0 Merge Changeset: e4bae5c53fca Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e4bae5c53fca Added tag jdk8-b49 for changeset 51707c3b75c0 ! .hgtags Changeset: 1579507a736f Author: lana Date: 2012-07-27 22:39 -0700 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1579507a736f Merge - 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 From sergey.malenkov at oracle.com Mon Jul 30 02:56:02 2012 From: sergey.malenkov at oracle.com (sergey.malenkov at oracle.com) Date: Mon, 30 Jul 2012 09:56:02 +0000 Subject: hg: jdk8/awt/jdk: 7187618: PropertyDescriptor Performance Slow Message-ID: <20120730095720.75E45472A2@hg.openjdk.java.net> Changeset: 1abb270d9038 Author: malenkov Date: 2012-07-30 13:35 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1abb270d9038 7187618: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Performance/Test7122740.java + test/java/beans/Performance/Test7184799.java From alexandr.scherbatiy at oracle.com Mon Jul 30 03:36:39 2012 From: alexandr.scherbatiy at oracle.com (alexandr.scherbatiy at oracle.com) Date: Mon, 30 Jul 2012 10:36:39 +0000 Subject: hg: jdk8/awt/jdk: 7184365: closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails Message-ID: <20120730103702.A28FD472A4@hg.openjdk.java.net> Changeset: 896322c6f35f Author: alexsch Date: 2012-07-30 14:31 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/896322c6f35f 7184365: closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails Reviewed-by: serb, bagiras ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/share/classes/java/awt/TextComponent.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java + test/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest.java From artem.ananiev at oracle.com Mon Jul 30 05:54:01 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 30 Jul 2012 16:54:01 +0400 Subject: JAWT Breakage in OpenJDK 7/8 In-Reply-To: <50100574.9020607@redhat.com> References: <500ED0D6.2080908@redhat.com> <500FBD79.5050601@oracle.com> <50100574.9020607@redhat.com> Message-ID: <501683E9.8040201@oracle.com> 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. >> 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. As for formal JDK specification, is there anything broken in JDK7/8 version of JAWT? Is there any wording about loadLibrary("jawt") in 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.)? I'm even not sure that there is a specification that declares System.loadLibrary("jawt") to work everywhere. Thanks, Artem > Thanks, > Omair From omajid at redhat.com Mon Jul 30 09:40:37 2012 From: omajid at redhat.com (Omair Majid) Date: Mon, 30 Jul 2012 12:40:37 -0400 Subject: JAWT Breakage in OpenJDK 7/8 In-Reply-To: <501683E9.8040201@oracle.com> References: <500ED0D6.2080908@redhat.com> <500FBD79.5050601@oracle.com> <50100574.9020607@redhat.com> <501683E9.8040201@oracle.com> Message-ID: <5016B905.2070106@redhat.com> 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? Thanks, Omair From neugens.limasoftware at gmail.com Mon Jul 30 10:02:45 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 30 Jul 2012 19:02:45 +0200 Subject: JAWT Breakage in OpenJDK 7/8 In-Reply-To: <501683E9.8040201@oracle.com> References: <500ED0D6.2080908@redhat.com> <500FBD79.5050601@oracle.com> <50100574.9020607@redhat.com> <501683E9.8040201@oracle.com> Message-ID: 2012/7/30 Artem Ananiev : > 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. > > As for formal JDK specification, is there anything broken in JDK7/8 version > of JAWT? Is there any wording about loadLibrary("jawt") in 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.)? I'm even not sure that there is a > specification that declares System.loadLibrary("jawt") to work everywhere. Hi Artem, While I share *some* of your concerns and I'm sympathetic with your point of view regarding backward compatibility, I have to play for once the role that you guys have played for many years: many, many applications are simply not fixable... Removing the jawt.so library seems to be problematic for those applications (even if I think I for first wanted to see this library be linked just on demand), and to be honest, I don't see a big issue here with the proposed patch, it looks ok to me. Maybe there is some other reason why this is not acceptable than a couple millisecond delay (trade backward compatibility for a couple millisecond start up time doesn't seem right, though)? I also believe that Omair proposed another approach on the build-dev (Omair, please correct me if I'm wrong), based on changing the LDFLAGS rather than explicitly load the library in the awt initialisation code, this may be a better solution for you. In either case, I would love to see this sorted out, since we're getting real world applications involved in that, and it would be unfortunate if we would only fix this issue in IcedTea distributions and not get this upstream instead. I would really appreciate if you could either suggest an alternative fix that would work for you, or sync with us and the Build team for a better approach if possible? Thanks for your input, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/